Re: [RRG] Six/One Router: Provider-Independence, IPv4/IPv6 Interworking, Backwards-Compatibility

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

Philip,

thank you for reviewing the Six/One Router documents; deeply
appreciate this.  Going through your comments one-by-one...


> 1. in the spec, how does the Remote Edge Address get set?

This is the destination address of a packet when sent by a host in
an upgraded edge network.


> 2. I couldn't puzzle out whether the Six-One header Option (with the
> original source/destination address before translation) is  
> necessary, an
> optimisation or necessary for the 'first pkt' but not thereafter?

It is necessary; you need it for two things:

- For multiplexing multiple edge addresses ("IDs") onto a single
  transit address ("locator").  The header option then indicates
  which edge address a packet is destined to.

  If the header option cannot be used because one edge network is
  legacy, the Six/One router at the upgraded edge network uses a
  port/address combination from the packet exchange as a pointer
  to the right edge address.  This may require port translation,
  as in today's NATs.

- To indicate whether addresses have to be translated throughout an
  entire packet or only in the IP header.  In the normal case,
  Six/One routers translate only the IP header in packets if they
  know that the other edge network supports Six/One Router as well.
  But if a host contacts a peer by transit address, even though both
  hosts are in upgraded edge networks and would more appropriately
  use edge addresses, then this transit address will not be translated
  at the initiator's side, and must hence be translated throughout the
  entire packet at the recipient's side.  This may happen when the
  initiating host is referred to the transit address by another host.
  The Six/One header option is an indication for this because its
  original destination address is in this case the same as the
  destination address in the IP header.


> 3. I was also a bit unclear on step 5b of outgoing pkts, where you
> translate the source address in the entire pkt including payload. Is
> this necessary, an optimisation or necessary for the 'first pkt' but  
> not
> thereafter? Is this a standard NAT/ALG function?

I must update this because, based on the discussion on this mailing
list, we changed the method by which a Six/One Router detects whether
a remote edge network supports Six/One Router.

In the specification paper, the assumption is still that a Six/One
router has no means of detecting remote Six/One Router support if a
packet is sent to a transit address.  The packet must therefore be
kept processable by a remote host for the case that the remote edge
network is legacy.  This means that also the payload is subject to
address translation, and that the extension header must be an option.

But due to the advantages of using extension headers instead of header
options in IPv4, as pointed out by Robin, the new approach is to have
Six/One routers always discover whether a remote edge network supports
Six/One Router.  And they use the mapping resolution system for that
purpose.  Packet payloads must then be translated if and only if the
remote edge network is legacy, and extension headers must be added in
that and only that case.


> 4. in your analysis doc [ref 1 below] I wasn't completely convinced by
> the scalability section (3.1). I can believe that the transit (ie
> global) routing system is more stable. But haven't you shifted this
> problem to the mapping system - it now has to cope with changes in
> edge/transit mappings? (does this necessarily make things easier?)

Six/One Router does not impose more frequent updates on the mapping
resolution system than other address indirection proposals such as LISP,
APT, Ivip.  In all cases, the mapping resolution system only provides a
set of feasible address mappings.  The selection of a particular
mapping, initially and possibly subsequently due to traffic engineering,
has to be done end-to-end.  Three possibilities:

The mapping for a packet's destination address is chosen by...

(a) the sending side

(b) the sending side initially, but the receiving side controls all
    subsequent re-selections

(c) the receiving side, both initially and subsequently

In cases (a) and (b) the sending side should probe the available
destination address mappings that it has gotten via mapping resolution.
It should do so initially in case (b), and also periodically thereafter
in case (b).  In cases (b) and (c), the receiving side must signal
preferred reachability information to the sending side.

Which approach to follow is something that I think should be more
carefully discussed on this mailing list.  This is a general topic that
is not specific to Six/One Router.  It may be a delicate topic because
it is about the distribution of routing power.


> It's interesting to me that there's similarity, at a high level,  
> between
> Six-one router & the IVIP/LISP/etc family. Both require a separate
> mapping function (is that right?). Also Six/one's header option is not
> dissimilar to tunnelling (different ways of encoding the same info -  
> but
> with different implications for processing at each end & at the  
> transit
> routers [header option bad?], pkt size). I think Christian you're also
> claiming that the tunnelling approaches require a special router (ETR)
> at the destination network (which obviously doesn't exist for legacy
> networks & so is problematic) whilst having a six/one router at the
> destination network is not a reqt.

You are right.  If both edge networks in a packet exchange are
upgraded, then LISP, APT, Ivip, Proxy Shim6, and Six/One Router all
perform either classic tunneling or an equivalent of it.  The
differences become apparent when one edge network is legacy.  With
classic tunneling, you need a special router that takes care of the
legacy edge network, albeit that router might not directly attach to
the legacy edge network (such as in Ivip or with LISP proxies).  With
address translation, you don't need such a special router.  You fall
back from bilateral to unilateral translation instead.

Of course, nobody prevents you from installing a "proxy" Six/One router
close to a legacy edge network.  That would enable bilateral address
translation even for packet exchanges with legacy edge networks, the
benefit being the end-to-end use of the IP addresses involved.  But
the proxy Six/One router would be optional, not mandatory as in
classic tunneling approaches.

Philip, thanks a lot for your review.  I am going to update the
specification paper with the clarifications that your review has
identified as necessary.

- 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