RE: draft-ietf-ipv6-ula-central-02.txt - reverse DNS

["Tony Hain" <[e-mail]>]

You may have received an answer to this already, but I am just catching up
and since you asked for help understanding, I thought I would provide some
context. 

The RIR community is being spun up that ULA-C is nothing more than PI
because some members want to retain control over who has addresses and how
much. PI is a hot issue because there is a potential impact to the global
routing system if it runs unchecked. 

ULA L or C is about a space that is not intended to show up in the global
routing system. As such it should not have the same restrictions over who
can have it that PI would have. 

Yes an organization with PI could implement an acl or simply limit the
length of the prefix that is announced to routing and have the same effect
---from their perspective---. From the perspective of the rest of the world
though, it is not clear if a PI block is intended to be globally routed or
not so they can't filter it arbitrarily. ULA has the upfront global
expectation that if it shows up it is a bogon that should be filtered. 

ULA-L is targeted at the soho router default config and organizations that
just don't want to deal with the RIRs. Their probability of collision is low
enough relative to their likelihood of multiple connections that it really
doesn't matter. 

ULA-C is about organizations that really want to have public bogon filtering
to help restrict access to a given network, but also want to ensure that
future mergers and acquisitions or partnerships that form will not have any
possibility of collision. 

This should never have been a big deal, but when all the RIRs were refusing
to allow any PI space ULA-C was seen as an end-around that policy. Even now,
only ARIN & APnic allow PI, so ULA-C is still perceived to be a problem for
the DFZ. 

My suggestion to both the RIPE and ARIN communities has been to embrace
ULA-C and give every member a ULA-C block in addition to whatever else they
ask for. If they don't own the space someone will, then there will be
competing registries and a real risk that ULA becomes PI due to easier
access or lower cost. If a ULA-C requires RIR membership, the member can
choose whatever space makes sense for their deployment and all this RIR/IETF
noise will not matter. 

Tony


> -----Original Message-----
> From: Kevin Kargel [mailto:[e-mail]]
> Sent: Tuesday, June 19, 2007 1:11 PM
> To: [e-mail]
> Subject: RE: draft-ietf-ipv6-ula-central-02.txt - reverse DNS
> 
> I fail to see the point of mandating non-routable space with allocated
> ULA-C.  Any network administrator has the ability and freedom to not
> route as much or as little of their PI space as they want.   Why force
> constraints on usage?
> 
> If they are going to link two physically seperated sites (into a WLAN
> or
> MLAN for example) with 'private' IP's then isn't that just access-
> listed
> PI?
> 
> Please explain to me what you could do with ULA-C that you can't do
> with
> PI and an ACL.  I really want to understand.
> 
> The only possible use I can figure is so that soho router manufacturers
> can have something to hard-code in to their LAN/DHCP defaults, but even
> then there would have to be a subnet parameter passed to the router by
> DHCP unless one was going to assume that the WAN network was the entire
> PI space.
> 
> Thanks in advance for the constructive education.
> 
> Kevin
> 
> 
> 
> 
> > -----Original Message-----
> > From: Pekka Savola [mailto:[e-mail]]
> > Sent: Tuesday, June 19, 2007 2:41 PM
> > To: Jeroen Massar
> > Cc: Thomas Narten; Mark Andrews; [e-mail]
> > Subject: Re: draft-ietf-ipv6-ula-central-02.txt - reverse DNS
> >
> > On Tue, 19 Jun 2007, Jeroen Massar wrote:
> > > What is the point of that? How can a ULA address reach a global
> > > unicast address or for that matter, how is such a ULA
> > address, which
> > > is most likely going to be the sole user of those reverse servers
> > > going to contact any of the root servers, .arpa servers,
> > RIR servers
> > > etc to actually find out where that server is located in
> > the first place?
> > >
> > > Are those people going to do NAT from their ULA space? Then please
> > > directly kill this whole ULA proposal completely. If NAT is
> > involved
> > > in anyway it should never see daylight.
> >
> > I do not know the intended deployment scenarios, but in many
> > cases where I'd expect ULA-C migth be deployed, I'd expect
> > such sites to have some global addresses as well for v4, v6
> > or both (maybe at a different physical site, just for a
> > couple of infrastructure servers instead of all hosts, etc.)
> >
> > You're right that if a ULA(-C) site would have no global
> > addresses whatsoever, reverse-DNS delegations can't be done.
> >
> > --
> > Pekka Savola                 "You each name yourselves king, yet the
> > Netcore Oy                    kingdom bleeds."
> > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------


--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------