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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf