On 11/12/08 7:16 PM, William Herrin allegedly wrote: > Operational experience says no lifeline with DNS TTLs I'm afraid. DNS > TTLs only work right with applications which pay attention to DNS > TTLs. This works out to something south of 10% of deployed apps: most > interface with DNS via the gethostbyname call. Some undetermined and > indefinite time later, the other 90% are restarted or encounter some > other event that causes them to look up the DNS entry again.
Thanks, I had forgotten that. Site renumbering is just hard. >> but I'm told there are also problems because >> changes are required in internal routing and forwarding configuration, >> and in configuration of external sites you have special relationships >> with. > > I'm not sure that makes sense in context. Given a protocol in which > the GUID, SID and LOC are separate, why would you ever statically > assign the LOC to anything? Borrowing the MAC address example again, I > can count on the fingers of one hand the situations in which they get > statically assigned, especially across multiple routing domains. I should probably leave this to others to answer but for example a site may have restrictions on which prefixes (assigned by department) can access which services. I hope others will fill in here. >>> Would you expand on translation? How does translation reduce the >>> number of entries in the routing table? >> Consider Six/One Router or NAT66 or LISP's "NAT". If you translate a PI >> prefix into one or more provider-aggregatable prefixes, you've >> eliminated the PI prefix from global routing. > > If I understand Six/One router (and please correct me if I'm wrong), > it alters the the IPv6 source and destination addresses entering the > core by replacing the edge PI prefixes with provider-assigned > prefixes. Right. Maybe Christian will add more. > The edge PI prefixes are fed (via the mapping system) to the > router where the packet exits the core. When exiting the core at the > other side, the edge PI prefixes are restored. > > I'm not sure I'd call that translation. It seems like Strategy A > variant A1c where the "provider-assigned prefixes" are RLOCs. Instead > of adding space in the packet for the RLOC, a portion of the GUID is > mapped out to make room for the RLOC on entering the core and then > mapped back in on exiting the core. The extra map-in-on-exit is the > price paid for maintaining compatibility with the existing IPv6 > protocol. I was thinking about unilateral mode. In Unilateral Mode, Six/One Router does a 1:1 translation at a site boundary, without involvement of mapping services or a requirement for reverse translation. I get the feeling unilateral mode may be OBEd by NAT66, but I haven't asked Christian. > Maybe that's an engineering compatibility difference like the > gyrations for PMTU in map-encap rather than an architectural > difference? What do you think? > > How do NAT66 and LISP's NAT differ from Six/One Router? NAT66 and Six/One Router preserve the "host" part of the address, and iirc rewrite to a different prefix at different upstream connection points. Scott _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
