Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-07.txt

From: Brian E Carpenter <[email-masked]>
Date: Wed, 03 Nov 2004 09:50:38 +0100

Looking at the non-trivial bits of the change log:

>       o Changed the format in section 3.1 in add a "L" (local/central)
>         bit and reduced the size of the global-ID to 40 bits.  This is
>         equivalent to the previous separate prefixes and makes the
>         document clearer.

OK for me

>       o Changed pseudo-random algorithm to use SHA-1 instead of MD5.

OK for me

>       o Added paragraph in Routing section to discuss the use of IGPs.

Let's see:

>    For link-state IGPs, it is recommended that a site utilizing ULA
>    prefixes be contained either within one IGP domain or area.  By
>    containing a ULA prefix to a single link-state area or domain, the
>    distribution of prefixes can be controlled.

I can see why the IESG suggested this. However, I have a problem with
'recommended'. In a large enterprise network, I would expect ULAs
to be routed enterprise-wide; and when two enterprise networks merge,
I would expect *both* their ULAs to be routed throughout the combined
network. If that happens to need routing between domains/areas, so
be it. I think it would be fine if the above paragraph said 'suggested'
instead of 'recommended'.

Incidentally, I've heard that some ISPs raised philosophical objections
to ULAs at the recent ARIN meeting, on the grounds that rich customers
might force their ISPs to announce ULA prefixes as if they were PI
prefixes. I'm sorry to say it, but this is a bogus objection. If that
risk exists, it exists for provider-assigned prefixes as well, or for
a home made prefix for that matter. Also, since each ISP decides which
prefixes to filter, it's just as easy to filter ULA prefixes as any
other unwanted PI prefixes. Actually, it's easier, since they are
trivial to identify.

In this case, the interests of enterprise users have to be considered
as just as important as those of the ISPs, and ULAs are very much
needed by enterprise networks (draft-vandevelde-v6ops-nap-00.txt).

     Brian

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