Re: [RRG] Six/One: A (Different) Solution for Routing and Addressing in IPv6

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

Christian,

Let me put on my old MULTI6 co-chair hat for this message.

I find the concept of an 'address bunch' very interesting,
not to mention the obvious associated concept of a 'prefix
bunch'. It's essentially identical from the host's viewpoint
to the address set used in shim6, but I think having it
defined at site level is good.

It's unfortunate that we didn't have this idea on the table
at the MULTI6 interim meeting in June 2004, when we sorted
through the many proposed solutions. We were hoping for a
viable proposal derived from 8+8/GSE but we didn't get one.
So I'm trying to look at Six/One as if we were still in 2004.
I have four top-level issues and then some details.

1. Can I ask you to respond, as all the MULTI6 proposals did,
to each of the goals defined in RFC 3582?

2. Can I ask you to explain how Six/One addresses each of the
threats identified in RFC 4218, and to indicate any additional
threats against Six/One and how they are handled?

3. As far as I can see, Six/One requires all of a site's
routeable prefixes to be the same length, or at least not
exceeding a given maximum length. (In GSE it was defined that
they would all be /48, and that was one of the reasons for the
/48 recommendation in RFC 3177.) Unfortunately the RIRs have
scrapped the /48-only recommendation. How can Six/One deal
with this?

4. How does Six/One address the referral problem? In shim6
that is easy - since the ULID address is always a valid locator,
it can be used for referrals, regardless of whether the 3rd party
host support shim6 or not. Can Six/One identify a particular
globally valid locator to use in referrals?

One more general comment. I just re-read the shim6 protocol for
WG Last Call, and was struck by how much detail had to be added
to the basic version from three years ago, to cover all sorts of
corner cases that have been discovered. I am absolutely certain
the same would be true of Six/One. However, shim6 is in need of
a clean solution to the "shim6 proxy" problem, and there is a lot
of commonality in the detailed issues for shim6 and Six/One.
I think there may be an opportunity for using the Six/One approach
to fill the shim6 proxy gap, by means of the very useful 'bunch'
concept, and get the best of both worlds.

Now a few details (definitely not a full review):

> 1.  Introduction
...
>    On the other hand, provider-dependent addressing brings about grave
>    limitations for edge domain operators.  An edge network operator that
>    wishes to rehome must reconfigure networking equipment for traffic
>    control and analysis as well as applications with preconfigured
>    addresses on hosts.  

Anyone who tries to do that (preconfigure IPv6 addresses in apps) is
going to learn the hard way that it doesn't work. IPv6's normal state
is for an interface to have multiple addresses with dynamic address
selection.

>    This affects routers just as well as middleboxes
>    that store addresses, such as firewalls and intrusion detection
>    systems.  Rehoming is therefore expensive and disruptive.

That is only true if you don't have an asset database. I think more
and more IT departments are learning the obvious - that all these
configurations should be automatically generated from a database
and downloaded. In fact, that's one of the motivations for NETCONF,
to get away from proprietary config downloads. I'm not trying to
minimize the costs of adding or removing an IPv6 prefix, but it's
only one of the thousands of things that should be configured
automatically.

...
>    7.   Host preferences.  A host should have a means to suggest to the
>         edge network which provider it would prefer its packets to pass
>         through.

I don't think this is a 'should'. Applications must to be able to control
path selection, e.g. for real time media streams.

...
>       ...The novel concept of Six/One is that a
>    host's addresses differ only in their high-order bits, which enables
>    an edge network or a provider to change the address in a packet on
>    the fly depending on the provider to with the packet is routed.

Truly, that isn't novel. It was the key point in
draft-odell-8+8-00.txt (October 1996). The novelty in Six/One is
the 'address bunch' concept.

    Brian

On 2007-07-02 16:12, Christian Vogt wrote:
> Folks,
>
> the main existing routing and addressing proposals are based on an
> indirection between the addressing spaces of edge and transit domains.
> The strength of indirection is that it contains the size and the update
> frequency of the global routing table.  This can happen transparently to
> hosts and edge networks, enabling new traffic engineering practices and
> reduced rehoming costs for edge networks.
>
> The drawback of indirection is that it requires a distribution of
> address translation information across the Internet.  Little analytical
> insight is currently available on how this be done in fast, scalable,
> and secure manner.  And where indirection requires support of both sides
> of a communication, no smooth transition path exists either.
>
>   http://users.piuha.net/chvogt/pub/2007/draft-vogt-rrg-six-one-00.txt
>
> The routing and addressing solution proposed at the foregoing link,
> Six/One, avoids the problems of indirection.
>
> - It uses a single addressing space of IPv6 addresses, and hence
>
> - works without a distribution of address translation information.
>
> - Hosts can suggest a packet be routed via a preferred provider, yet
>
> - edge networks can overwrite this suggestion according to traffic
>   engineering policies.
>
> - Hosts adapt to the provider selection of an edge network in that
>   subsequent packets include the right addresses directly.
>
> - This adaption happens within 1 RTT w/o packet loss or delay.
>
> - Edge network reconfiguration during rehoming is small if access
>   network operators obey recommended operational practices.
>
> - A smooth transition path exists, driven by incentives for early
>   adopters.
>
> - Deployment will foster global protection against IP spoofing.
>
> Your feedback will be appreciated.
>
> Regards,
> - Christian
>
>
> --
> to unsubscribe send a message to rrg-request@psg.com with the
> word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg