RE: [address-policy-wg] Re: 2006-02 Discussion Period extended until 19 March 2007 (IPv6 Address Allocation and Assignment Policy)
Just as an editorial comment: We should also remove the "requirement" to advertise the prefix.
I suppose that could be interpreted as "announce to at least one other AS using BGP4" which can be done without ever having the prefix visible on the public Internet. However, due to the ambiguity of the word "advertise" it would be good to get rid of it and put something less Internet-centric in its place. After all, RFC 2050 explicitly states that RIRs can allocate prefixes that will never be used on the Internet. The RIRs allocate IP resources, not Internet resources.
While there is an argument for using PI for private assignments, right now we can't do this in ipv6, because there is no ipv6 PI space yet. But more importantly, there are situations where it may be appropriate for a private entity to register large amounts of v6 address space, where PI would be less appropriate due to sub-assignment issues.
In particular, there is a general misunderstanding of what "private addressing" means because most people have not read RFC 1918 carefully enough. Many people feel that addresses used on the Internet are "public" and therefore addresses that are not used on the Internet are private. This implies that all non-Internet use of IPv4 addresses should use RFC 1918 allocated ranges. However, that's not the case at all. In fact, RFC 1918 has allocated ranges for networks which will never interconnect. In other words, the word "private" refers to the networks themselves. A private network is one which never connects to another network. In the real world there are many instances of non-Internet IP networks which do interconnect, often on a large scale. Because they interconnect, they need unique addresses, i.e. RIR allocations. In the IPv4 world, people would rig up complex workarounds because of address scarcity, such as double-NAT. However, in the IPv6 world this is not necessary and RIR policy should not force people into replicating these workarounds. --Michael Dillon
participants (1)
-
michael.dillon@bt.com