Re: stable addressing

[Brian E Carpenter <brc@zurich.ibm.com>]

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