Re: mini-cores (was Re: ULA-C)

Keith Moore wrote:
> > In my vision the /48s being given out as "PI" today can be used for the
> > ID portion, while every transit will give a "location" /48 to the site
> > that needs it. Over the DFZ the src/dst will be in DFZ/location style,
> > but when it arrives at the endsite it will be in PI mode again. NAT
> > (that evil thing) is useful and when you do it twice you actually still
> > have the same packet and have achieved a tunnel without the overhead of
> > it. The signaling of what to use is the tricky part though.
> >   
> I think that dual NAT can be used in a somewhat benign way.  If it's
> done by bilateral agreement between networks with globally unique
> prefixes, and the mappings at each end are symmetrical, it seems like
> it's basically equivalent to a tunnel with a kind of header compression
> and without the PMTU reduction issues.
Exactly what I meant. The 'bilateral agreement' is the unknown magic
pixie dust though which should be automated and is the biggest problem.
For the rest it is indeed just automated "tunnels".

> And if the addresses used at the host are unique, it gets rid of many
> of the problems caused by overlapping use of RFC 1918 addresses in IPv4.
> There's still some issues related to traceability of traffic over the
> network, but maybe those are manageable.
The source and destination address are globally unique. As such you know
where the traffic comes from as all these prefixes are correctly
registered in whois. This means that an end-site organization might have
5 /48's in whois: one they use for "ID", this can be a special block
like ULA, PI or just a block they get from one of their upstream ISPs,
and maybe 4 from their upstream ISPs. All would be in whois, pointing at
least to the ISP responsible and maybe even to the org that is using it.
As long as uRPF is correctly enabled nothing will go through the DMZ
which is not from the ISP that actually is supposed to send data sourced
from that prefix. Traceability thus becomes easier as traffic has to be
sourced from the ISP it has to come from.

As mentioned above "PI" blocks can be used for this. As such
organizations who can convince all ISPs in the DFZ that they are
important enough to have their own routing slot can cough up the dough
and be there, others will just have to do with this mechanism to get around.

Greets,
 Jeroen

signature.asc
Description: OpenPGP digital signature

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf