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

[Christian Vogt <christian.vogt@nomadiclab.com>]

Brian,

thank you for your detailed review!

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

Although in Shim6, hosts may use a set of IP addresses with different
interface identifiers.  If a host derives all of its IP addresses from a
MAC address, then the IID will be the same.  But this is not necessarily
so -- due to CGAs, privacy addresses, DAD collisions...

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

Yes, let me write this down in a follow-up email and also include it in
the next version of the draft.

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

Will do this, again in a separate email and in the next version of the
draft.

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

Six/One leaves it up to the edge network operator how long a routing
prefix (the first, provider-dependent bits of a subnet prefix) is.  The
rest of the subnet prefix, the subnet ID, is then used by the edge
network operator to define an internal topology.

If the routing prefixes of a multi-homed edge network differ in length,
then network administration can be simplified by padding the routing
prefixes to the length of the longest routing prefix.  This is not
required for Six/One to work properly, but it permits a clear separation
of the address part used to reach the edge network from the address part
used for routing inside the edge network.  The clear separation, in
turn, makes it simpler to...

- rewrite addresses in routers because only the routing prefix needs to
be rewritten rather than an entire subnet prefix.

- mask the routing prefixes inside the edge network to avoid
reconfiguration in the case of rehoming.

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

As in Shim6, the IP addresses in an address bunch in Six/One are
routable locators.  They can be used for referrals, just as IP addresses
can be used for referrals today.

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

Yes, Six/One can be used in proxy mode.

The disadvantage of running Six/One in proxy mode compared to normal
host-based operation of Six/One is that, in proxy mode, a host (be it at
Six/One level or at application level) loses the ability to choose a
particular provider for its packets.

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

I fully agree with you that IPv6 address preconfiguration should be
avoided.  Unfortunately this practice is yet to become extinct...

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

Right.  It shouldn't be a big deal for large edge network operators to
conceive some clever means for automated network (re-)configuration.
For small edge networks, setting up such a mechanism might be considered
overkill, however.  The reduction in reconfiguration that Six/One
permits is then beneficial.

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

Yeah, I fully agree.  Not only hosts (at the IP layer), but applications
themselves should have an influence on the path they choose.

It is similar for the transport layer:  A transport protocol will be
able to adapt much more quickly to path changes if it receives an
indication about those path changes rather than having to infer them
implicitly.  Tony Li had brought this up on the RAM mailing list.

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

Yes, I should revise this if the relation to prior art is not clear.

The difference between 8+8 and Six/One is that, in 8+8, a host's
addresses actually do NOT differ in their upper bits from the
perspective of a (sending) host.  The host never uses a routing prefix
of its source addresses.  This implies that the host also has no
influence on which provider its packets go through.  In Six/One, this is
different thanks to the concept of address bunches.  (I referred to 8+8
further down in the text when describing that routing prefixes can be
masked inside an edge network.  In Six/One, this masking may happen
anywhere inside the edge network.  In 8+8, routing prefixes are masked
also on the host.)

The difference between Shim6 and Six/One is that, in Shim6, a host's
addresses generally differ in their interface identifiers, so a router
cannot easily rewrite them.  In Six/One, address rewriting is
facilitated through address bunches, which include only addresses with
the same interface identifier.

You are right that the conceptual differences of Six/One compared to
prior art are made possible by address bunches.  I will work on this
paragraph to clarify.

Thanks again, Brian.  These were very valuable comments.

- 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