Subject: RE: stable addressing

From: "Fleischman, Eric" <[email-masked]>
Date: Mon, 19 Apr 2004 16:35:09 -0700

Brian,

For whatever it's worth, my Boeing coworkers and I currently expect to maintain a Boeing-unique address space in IPv6 (such as we currently have for IPv4) which will not change regardless of who our ISP may or may not be. I would be very surprised if other Fortune 100 companies do not take a similar stance since we view this stance to be entirely logical: i.e., it is a refusal to be "taken hostage" by ISPs.

On the other hand, in support of your posting, we also don't want outsiders to know about our internal networks. We currently plan to handle this by deploying NATs for IPv6, such as we currently do for IPv4 (i.e., like many other Fortune 100 companies, we use NATs for security, not for addresses). While I doubt if our security people are willing to discard the use of NATs as a security mechanism, perhaps a heavy dose of the logic found within your posting below would cure them of that position (but I somehow doubt it)? 

--Eric

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]]
Sent: Friday, April 16, 2004 7:26 AM
To: Iljitsch van Beijnum
Cc: Multi6 List
Subject: Re: stable addressing

Iljitsch,

> Things are different however for class 4. Here, renumbering is not a 
> realistic option. Even if renumbering the actual network infrastructure 
> were to be doable, changing the associated filters and related security 
> setups is too much work to undertake at regular intervals.

I would dispute this. All that changes is the /48 prefix, and the normal
case in IPv6 is to be running with several of those simultaneously on
any large site. Actually the filters and internal routing setup will
need to treat the top 48 bits as don't care bits. So it seems to me that
relatively simple operational procedures can deal with prefix changes.

Nevertheless, I assume that all large enterprises will choose to
use a draft-ietf-ipv6-unique-local-addr-03.txt prefix for internal
traffic and some VPN uses. For external traffic I assume they will use
ISP-delegated prefxes, which is where multi6 comes in. 

   Brian

Iljitsch van Beijnum wrote:
> 
> As a result of discussions elsewhere, my concern about lack of stable
> addresses in IPv6 has increased once again. Let me first define four
> fairly typical classes of future IPv6 users:
> 
> 1. single homed users
> 2. "basement multihomers": (very) small networks with two uplinks
> 3. content providers: lots of traffic, but not very many network
> components
> 4. enterprises: lots of subnets, lots of network components
> 
> If we consider NOID-like solutions with DNS names and PA addresses only
> and no longer-lived identifiers or addresses, this should work quite
> well for classes 1, 2 and 3, as the amount of equipment that must be
> reconfigured when a new ISP is connected is relatively small.
> 
> Things are different however for class 4. Here, renumbering is not a
> realistic option. Even if renumbering the actual network infrastructure
> were to be doable, changing the associated filters and related security
> setups is too much work to undertake at regular intervals.
> 
> So how do we solve this? I'm assuming NAT is not an option. One way
> would be to create address space that isn't regularly routable, but can
> be automatically tunneled/aliased over regular PA space. The
> disadvantage here is that tunnel/aliasing setup must happen prior to
> session establishement, which isn't all that great for incoming
> sessions towards these types of addresses, but presumably most sessions
> will either be outgoing or part of a longer-term meta-sessions so this
> shouldn't be as big a problem as with classes 2 and 3. Another problem
> here would be that even if the correspondent for the class 4 user
> doesn't actually multihome, they must still support the mechanisms in
> order to set up and use the tunnel. Again, this might be a disadvantage
> we're willing to swallow as the type of communication for class 4 is
> presumably limited to a subset of the full internet.
> 
> (Obviously an enterprise with lots of internal stuff but also highly
> visible stuff (think Cisco with their huge internal nework and also
> huge web presence) could use stable addressing for most of its network
> and PA/NOID for the most visible parts.)
> 
> Another side effect would be the need for a registry of some kind where
> the initial mapping information can be found in order to create
> tunneling/aliasing state.

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM

---

From: Pekka Savola <[email-masked]>
Date: Tue, 20 Apr 2004 06:32:02 +0300 (EEST)

On Mon, 19 Apr 2004, Fleischman, Eric wrote:
> On the other hand, in support of your posting, we also don't want
> outsiders to know about our internal networks. We currently plan to
> handle this by deploying NATs for IPv6, such as we currently do for
> IPv4 (i.e., like many other Fortune 100 companies, we use NATs for
> security, not for addresses). 

Why don't you just deploy proxy servers at the edge of your network?  
It allows you to talk to the outside using local addresses, while 
disguising the internal topology as only the proxy servers' addresses 
are known?

Much better than deploying v6 NAT.

> While I doubt if our security people
> are willing to discard the use of NATs as a security mechanism,
> perhaps a heavy dose of the logic found within your posting below
> would cure them of that position (but I somehow doubt it)?

What "security" is that, pray?

Not being able to make out internal topology from the v6 addressing 
plan?  Using Proxies fix that.

Not being able to initiate connections to the internal network e.g. 
for mapping the network?  Using a default-deny-incoming stateful 
firewall/ACLs at the border fixes that.

The security benefits of NATs are mostly misguided, which you're 
probably aware of?

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 20 Apr 2004 09:55:49 +0200

Eric,

I'm disappointed that you bring up the N-word in the very same thread I 
started in order to find a way to make it possible to use stable 
addressing in a clean way.

On 20-apr-04, at 1:35, Fleischman, Eric wrote:

> For whatever it's worth, my Boeing coworkers and I currently expect to 
> maintain a Boeing-unique address space in IPv6 (such as we currently 
> have for IPv4)

If you are in fact acting as an ISP you should be able to get a /32 
just like any other ISP. If you plan to assign address space to 200 
"customers" in the next two years you qualify. However, having one 
large address block isn't always advantageous to enterprises, as this 
also means that you may receive traffic for locatioon A in location B 
and vice versa. I know there are people who want their own block and 
then announce more specifics in different locations but I'm afraid 
that's not exactly in line with our plans to keep the size of the 
global routing table manageable.

> security, not for addresses).

Expect things to break if you do. In IPv4 software vendors are forced 
to add NAT workarounds to their products because NAT is very widespread 
in v4, but it's unlikely it will be in v6 as well, so I imagine there 
won't be many NAT workarounds for IPv6.

> While I doubt if our security people are willing to discard the use of 
> NATs as a security mechanism,

Think about it this way: if you have 100 boxes in a /24, it takes an 
atttacker with a dial-up connection all of two seconds to find them. If 
you have 100 boxes in a /64, it takes takes an attacker with 10 Gbps 
nearly a year to scan just the 48-bit MAC address derived addresses, 
and about 20000 years to scan all the RFC 3041 addresses. I suggest 
your security people learn a few new tricks for IPv6 rather than keep 
doing what they're doing today with 96 extra bits.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 22 Apr 2004 16:20:37 +0200

(slowly surfacing over MD5 passwords)

On 2004-04-20, at 09.55, Iljitsch van Beijnum wrote:

>> For whatever it's worth, my Boeing coworkers and I currently expect 
>> to maintain a Boeing-unique address space in IPv6 (such as we 
>> currently have for IPv4)
>

Not that this question is really on-topic for multi6 but it would be 
interesting to better understand what the requirements for companies 
that insist on their own address space are. "Not being hostage by the 
ISP" is one argument, but that often boils down to readdressing scare. 
However, with many of the id/loc ideas that have been presented here, 
readressing is becomes another issue to what we are used to today. 
Anyone like to bite on this? Perhaps we should take this off-list 
though.

- - kurtis -