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

From: Christian Vogt <[email-masked]>
Date: Mon, 02 Jul 2007 17:12:22 +0300

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 [email-masked] 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

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Jul 2007 11:08:17 +0200

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

---

From: Christian Vogt <[email-masked]>
Date: Thu, 12 Jul 2007 15:15:44 +0300

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.

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

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

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

---

From: Tony Li <[email-masked]>
Date: Fri, 13 Jul 2007 15:54:42 -0700

> particular provider for its packets.

Many folks would consider that a benefit.  Hosts within an enterprise  
need to be managed in a scalable manner, which effectively  
necessitates the proxy approach.  This is the same driver that makes  
proxy mode for shim6 a pragmatic necessity.   Along with that proxy  
mode, it would seem that this would relieve the burden on the host of  
learning and retaining all of the addresses in its bunch.  This would  
actually simplify deployment.

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 16 Jul 2007 10:36:54 +0200

Tony,

On 2007-07-14 00:54, Tony Li wrote:
> need to be managed in a scalable manner, which effectively necessitates 
> the proxy approach.  This is the same driver that makes proxy mode for 
> shim6 a pragmatic necessity.   Along with that proxy mode, it would seem 
> that this would relieve the burden on the host of learning and retaining 
> all of the addresses in its bunch.  This would actually simplify 
> deployment.

The alternative approach is that the necessary policy and preference
table is automatically distributed to all hosts in the site from
a central point; that would of course require overhead in every host
(but RFC 3484 already assumes such overhead).

There's at least one proposed mechanism for this:
draft-fujisaki-dhc-addr-select-opt-04

    This document describes a new DHCPv6 option for distributing default
    address selection policy information defined in RFC3484 to a client.
    With this option, site administrators can distribute address
    selection policy to control the node's address selection behavior.

        Brian

---

From: Christian Vogt <[email-masked]>
Date: Mon, 16 Jul 2007 12:39:08 +0300

> all of the addresses in its bunch.  This would actually simplify

Hello Tony,

I see your points, have two comments, though.

(1)  Complexity on hosts

The functionality of host-based multi-homing solutions is very similar
to what the hosts need to accomplish for mobility management anyway.
Six/One specifically can be integrated with mobility management.  It
could, e.g., easily be integrated into Mobile IPv6 without changing
Mobile IPv6 too much.  I was planning to describe this in the Six/One
document, but did not have the time so far.

Learning and retaining IP addresses in a bunch does not take extra
effort for a host because hosts configure IP addresses for all
advertised subnet prefixes already according to RFC 2462[bis].  Most
hosts also already use the same interface identifier for all of their IP
addresses.

(2)  Host influence on/awareness of provider selection

The ultimate goal of all routing and addressing solutions is to provide
better connectivity to users.  I hence don't consider it a benefit if
those same solutions eliminate a user's ability to select a connection.

Two reasons:

- Applications, in particular real-time media applications, have an
advantage if they can select a connection because that allows them to
choose a path that is best for a particular traffic type.

- Transport protocols, too, would benefit from the ability to select a
connection.  They would also benefit from an awareness of connectivity
changes as they could so better adapt to such changes.

Cheers,
- Christian

---

From: Christian Vogt <[email-masked]>
Date: Mon, 16 Jul 2007 12:52:44 +0300

> (but RFC 3484 already assumes such overhead).

Right.  And in the specific case of Six/One, you may not even need the
automatic policy/preference distribution.

Given Six/One support on hosts, all the network needs to do to enforce a
particular provider for a given connection is to write that provider's
routing prefix in the packets of the connection.  The end hosts will
recognize the provider change and adopt it -- which also allows for some
host-internal adaption at the transport and application level for
ongoing connections.

Thus, hosts learn the edge network's policies and preferences
dynamically.  No need to pre-configure the hosts.

- Christian

---

From: Tony Li <[email-masked]>
Date: Wed, 25 Jul 2007 17:58:54 -0500

[Sorry for the delay in responding, I'm still catching up after  
vacation...]

> (but RFC 3484 already assumes such overhead).

Unfortunately, distributing policy is NOT the same as having an  
effective policy.  In an enterprise of any significant size, the  
number of hosts that is not completely under the control of the local  
administration can be quite large.  Those host may or may not comply  
with the policy as distributed, either due to non-implementation of  
the policy mechanisms, incorrect implementation, or outright  
malfeasance.

Yes, I realize that this is analogous to the architecture argument  
about firewalls vs the end-to-end principle that we've debated for  
about 20 years now and still do not have consensus on.  No, I don't  
mean to reopen that.  I will point out that the practical necessity  
for firewalls does exist, and therefore the facilities exist in reality.

Similarly pragmatic thinking suggests that enterprise administrators  
will take whatever steps necessary to ensure that they have a proxy  
solution.  Given that, it would be greatly preferable in my mind if  
we architected the solution rather than letting it evolve.

Tony

---

From: "Christian Vogt" <[email-masked]>
Date: Wed, 25 Jul 2007 23:11:33 -0500

> number of hosts that is not completely under the control of the 
> local  administration can be quite large.  Those host may or may not 
> comply  with the policy as distributed, either due to 
> non-implementation of  the policy mechanisms, incorrect 
> implementation, or outright  malfeasance.

Tony,

FWIW, the issue you are raising does pertain to pure host-based 
routing and addressing solutions such as Shim6, but not to combined 
host/network-based solutions such as Six/One.

In Six/One, the edge network is still in charge of selecting a 
provider:  Hosts can only /suggest/ a provider; it's the edge network 
which finally /decides/ whether or not to grant that suggestion.  This 
means that, in Six/One, there is no need to define a provider 
selection policy and distribute it to hosts.

- Christian

---

From: Tony Li <[email-masked]>
Date: Thu, 26 Jul 2007 01:08:36 -0500

Christian,

On Jul 25, 2007, at 11:11 PM, Christian Vogt wrote:

> provider:  Hosts can only /suggest/ a provider; it's the edge  
> network which finally /decides/ whether or not to grant that  
> suggestion.  This means that, in Six/One, there is no need to  
> define a provider selection policy and distribute it to hosts.

and previously:

> changes as they could so better adapt to such changes.

Seems to me you need to decide: either the user/host gets to decide,  
or the middle box does.  You can't have it both ways.  Which is it?

Tony

---

From: Christian Vogt <[email-masked]>
Date: Thu, 26 Jul 2007 07:09:42 -0500

Tony,

please let me know if the explanation below makes things clear.  This is
an important aspect of Six/One.

By sending a packet with an IP source address with provider P1's routing
prefix, a host tells the edge network:  "P1 is the provider I would like
to have my packets go through."

Then it is up to the edge network's policy:

- If network resources and traffic engineering strategies permit, the
edge network can decide:  "OK, we will route the packet to provider P1
as suggested by the host."

- Otherwise, the edge network will say:  "No, we will route the packet
through a different provider P2.  So let's rewrite the routing prefix in
the packet's IP source address so that it matches provider P2."

In other words, hosts can /suggest/ a particular provider, but the edge
network finally decides and /selects/ the provider.

Since hosts adopt a new IP address after a rewrite, network-enforced
provider changes (i.e., path changes) are visible to both hosts of a
connection.  Hosts can then do whatever is necessary to adapt to the
path change efficiently (e.g., by resetting TCP RTT estimations and
triggering Slow Start mode).

Ciao,
- Christian

---

From: Tony Li <[email-masked]>
Date: Thu, 26 Jul 2007 09:49:44 -0500

Hi Christian,

Thanks very much, yes, that's much clearer.

> triggering Slow Start mode).

I'm not clear on this.  Specifically, are all policy selections truly  
visible
to both sides?  Suppose host A selects provider 1, only to be
overridden by his administration to use provider 2.  However,
correspondent host B exercises its prerogative and sends the packet
to destination provider 3.  When A receives the packet, it has no
idea that provider 2 was ever involved...

Tony