[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