RE: stable addressing

["Bound, Jim" <jim.bound@hp.com>]

You don't need NAT just a good firewall which you will need with NAT
anyway.
/jim 

> -----Original Message-----
> From: owner-multi6@ops.ietf.org 
> [mailto:owner-multi6@ops.ietf.org] On Behalf Of Fleischman, Eric
> Sent: Monday, April 19, 2004 7:35 PM
> To: Brian E Carpenter; Iljitsch van Beijnum
> Cc: Multi6 List
> Subject: RE: stable addressing
> 
> 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:brc@zurich.ibm.com]
> 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
> 
> 
> 
>