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

Brian E Carpenter <brc@zurich.ibm.com> Wed, 03 November 2004 09:13 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13654 for <ipv6-web-archive@ietf.org>; Wed, 3 Nov 2004 04:13:22 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPHS1-0006hz-0B for ipv6-web-archive@ietf.org; Wed, 03 Nov 2004 04:29:12 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPH4g-0006Bj-FC; Wed, 03 Nov 2004 04:05:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPGrM-00010i-8M for ipv6@megatron.ietf.org; Wed, 03 Nov 2004 03:51:16 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12292 for <ipv6@ietf.org>; Wed, 3 Nov 2004 03:51:14 -0500 (EST)
Received: from mtagate2.uk.ibm.com ([195.212.29.135]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPH6d-0006Ga-7m for ipv6@ietf.org; Wed, 03 Nov 2004 04:07:04 -0500
Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate2.uk.ibm.com (8.12.10/8.12.10) with ESMTP id iA38ohsl142726 for <ipv6@ietf.org>; Wed, 3 Nov 2004 08:50:43 GMT
Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iA38ohqQ037114 for <ipv6@ietf.org>; Wed, 3 Nov 2004 08:50:43 GMT
Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id iA38og8p030108 for <ipv6@ietf.org>; Wed, 3 Nov 2004 08:50:42 GMT
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id iA38ogkt030105 for <ipv6@ietf.org>; Wed, 3 Nov 2004 08:50:42 GMT
Received: from zurich.ibm.com (sig-9-145-131-110.de.ibm.com [9.145.131.110]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA59878 for <ipv6@ietf.org>; Wed, 3 Nov 2004 09:50:41 +0100
Message-ID: <41889BDE.9000101@zurich.ibm.com>
Date: Wed, 03 Nov 2004 09:50:38 +0100
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: ipv6@ietf.org
References: <200410252002.QAA29115@ietf.org>
In-Reply-To: <200410252002.QAA29115@ietf.org>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Content-Transfer-Encoding: 7bit
Subject: Re: I-D ACTION:draft-ietf-ipv6-unique-local-addr-07.txt
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "IP Version 6 Working Group \(ipv6\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Content-Transfer-Encoding: 7bit

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
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------