[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] map-and-map (vs map-and-encaps) - further thoughts
Brian E Carpenter wrote:
On 2008-01-04 23:08, Brian Dickson wrote:
Here are some further interesting side-benefits that come from doing
transmogrification (onto, and then 1:1, mappings), rather than
encapsulation (tunneling):
It is possible for non-EID hosts (without an ITR) to speak to an EID
host, by addressing it via any of its RLOC addresses. The ETR maps
the RLOC onto the EID, and the EID host doesn't know any different.
My attention may have been off, but I don't quite recall how your
proposal remaps to the original addresses at or near the recipient,
which is required for the EID host not to know any different
(because of all the reasons that NAT breaks upper layers).
The essential part is, an ETR may (and likely will) hold many RLOC blocks,
where each block might typically be a (PA) assignment from a larger
(single) PA block.
EID blocks are effectively PI, either by being actual PI blocks
(preferably), or ULA/ULA-G/ULA-C blocks.
Each EID block gets mapped to a set of RLOC blocks, but each RLOC block
only has one EID block mapped to it.
That uniqueness allows for the reverse mapping to be deterministic. The
exact mechanism for forward/reverse lookups
will depend greatly on the specifics of the RLOC->EID mapping database
stuff itself. :-)
This operates, as does the EID->RLOC mapping, is essentially static, and
does not require signalling.
We travelled this road in multi6/shim6 and that's how we ended up with
shim6 being essentially signalled double ended NAT. I don't see how
you can untransmogrify without signalling.
It basically uses the addressing scheme to do this.
I.e. it is part of the architecture, designed-in deliberately.
I'm not sure whether/how that uniqueness can be guaranteed or enforced.
It boils down to, "This is how you do things to make it work, and if you
don't, it won't work."
The main criteria for the mapping database should be, that the essential
elements be delegated to the "customer", and the "customer" would need
to do what is needed, or delegate the authority for doing that to some
third party (e.g. outsourcing entity).
This is mainly so that the design/implementation/operation of lots of
these scales, both globally and from the perspective of the service
providers (PA block owners).
The obvious choice would be to somehow link the mapping to the inherent
delegation that happens with ip6.arpa delegation for the RLOC block(s),
and to the delegation for the EID block.
Perhaps something as simple as a PTR RR at the zone cut of the RLOC
block, and some kind of RR listing the ip6.arpa zones (of the RLOCs)
under the EID block zone?
(This bit needs fleshing out, but the details of the mapping function
are orthogonal to the transmogrification bits.)
Brian D
--
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