Re: a draft about on-link and subnet prefixes

Alexandre Petrescu <alexandre.petrescu@gmail.com> Fri, 17 March 2017 13:34 UTC

Return-Path: <alexandre.petrescu@gmail.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 E72A4129431 for <ipv6@ietfa.amsl.com>; Fri, 17 Mar 2017 06:34:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.333
X-Spam-Level:
X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_SOFTFAIL=0.665] autolearn=no 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 Usepp2gt6vXD for <ipv6@ietfa.amsl.com>; Fri, 17 Mar 2017 06:34:47 -0700 (PDT)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2273912941C for <ipv6@ietf.org>; Fri, 17 Mar 2017 06:34:46 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v2HDYi8k047608; Fri, 17 Mar 2017 14:34:44 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4B526203034; Fri, 17 Mar 2017 14:34:44 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 39997209557; Fri, 17 Mar 2017 14:34:44 +0100 (CET)
Received: from [10.8.34.184] (is227335.intra.cea.fr [10.8.34.184]) by muguet1.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v2HDYi6A026018; Fri, 17 Mar 2017 14:34:44 +0100
Subject: Re: a draft about on-link and subnet prefixes
To: 神明達哉 <jinmei@wide.ad.jp>
References: <CAJE_bqdd9OXOi+SZ8_OfGWXxEoKSfoR6=Lp3-_=vEaWbjx4udw@mail.gmail.com> <018c1f82-cd5c-7d59-f92b-9401ddfb11fb@gmail.com> <CAJE_bqfGLngOuGzyTyRFrSOjn1kCkz3RBO0rojFCqqpYWgOZNw@mail.gmail.com> <97e0eff9-9f85-7f55-b3dc-c9b4a4b2bf62@gmail.com> <CAJE_bqexpdnrGfNkj09jv25Ng8J2MsNGVnjczM6ayeZqL2KfTA@mail.gmail.com>
Cc: IPv6 IPv6 List <ipv6@ietf.org>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <c93d109d-9337-352f-e012-a67d54ca3a69@gmail.com>
Date: Fri, 17 Mar 2017 14:34:35 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CAJE_bqexpdnrGfNkj09jv25Ng8J2MsNGVnjczM6ayeZqL2KfTA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/dXyuqHy5wDRXtyjORAR-P_h3954>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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: Fri, 17 Mar 2017 13:34:49 -0000


Le 16/03/2017 à 18:43, 神明達哉 a écrit :
[...]
>>> It's already covered in bit more generalized text:
>>>
>>> [...]  This means that, for example, if the length of interface
>>> identifiers for the link is specified as 63, 64, or 65, then the
>>>  SLAAC subnet prefix length must be 65, 64, or 63, respectively;
>>>  otherwise the PIO is ignored for the purpose of SLAAC.
>>
>> But this text does not say what is the plen of routes towards that
>>  subnet.
>
> If "routes towards that subnet" means the SLAAC subnet prefix is to
> be considered on-link, that's not what the current specs allow.

By "routes towards that subnet" I mean the entries in a routing table of
a Router that is in the path from the Internet towards that link.

> On that point RFC5942 would be a better reference.

I read this RFC 5942 "IPv6 Subnet Model".  But, just as this draft, this
RFC does not talk about the routing table entries presented in the
Routers on the path from the Internet towards that link.  Just as this
draft, that RFC talks only about the Router that is immediately
connected to that link.

>>>> However, this dichotomy has very many consequences.
>>>>
>>>> A number of RFCs and I-Ds misunderstand this dichotomy
>>>> "on-link"|"SLLAC" and make wrong recommendations.  Maybe you
>>>> want this draft to clarify all these RFCs?
>>>
>>> Which RFCs are they?  I don't intend to update any existing RFCs
>>>  in this draft, but I could refer to those RFCs as example cases
>>>  if and when I revise the draft.
>>
>> I think of the following: RFC4887 "Home network models with NEMO"
>> (it is a stretch, but HA config is impacted), RFC4903 "Multi-Link
>> Subnet Issues", RFC7278 "64share", various RFCs of Proxy Mobile IP,
>> and other recent Internet Drafts.
>
> I just took a quick look at RFC7278 (just as an example), but I
> don't find anything obvious in it that misunderstands the separation
> of on-link and SLAAC subnet prefixes (it certainly does something
> awkward if not non-compliant, like re-advertising a prefix learned
> from a 3GPP interface to a LAN interface, but such oddity is
> irrelevant to the separation of on-link and SLAAC subnet prefixes).

I agree.

I would say that using 64share is incompatible with the capability of
providing separation between onlink and SLAAC prefixes.  A prefix that
is '64shared' can not be further separated into 'onlink' and a 'SLAAC'
prefix.

Whereas a /63 prefix (not a 64shared prefix) could be divided into a /64
prefix for SLAAC, and another /64 for onlink determination.

Moreover, a prefix allocated with DHCPv6-PD could be divided into a
prefix for SLAAC and another for onlink determination.

> Can you be more specific about specifically which text of RFC7278
> misunderstand the separation?

For example this from RFC7278:
> The LAN link is configured as a /64 and the 3GPP radio interface is
> configured as a /128.

Which one of those two prefixes is the on-link and which is the SLAAC?
Maybe neither?

Maybe the /64 is for SLAAC on the LAN interface (not on the 3GPP) and it
is at the same time "on-link" for same LAN interface?

Yet one of the addresses in the /64 is for the 3GPP interface, so it is
not the entire /64 that is onlink and SLAAC.

Another example is this:
> The gateway routes the entire /64 to the UE and does not perform ND
> or Neighbor Unreachability Detection (NUD) [RFC4861].

What kind of prefix is that for which there is neither NUD nor ND
overall, yet an address is formed on the interface?  Is it SLAAC?  Is it
onlink?  Is it neither?

>> But if nobody allocates two distinct prefixes, what are the users
>> of two distinct prefixes going to use?
>>
>> Or is it just theory?
>
> Perhaps.  And I don't mind to see a discussion to challenge the need
> for the separation in the first place in case it's really only in
> theory.  I didn't intend to defend the current specification - I
> just tried to make them correctly understood.

And I appreciate the explanation.

I think it is good to have this draft.

If someone says again onlink|SLAAC dichotomy requires this or that, then
we can come to this draft and clarify whether or not it is so.

>>>>> An on-link prefix could be longer than an SLAAC subnet
>>>>> prefix.  For example, when the latter is 2001:db8:1:2::/64,
>>>>> the former could be 2001:db8:1:2:3:4::/80.
>>>>
>>>> I agree it could be.
>>>>
>>>> But in this case, one also must make sure the routing towards
>>>> that subnet is the SLAAC's /64 (not the 'onlink's /80).
>>>
>>> I don't see why.
>>
>> Because if the routing is not towards the SLAAC's /64 then the
>> following bad situation may occur:
>>
>> A computer configures an address with SLAAC /64, address that is
>> actually found on another subnet.  At that point, neighbors in
>> that other subnet will not be able to reach this computer - their
>> ND process fails and they dont ask their default router.
>>
>> In this sense the computer in question forms an address that is
>> actually not allowed to use, because there is no routing to it.
>>
>> On another hand, if the routing towards our subnet where this
>> computer is found is the /64 then the situation is better.
>>
>> onlink /80 Router  -----------Router -------------- Computer /64 in
>> rt            |       SLAAC /64 | | +----------(another subnet)
>> ----Neighbor1 | +-Neighbor2
>
> In such a case, the admin should not advertise the /80 on-link
> prefix in the first place.  If all hosts under a /64 are expected to
>  communicate directly, the admin should advertise that /64 also as
> an on-link prefix (in the above diagram we'd also need something
> other fancy stuff like multi-link subnet, ND-proxy, etc, but that's a
>  different matter).  It's just that using different on-link and
> SLAAC subnet prefixes may not meet a particular operational
> requirement - it's the admin's responsibility to choose the right
> tool and configure it correctly.

I agree.  And for 64bit IIDs the correct configuration is to have /64 in
the rt table, and /64 as both SLAAC and as onlink prefix.

>>>> In this case, one also must make sure the routing towards that
>>>>  subnet is the onlink's /48, and not the SLAAC's /64.
>>>
>>> Implementation specifics (whether it's implemented as a "route")
>>>  aside, an RFC4861-compliant host implementation should already
>>> do so.
>>
>> What I am asking stems not from implementation specifics
>> (implemented as route, or otherwise), but stems from bidirectional
>>  reachability requirements.
>>
>> The draft currently talks exclusively what happens on a link, in a
>> subnet.  But it misses to tell that whatever happens on a link, or
>> in a subnet, must ensure bidirectional rechability to and from the
>> Internet.
>
> This is vague and I'm still not sure if I really understand it. But,
> if you mean that a site using a /48 on-link subnet should advertise
> that /48 prefix via a routing protocol or something outside of the
> site, then that's correct.

I agree and I set it aside for another thread.

This is what is needed when considering dichotomy of onlink|SLAAC
prefixes.

ND and SLAAC allow for different plens for onlink determination and
SLAAC.  But routing must use the shortest of the two.

And it is the shortest of the two that constitutes a problem at this
time: it is the "/64"; those who establish routes dont make shorter than
/64.

Even if we have a concept of dichotomy onlink|SLAAC in a subnet, the 
admins of the Routers towards that subnet have a problem making 
shorter-than-64 plen routes.

Simply because there is a dichotomy does not make people making
routes make shorter-than-64 plen routes.

_If_ we said that the dichotomy onlink|SLAAC was the possibility to have
/48 as onlink and /60 as SLAAC, then the people making routes would take
the smallest (/48) and make a /48 route towards the subnet.

That comes down to the following paragraph in your draft:
> If a link-type specification defines the interface identifier length
> to be 64 bits, the SLAAC subnet prefix must be 128 - 64 = 64 bits.

should rather say "the SLAAC subnet prefix could be for example 63bit".
(that's how people do when specifying the fe80:: could be fe80:://10 in 
4291 but for Ethernet to be fe80::/64 in 2464)

Also in the place of this draft that says:
> For example, when the latter is 2001:db8:1:2::/64,
                                                ^^^^ make it 63

For you, it may be totally clear, but for others it's the 64 that is too 
obvious.

Especially for the people wondering what to put in the routing tables.

Alex

> But, to me, that's a totally different topic.
>
> -- JINMEI, Tatuya
>