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

Owen DeLong owen at delong.com
Mon Apr 26 10:33:28 CDT 2010

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 at gmail.com> wrote:
>>> On Wed, Apr 21, 2010 at 5:47 PM, Mark Smith
>>> <nanog at 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.


More information about the NANOG mailing list