Re: [RRG] MTU/fragmentation AGAIN

[Scott Brim <swb@employees.org>]

Excerpts from Brian Dickson on Wed, Jan 02, 2008 08:30:18PM -0500:
> There's two kinds of "mapping" in math that are interesting: "1:1",
> and "onto".  What we conventionally think of as "1:1", is,
> technically, "1:1 *and* onto".
>
> I bring this up because of an interesting observation. Regardless of
> RLOC used, if mappings are looked up by xTR's in both directions,
> RLOC->EID at the ETR is completely deterministic.

You lose me here already.  At the ETR there is no RLOC->EID *mapping*.
If the RLOC is a valid address of the ETR, the packet is decapsulated
and forwarded toward the EID in the inner header.  EID->RLOC is
determined at the ITR, but I don't understand when you say that
RLOC->EID is determined at the ETR.  RLOCs name xTRs.

But anyway ...

> What if the EIDs were (assigned | issued) as PI address blocks?
> Specifically, PI blocks not routed into the DFZ, per se (but
> potentially available as an "upgrade path"), as an alternative to
> ULA or ULA-{C|G}.
>
> The concept is to "map-and-map", from PI-EID to PA-RLOCs, via 1:1
> mapping(s).  The reverse mappings are likewise 1:1,  reasonably
> trivial, and essentially unchanging regardless of RLOCs in use.
>
> The real benefit is that, like SIIT, it is feasible to do ICMP
> transliteration, thus support PMTUD and similar activities.  That,
> and not affecting the PMTU itself in the first place. :-)
>
> The map-and-map effectively becomes NAT + SNAT, without any port
> mangling.

So ... setting terminology aside, you're suggesting a 1:1 relationship
between an aggregatable, globally routed address and a locally scoped,
not necessarily aggregatable address?  

If I understand you correctly, why have that kind of mapping at all?
Why not do something like 8+


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