RE: stable addressing

["marcelo bagnulo" <mbagnulo@ing.uc3m.es>]

> 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.

Good observation

>
>
> > - 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.
>
> 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.

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)

>
> > 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.
>
> Yes.
>
> > 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.
>
> 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.

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

> 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.

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.

>
> 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.
>

I am not following, sorry.

Regards, marcelo

>