RE: [Re: http://tools.ietf.org/search/draft-hain-ipv6-ulac-01]

["Tony Hain" <alh-ietf () tndh net>]

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