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

[<philip.eardley@bt.com>]

Christian

Some questions & comments, having read this & the companion 3 page
'specification' doc.

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

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?

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?

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

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.

Thanks
Phil

> -----Original Message-----
> From: owner-rrg@psg.com [mailto:owner-rrg@psg.com] On Behalf Of
Christian
> Vogt
> Sent: 25 February 2008 07:54
> To: Routing Research Group Mailing List
> Subject: [RRG] Six/One Router: Provider-Independence, IPv4/IPv6
> Interworking, Backwards-Compatibility
> 
> Folks,
> 
> backwards compatibility has proven to be one of the bigger challenges
> in the work of this RG.  It is hard in particular when identifiers are
> to be provider-independent and therefore, for scalability reasons,
non-
> globally routable.  The use of tunneling exacerbates the problem
because
> the extra IP header makes packets unprocessable by recipients in
legacy
> edge networks.
> 
> I would like to propose Six/One Router [1], a network-based variant of
> the original Six/One protocol, which avoids these problems through (1)
> exclusive use of address translation (instead of tunneling), (2)
> optional-to-support packet extensions (instead of mandatory-to-support
> tunnel headers), and (3) the ability for hosts in upgraded edge
networks
> to be reached from legacy edge networks at a locator.
> 
> [1]
http://users.piuha.net/chvogt/pub/2008/vogt-2008-six-one-router.pdf
>      or via RRG homepage
> 
> Specifically, Six/One Router offers:
> 
> - Provider independence (independent of deployment elsewhere)
> 
> - Interworking between IPv4 and IPv6 (different IP versions on hosts,
>   or path of different IP version than the common IP version of hosts)
> 
> - Backwards compatibility with legacy IPv4 and IPv6 Internet
> 
> Six/One Router interoperates with existing mapping resolution
protocols,
> such as NERD, APT Default Mappers, Cons, ALT, DNS Map.
> 
> A comprehensive analysis with respect to the RRG design goals is
> included
> in the paper [1].
> 
> Your comments and opinions will be highly welcome.
> 
> - 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