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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
