[ppml] Fw: IRS goes IPv6!
alh-ietf at tndh.net
Wed Feb 22 15:45:22 EST 2006
> Tony's document and my suggestion are just about diametrically
> opposed. He wants to encode physical location in IPv6 addresses.
> I don't care about encoding anything more than the general
> vicinity of the address user and I only want to do that because
> users in the same general vicinity have the possibility of
> easily building a network architecture that allows aggregation
> of that vicinity into a route announcement. In fact, if the
> end user believes that an address from the neighboring vicinity
> would serve them better, then I am happy for ARIN to give them
> that address. As long as the end user knows the purpose of
> assigning addresses out of a reserved block for their geographical
> region, then I am willing to let them choose.
The approaches are not all that different. Other proposals based on cities
have been floated. In a PSTN context yours is effectively an area-code where
previous ones have been city-code. The details about how the addresses are
handed out are minor in context. The real issue with any geo approach is
that providers have to interconnect and hand off the traffic they picked up
via the aggregate to the carrier that has the customer. This is a telco
business model and the 'ISPs are different' mindset refuses to go there.
My approach of going to /48 essentially pre-allocates space so there is no
continuing need to justify or otherwise deal with process. It is completely
devoid of political context so it is not subject to population shifts or the
whims of the UN. If continuing justification is a goal, then stopping at a
/12 would create the prefixes that fit your regional model.
The biggest thing to keep in mind is that while this discussion is occurring
in the ARIN region, there are global implications. It really doesn't help if
ARIN adopts a PI based on area-codes while China and/or India put 1B PI
entries into their BGP announcements. We don't have to have a single global
approach to PI, but this is a difficult enough problem that reinventing for
use outside the ARIN region doesn't make sense.
More information about the ARIN-PPML