Subject: stable addressing

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 16 Apr 2004 15:32:39 +0200

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.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Apr 2004 16:25:56 +0200

Iljitsch,

> 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

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 16 Apr 2004 18:56:41 +0200

> need to treat the top 48 bits as don't care bits.

This can only work if the bottom 80 bits aren't random. And today they 
are, to all intents and purposes. But obviously something like 
draft-van-beijnum-multi6-cbhi-00.txt could change that.

> So it seems to me that

Even if security isn't an issue and there is decent address agility 
higher up in the stack, changing addresses introduces instability and 
rendezvous issues.

> ISP-delegated prefxes, which is where multi6 comes in.

Aarrgghh, multi-faced DNS. It would be better to automatically map 
these addresses to PA addresses where desired. This way, all the 
multiadressing issues are nicely hidden in a layer that really knows 
how to handle them rather than spread around different applications and 
transport protocols, some of which will handle this beautifully, and 
some of which will fail miserably.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 18 Apr 2004 01:04:48 +0200

A "talk first, negotiate later" approach to multiaddress multihoming 
has important advantages, as it allows seamless backward compatibility. 
A weak point of this type of approach is that it doesn't lend itself to 
easy implementation in a middlebox, as compatibility with existing 
transports requires all possible addresses to be available on the 
multihomed host, and it possibly even requires cooperation from 
applications.

However, if we were to add a new "fool the transport" address, this 
problem would largely go away. The idea is that multihomed hosts would 
have stable addresses (presumably unique site locals). For incoming 
sessions, the stable address is advertised in the DNS as a new RR. The 
correspondent looks up both the stable address and the set of regular 
addresses, and proceeds to set up a transport session towards one of 
the regular addresses as per NOID et al. However, the transport 
protocol acts as if the session is towards the remote stable address. 
The middlebox at the receiving site terminates all multihoming 
negotitation. It also maps back and forth between any of the regular 
addresses and the stable address, with the result that the receiving 
host can just use its stable address without being aware of multihoming 
issues.

For outgoing sessions, the multihoming middlebox intercepts DNS 
requests by internal hosts. Rather than just send the AAAA records to 
the requesting hosts, it replies with an AAAA record that contains the 
"fool the transport" address for the remote host, and keeps an 
FTT->AAAA mapping in memory. Then, when the internal host tries to set 
up a session towards the remote FTT address, the middlebox performs the 
necessary multihoming negotiation with the host sitting at the AAAA 
address(es) associated with the FTT address in question and then 
proceeds to rewrite addresses as per the combined FTT->AAAA and 
multihoming state.

Since the FTT address only replaces the locator/identifier at the 
transport level, applications still get to see the addresses that are 
published as AAAA records, so security assumptions aren't broken. That 
is, unless a middlebox is used, but in that case presumably the 
middlebox will handle any address-based security as well as 
multihoming. Since FTT addresses aren't really visible anywhere, there 
is little to no need to authenticate them.

Note that this approach also allows for easier source address rewriting 
by routers.

Two problems remain: interaction between multihomed hosts behind a 
middlebox and legacy IPv6 hosts, and referrals. And one thing to think 
about: making the negotiation protocols such that two or more 
middleboxes can come to the same results independently, so they can 
provide failover for eachother without having to synchronize state 
between them.

---

From: "marcelo bagnulo" <[email-masked]>
Date: Tue, 20 Apr 2004 13:11:19 +0200

Hi Iljitsch,

I very much share your concern about stable addressing.
The fact is that currently in IPv4, multihomed sites usually get PI
addressing, so provider independence is one of the benefits of multihoming
they obtain.
If the IPv6 multihoming solution doesn't provide provider independence, it
will be less attractive.

OTOH, i think we still don't have a clear view of what implies renumbering
in IPv6, as Brian mentions.

there are different renumbering scenarios here:
- Renumbering in current IPv4 networks, The experience here says that it is
expensive and sites will try to avoid it.
- Renumbering in current IPv6 networks, considering stateless
autoconfigurations, a fixed /48 etc. Perhaps it is still expensive but it
will be cheaper. Perhaps it is still too expensive.
- Renumbering when there is a loc/id split solution available. I guess we
don't have much idea how this would be, but we guess that it will be even
cheaper.

As i understand this thread, perhaps it would be possible to design the
solution to provide some sort of stable internal addressing for multihomed
sites, sort of GSE or MHAP like.

IMHO, i think that since this is one of current benefits of multihoming, we
should try to provide it (perhaps we should include it in Elliot's "things
to think about", so it is another aspect considered in the solution space
analysis.
OTOH, IMHO, for now, it should be one of those "nice to have" items, since
we still don't know how really expensive would be the renumbering process in
a general loc/id split and we don't know how hard it will be to provide this
feature.

Bottom line, i really think this should be one of the things we should
consider when analyzing the solution space.

About the particular approach that you are considering below, imho a very
valuable feature of a solution would be that middle boxes are stateless, so
that packets belonging of a certain communication can flow through different
middle boxes. I don't really think that a solution with a per flow state is
a good approach.

Regards, marcelo

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]]En
> nombre de Iljitsch van Beijnum
> Enviado el: domingo, 18 de abril de 2004 1:05
> Para: Multi6 List
> Asunto: Re: stable addressing
>
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 20 Apr 2004 19:18:53 +0200

> If the IPv6 multihoming solution doesn't provide provider 

Exactly. And if multihoming in IPv6 is significantly less attractive 
people may opt to stay with IPv4.

> expensive and sites will try to avoid it.

Going through some renumbering right now... It's never any fun.

> will be cheaper. Perhaps it is still too expensive.

Very much depends on the way things are deployed. When using stateless 
address configuration the actual renumbering is MUCH easier but editing 
all those text files where addresses show up isn't any better than with 
IPv4.

Note that renumbering gets worse as more systems are involved. In IPv4, 
it is common to start out with few addresses, then renumber once or 
twice and finally end up with a (somewhat) portable address block. 
Also, NAT limits the number of systems that receive a new address. With 
IPv6, it's entirely possible that netwoorks that are already very big 
need to renumber. This could be fairly traumatic.

> don't have much idea how this would be, but we guess that it will be 

This will depend on whether people will still find in necessary to 
filter on (locator) IP addresses. If people find it hard to leave NAT 
behind I'm afraid that address filtering won't disappear overnight 
either.

> sites, sort of GSE or MHAP like.

Yes.

> middle boxes. I don't really think that a solution with a per flow 

Hm, we talked about the security issues with rehoming all sessions 
towards an IP address, our conclusion being that this is too dangerous 
without relatively strong authentication. However, this doesn't 
necessarily imply that the alternative must be working per session. 
That also applies here. I think it would be entirely possible to group 
sessions as per a creation/refresh date.

Also, there is still the option of having cryptographic hashes in the 
addresses. This would especially make sense with stable addresses. If 
we can find enough bits the hash can be in the higher part of the 
address so there is no need to make hosts aware of the existence of the 
hash.

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 21 Apr 2004 15:16:55 +0200

> need to renumber. This could be fairly traumatic.

Good observation

> behind I'm afraid that address filtering won't disappear overnight

Yes.
I guess this will depend also on the properties of the identifier namespace
If the id namespace is for instance hierarchical, we could filter based on
identifiers (if they are carried in the packets)
If the id namespace doesn't provide a mean to group a set of id that belong
to the same site, this will be more difficult (this is one of the features
that i like about your old crypto id based proposal, is that it was crypto
but it also allowed the grouping of ids)

> without relatively strong authentication.

Well, if you have a strong authentication on the identifier, the required
security verifications on the locator  are less.

> However, this doesn't

Well, i would preffer a mechanism were the middle box only knows which
prefix to change, and that all the rest of the required state resides on the
ends, sort of address rewriting but in both directions, so that it doesn't
really matter which box is used to carry the packet.

> address so there is no need to make hosts aware of the existence of the

I am not following, sorry.

Regards, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 24 Apr 2004 15:07:39 +0200

[Sorry Brian, but I'm already rate limiting]

> I am not following, sorry.

In my draft I mainly talk about crypto hashes in the interface 
identifier part of the address:

[prefix=48][subnet=16][hash+control=48][hostnumber=16]

However, another option is:

[iana=4][hash=44][subnet=16][eui-64]

Unmodified hosts can simply get addresses within such a prefix through 
stateless address configuration and the middleboxes take care of the 
multihoming issues. Yes, very similar to son-of-site-local+NAT, but 
some important differences:

1. We get multihoming (NAT doesn't provide this)
2. The "real" address is communicated to the correspondent so it's 
transparent
3. The hash over a public key allows for simpler/stronger security in 
the
    multihoming negotiation mechanisms

Note that this can very well be an extension on top of NOID or 
something similar. This would give us the option to either be backward 
compatible OR have stable addressing + strong multihoming security. I 
think that comes pretty close to the ideal solution. (In that case we'd 
have both at the same time...)

Iljitsch