Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard

Fernando Gont <fgont@si6networks.com> Sun, 26 February 2017 14:04 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D55CD1298C7; Sun, 26 Feb 2017 06:04:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCoiEo7dyAXh; Sun, 26 Feb 2017 06:04:21 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA9BB1298BB; Sun, 26 Feb 2017 06:04:21 -0800 (PST)
Received: from [192.168.3.83] (unknown [181.165.116.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 394ED8026B; Sun, 26 Feb 2017 15:04:16 +0100 (CET)
Subject: Re: Last Call: <draft-ietf-6man-rfc2460bis-08.txt> (Internet Protocol, Version 6 (IPv6) Specification) to Internet Standard
To: Sander Steffann <sander@steffann.nl>
References: <148599296506.18647.12389618334616420462.idtracker@ietfa.amsl.com> <6dbbbf7d-b3b8-0fbc-c2a3-546472925893@si6networks.com> <9B712605-E180-4F33-806F-9DC5CBAD2E31@steffann.nl> <456cf6e5-a57b-8198-4261-1ff2c0dc1e1c@si6networks.com> <86D1EAA4-237B-46E0-A766-E2D181250695@steffann.nl>
From: Fernando Gont <fgont@si6networks.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <6a49aae9-8971-3ae6-c14f-d18c140aa654@si6networks.com>
Date: Sun, 26 Feb 2017 11:03:54 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <86D1EAA4-237B-46E0-A766-E2D181250695@steffann.nl>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/2h_0Y8fFrnOYWyn1uKVa_oVjNsY>
Cc: draft-ietf-6man-rfc2460bis@ietf.org, 6man WG <ipv6@ietf.org>, ietf <ietf@ietf.org>, suresh.krishnan@ericsson.com, 6man-chairs@ietf.org
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Feb 2017 14:04:23 -0000

On 02/26/2017 10:24 AM, Sander Steffann wrote:
>>>> 2.3.  Address Type Identification
>>>> 
>>>> The type of an IPv6 address is identified by the high-order
>>>> bits of the address, as follows:
>>>> 
>>>> Address type         Binary prefix        IPv6 notation
>>>> Section ------------         -------------        -------------
>>>> ------- Unspecified          00...0  (128 bits)   ::/128
>>>> 2.4.2 Loopback             00...1  (128 bits)   ::1/128
>>>> 2.4.3 Multicast            11111111             ff00::/8
>>>> 2.6 Link-Local unicast   1111111010           fe80::/10
>>>> 2.4.6 Global Unicast       (everything else)
>>>> 
>>>> 
>>>> I wonder if this table should explicitly call out ULAs, and
>>>> provide a reference to the corresponding section.
>>> 
>>> ULAs are not an address type, they are Global Unicast. Adding
>>> them here might confuse people. And if we include ULAs then there
>>> is lots more that we should include as well. So while I
>>> understand your question, I think it would be better not to.
>> 
>> The "confusing" part is that, while globally unique, their scope is
>> not really global -- i.e., they are not meant to be globally
>> routable.
> 
> Indeed, globally unique vs globally routable. But if you go into this
> then it's more complicated than it seems. Whether something is
> routable and where are an operational choice. Companies choosing to
> interconnect might route each other's ULA space, while some of my
> RIPE NCC allocated space is not routed anywhere public. It's
> difficult to give a fixed definition that doesn't take operational
> stuff into account.

According to the definition of global scope in RFC4291, ULAs are not
really global. If they were, an ULA address should be able to uniquely
identify an interface in the whole (global) network. If anything, this
only happens "statistically".

In practice, sine 2001:db8::/16 is not routable, if your teaching a
course you'll probably use ULAs for a virtual lab. And since you copy
the same VMs to all attendees, they all end up using the same ULA
addresses. Hence their scope (within which an interface is uniquely
identified) will certainly not be global (multiple different interfaces
employ the same address at the same timeframe). :-)

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492