Iljitsch, I think we already discussed that, since it is the essence of a true loc/id split. (Yes, I'm implying that map-encap is a fake loc/id split.) But actually doing it is hardly part of the routing system - it amounts to saying that changing the routing system is too hard, so we'll do something else.
That might be a good conclusion, but I think it would mean chartering a new RG with a different constituency. http://tools.ietf.org/id/draft-irtf-nsrg-report-10.txt says " One of the questiones addressed by the NSRG is: Does the TCP/IP protocol suite need an additional level of naming above layer 3 but below the application layer? There was no consensus on the answer. " Brian On 2008-10-30 01:09, Iljitsch van Beijnum wrote: > I've once again fallen behind on RRG discussions but from the subject:s > I suspect that the renumbering discussion is still going strong. > > With NAT66 as proposed in this draft (which is stateless > transport-agnostic 1-to-1) part of renumbering could become easier, so > perhaps we should discuss the notion of changing the IP architecture > such that addresses may change in transit. Maybe we can find some time > for this in Minneapolis? (Please note that I'm not interested in > discussing the draft itself, but rather the consequences for routing > scalability and the solutions to make routing scale.) > > Begin forwarded message: > >> A new version of I-D, draft-mrw-behave-nat66-00.txt has been >> successfuly submitted by Margaret Wasserman and posted to the IETF >> repository. >> >> Filename: draft-mrw-behave-nat66 >> Revision: 00 >> Title: IPv6-to-IPv6 Network Address Translation (NAT66) >> Creation_date: 2008-10-27 >> WG ID: Independent Submission >> Number_of_pages: 13 >> >> Abstract: >> This document describes a stateless, transport-agnostic IPv6-to-IPv6 >> Network Address Translation (NAT66) function that provides the >> address independence benefit associated with IPv4-to-IPv4 NAT (NAT44) >> while minimizing, but not completely eliminating, the problems >> associated with NAT44. >> >> This document also describes an address mapping option for NAT66 that >> offers the topology hiding benefit associated with NAT44 at the cost >> of additional state in the NAT66 device. > _______________________________________________ > rrg mailing list > [email protected] > https://www.irtf.org/mailman/listinfo/rrg > _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
