[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] Six/One Router Design Clarifications



Dino -

based on what you write below, I suggest you read the Six/One Router
design paper [1] before you speculate more on how to implement it.

I implemented translation in LISP so I am not speculating. What you are doing in Six/One is no different than LISP.

[1] http://users.piuha.net/chvogt/pub/2008/vogt-2008-six-one-router-design.pdf


|With enough thrust anything can fly, but it's easier to do a
|decapsulator than a translator.

Why?

Well for one, you have to do a 5-tuple lookup because most NATs have
both ports as part of the lookup key.

A Six/One router does not use ports.  And lookups are based on only a
64-bit address prefix extracted from an IP header; NOT on a 5-tuple.

Either does LISP. The issue about ports was because talking about stateful NATs which haven't been implemented.

I do realize that for Loc/ID translation it is simpler. We have done the simpler version for LISP.

Connect to http://www.lisp4.net, you'll see it in action.

And for two, it's usually another data structure that has the
translation table. And typically in hardware implementations that is
not the same DRAM. So there is an extra cost there.

This is the case for a NAT; it can be different for a Six/One router.

The reason is that NATs are stateful, whereas Six/One routers are not.
Hence NATs have different implementation requirements than Six/One
routers.

You must keep another table so you can translate a packet egressing a site from one address to another. If you don't do that, then the global address must be imbedded in the source address, which we can go off and talk about how you would do that.

Third, you have to fix the pseudo-header checksum.

Nope.  Six/One routers don't have to fix checksums.

Then it means you can't have a Six/One site talk to a non-Six/One site. If so, you don't have an incremental solution.

Fourth, you have to fix payload like the all important ICMP unreachable
so traceroute works.

You have to do the same with encapsulation.

You do not have to change the payload for the encapsulation case.

Dino

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