While I appreciate Bill's attempt to raise attention to the draft, I needed to update it anyway with the intent to greatly simplify things and hopefully clarify at the same time. Given the interest level in this thread, I will ask for comments here before publishing the updated I-D. Replace intro paragraph 2 with: In any case, the prefixes defined here are not expected to appear in the routing system for the global Internet. A frequent question is how this prefix differs from a PI assignment. The simple answer is in expectation of global public routability. A PI assignment has the expectation that it could appear in the global DFZ, where a ULA-C registration is expected to be limited reach as service providers are free to, and expected to filter the entire FC00::/7 prefix as bogon space. The appropriate use of these prefixes is within a single network administration, or between privately interconnected networks that want to ensure that private communications do not accidentally get routed over the public Internet as might happen with PI. Replace section 3.2 & 3.3 with: Global IDs MUST be allocated under a single allocation and registration authority. The IAB SHOULD designate IANA as the registration authority. As policies differ around the world, IANA SHOULD delegate to the RIRs in a manner similar to the /12 approach used for the 2000::/3 prefix. The RIRs SHOULD establish registration policies which recognize that ULA-C prefixes are not a threat to the global DFZ, and therefore easier to justify. Organizations that don't want an ongoing relationship with the RIRs SHOULD be directed to RFC 4193. The requirements for ULA-C allocation and registrations are: - Globally Unique. - Available to anyone in an unbiased manner. - Available as a single prefix when justified to align subnet structures with PA or PI. Other clean up as necessary to align with this simplified text. The point is to remove as much policy as possible from the IETF text, and leave that to each region. Comments welcome, and to the extent they are operationally related to the DFZ could remain on nanog, but otherwise should be on the IETF 6man list. Tony
-----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Monday, April 26, 2010 8:33 AM To: Stephen Sprunk Cc: North American Noise and Off-topic Gripes Subject: Re: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]
On Apr 26, 2010, at 7:20 AM, Stephen Sprunk wrote:
On 24 Apr 2010 21:01, Mark Smith wrote:
On Thu, 22 Apr 2010 01:48:18 -0400 Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Wed, Apr 21, 2010 at 5:47 PM, Mark Smith <nanog@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> wrote:
So what happens when you change providers? How are you going to keep using globals that now aren't yours?
use pi space, request it from your local friendly RIR.
I was hoping that wasn't going to be your answer. So do you expect every residential customer to get a PI from an RIR?
The vast majority of residential customers have no idea what "globals" or "PI" are. They use PA and they're fine with that--despite being forcibly renumbered every few hours/days. (Many ISPs deliberately tune their DHCP servers to give residential customers a different address each time for "market segmentation" reasons.)
The majority of residential cusotmers bitch about paying $20/month for what they have and are not planning to multihome.
This was a comment about multihoming.
FWIW, this residential user has PI from an RIR (v4 and v6) and is multihomed using it. It works fine.
The only semi-rational justification for ULA-C is that organizations privately internetworking with other organizations are scared of ULA-
R
collisions. However, PI solves that problem just as readily. If one cannot afford or qualify for PI, or one wants a non-PI prefix due to delusions of better security, one can use a private deconfliction registry, e.g. <http://www.sixxs.net/tools/grh/ula/>.
The claim being made which I was attempting to refute had nothing to do with residential. IT was that ULA-C with NAT at the border would allow an organization to semi-transparently switch back and forth between providers. This is a (somewhat) common practice in IPv4 for delivering (degraded) multihoming.
Owen