Subject: a draft about on-link and submit prefixes

From: 神明達哉 <[email-masked]>
Date: Mon, 13 Mar 2017 16:14:36 -0700

I've submitted a new individual draft on the separation between
on-link and (SLAAC) subnet prefixes, at the risk of stating the
obvious: https://datatracker.ietf.org/doc/draft-jinmei-6man-prefix-clarify/

In fact, it was actually too obvious to myself until a few weeks ago,
but I realized it might not be as obvious as I originally thought
through recent discussions on the wg list.  So I thought it may still
be worth clarifying explicitly.  At least I can just refer to it next
time this topic is brought up, instead of explaining it from the
scratch again.  Hopefully it's useful for some others, too.

--
JINMEI, Tatuya

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 14 Mar 2017 13:06:50 +0900

> obvious: https://datatracker.ietf.org/doc/draft-jinmei-6man-prefix-

Thanks for attempting to clarify the topic. I think it is useful to do so,
since the distinctions here are very subtle and even many in the WG (not to
mention in the IETF or in the industry) are not fully aware of their
implications.

If possible, I would suggest making this document even more general. It's
mostly geared to how implementations treat PIOs, and refers to RFC 4861 and
RFC 4862, but really I think the clarifications it makes have much broader
impact. As I see it, the core issues here are:

   - IPv6 addresses don't specify any on-link information
   - For most (but not all) unicast addresses, subnet prefixes are 64 bits
   per RFC 4291.
   - A given subnet prefix can be spread across multiple links, and a given
   link can support multiple subnet prefixes.

This is not immediately obvious to people who are familiar with the IPv4
subnet model, because it is quite different.

For example, it is an entirely valid configuration for an RA to contain a
PIO for 2001:db8::/64 A=1 L=0 and a PIO for 2001:db8::/96 A=0 L=1. In this
case, the host can form an address via SLAAC that *is not on link*. This is
a a perfectly supported configuration that has no equivalent in IPv4. In
IPv4 the subnet prefix and the onlink prefix have to match because things
wouldn't work otherwise (e.g., the broadcast address would not be on link
any more).

A corollary to the above is that subnet prefixes don't specify any on-link
information. The fact that the subnet prefix is "almost always" 64 bits
long doesn't mean that the on-link prefix cannot be /48, /89 or /120. The
fact that the on-link prefix is /120 doesn't mean that nodes on that link
have to have addresses in that /120.

---

From: [email-masked]
Date: Tue, 14 Mar 2017 08:07:39 +0100 (CET)

> subnet model, because it is quite different.

I agree that a generalization is a good idea. In particular, it would
be good to have (in one place) a definition of what an IPv6 subnet is,
especially if a subnet can be spread across multiple links (which is
*not* obvious to me from reading RFC 4861 and RFC 4862).

Steinar Haug, AS2116

---

From: [email-masked]
Date: Tue, 14 Mar 2017 09:04:33 +0100

> *not* obvious to me from reading RFC 4861 and RFC 4862).

Indeed. I think we can generalize that statement and say it is not obvious in general.

There were proposals around multi-link subnets:
https://tools.ietf.org/html/draft-thaler-ipngwg-multilink-subnets-02

Which pretty quickly decayed into implementing a spanning tree in ND and flooding DAD messages.

The remnants of that you can find in proxy RA and DAD proxy work.

I would suggest that redefining existing terms to be able to shoe-horn in a 64 bit boundary isn't helpful.

Best regards,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 14 Mar 2017 09:47:49 +0100

I suggest adding the following upfront:

"The onlink|SLAAC dichotomy MAY be applied; if it is applied, then the
  routing towards that subnet MUST use the shortest plen of the two"

E.g. if the on-link prefix is 48 and the SLAAC prefix is 64 then the 48 
(not the 64) must be in the rt tables of routers with routes towards 
that subnet.

Le 14/03/2017 à 00:14, 神明達哉 a écrit :
> obvious:
> https://datatracker.ietf.org/doc/draft-jinmei-6man-prefix-clarify/

I have read the draft.  It was a good read, thank you.  It clarifies the 
difference between on-link prefixes and SLAAC prefixes.

Here are my comments in summary:

1. It does not resolve the question of whether or not the 64bit IID
    should be required in the IPv6 Addressing Architecture.

    We can't require all IIDs be 64bit (for SLAAC) and rely on non-64
    on-link prefixes at times.  There is no recommendation about how to
    make that work, and intuitively it is prone to error.  An example is
    needed picturing how the dichotomy can work.

2. The explanation of the dichotomy onlink|SLAAC should be accompanied
    by a recommendation of using the shortest plen of the two (even when
    that plen is not 64) in the Internet routing setup towards that
    subnet.  This is the crux of it.

    This recommendation should acknowledge that when that plen is larger
    than 64, SLAAC/Ethernet can not work.

    This recommendation should acknowledge that when that plen is smaller
    than 64, SLAAC/Ethernet can work by using 64 for SLAAC and plen for
    on-link determination.

3. The draft would benefit from dealing with LL addresses too.

Details below:

> Although this misunderstanding would normally not cause troubles in
> practical deployments, it can be a source of operational surprise or
>  interoperability problems once an administrator wants to exploit the
>  idea of this separation more "creatively".

This needs the administrator to have ability to set distinct routes
towards presumably distinct 'on-link' and SLAAC prefixes.

> For brevity, this document focuses on global unicast prefixes.
> Discussions on any other types of prefixes, including unicast link-
> local prefixes, are out of scope of this document.

<LL>

If one tries to bring the LL prefixes in the picture then the
perspective may change.

Let me explain why:

The LL prefix is not present in RA, there is no 'L' nor 'A' bits to
check, yet LL is "on-link" prefix and it is used to auto-configure an
Address.

So, your definition of an "on-link" prefix being "A prefix advertised in
an RA PIO with the L flag being set." is incomplete.

The right definition of an "on-link" prefix should be:
> A prefix advertised in an RA PIO with the L flag being set, or a
> prefix starting with fe81:://10.

and, similarly:
> SLAAC subnet prefix  - A prefix advertised in an RA PIO with the A
> flag being set, or a prefix starting with fe82:://10.

Further, when the draft says:
> It may also be worth noting that an SLAAC subnet prefix is not
> directly related to the "subnet prefix"

it is wrong.  It should say:
> It may also be worth noting that, with the exception of LL prefix, an
> SLAAC subnet prefix is not directly related to the "subnet prefix"
> (i.e. an LL prefix _is_ directly related to the "subnet prefix").

That goes for many other such statements.  Each should be qualified by
LL.  And if we do so, then this dichotomy may appear less obvious.
There is always this LL exception.

</LL>

> [RFC4861] and [RFC4862] intentionally separate the concept and
> handling of on-link prefixes and SLAAC subnet prefixes, even when
> they are specified in the same single PIO.

I agree with this dichotomy.  It is a tool that can be used to do
sophisticated configs in an IPv6 subnet.  Similar configs can be
achieved in IPv4 as well.  (there is equivalency between
1:1::/63   "connected" in rt and 1:1::1/64 on the iface, and
1.1.0.0/23 "connected" in rt and 1.1.0.1/24 on the iface)

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?

One of the worst consequence is the allocation of single /64 prefix for
an end user.  Many drafts and their respective deployments only give a
/64 to the end user: it is used both for SLAAC _and_ for on-link
determination.  If they agreed the dichotomy then they would give at
least two distinct prefixes to the end-user: one for SLAAC and one for
on-link determination.

Another consequence is the possibility to make wrong configurations.

A wrong configuration is the following: in a subnet where plen1 is for
on-link determination and plen2 is for SLAAC, it is easily possible to
make a Host believe a Neighbor is on-link whereas the routing system to
which that subnet is connected routes to another subnet for same Neighbor.

If somebody plays too much with this plen1 and plen2 configurations
(onlink|SLAAC) on a subnet one can easily make mistakes.  There is no
recommendation how to avoid these mistakes.

Recommendations about how to play with this onlink|SLAAC dichotomy will
need to take into account how routing is based on longest-prefix match.

Also these recommendations must make sure that allocating a
single /64 to an end user does not get into widespread use.

> Perhaps the administrator of the link wanted to force most of on-link
> communication to 2001:db8:1:2::/64 to be first sent to a default
> router, while allowing a particular set of hosts (those using the
> address that match the on-link prefix) to communicate directly.

I agree with the use-case.

But maybe the administrator should know too that the default router will 
reply back with an ICMP Redirect leading to an end result where the 
on-link prefix is same as the SLAAC prefix in the rt table.

Also, the administrator should know that same effect (force traffic to 
the defrouter, instead of directly to neighbors) is achieved by using 
ptp links.  This also avoids ICMP Redirect, and thus permanently 
maintain this "through-defrouter" path, instead of momentarily.

>    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).

>    An on-link prefix could also be shorter than an SLAAC subnet prefix.
>    For example, when the latter is 2001:db8:1:2::/64, the former could
>    be 2001:db8:1::/48.

I agree it could be.

In this case, one also must make sure the routing towards that subnet is 
the onlink's /48, and not the SLAAC's /64.

Lacking of saying so leads to the undesirable situation of operators 
allocating a /64 for a ptp link.

To combine the two, a recommendation would be:

"The onlink|SLAAC dichotomy may be applied only if the routing towards
  that subnet uses the shortest plen of the two; that could be a value 
less than 64."

Alex

---

From: Tim Chown <[email-masked]>
Date: Tue, 14 Mar 2017 09:30:39 +0000

> On 14 Mar 2017, at 07:07, [email-masked] wrote:
> 

I like this idea. Examples along the lines that Lorenzo included in his email would also be useful to include, with notes on use cases.

Tim

---

From: [email-masked]
Date: Tue, 14 Mar 2017 11:48:38 +0100

> I like this idea. Examples along the lines that Lorenzo included in his email would also be useful to include, with notes on use cases.

Any idea of what problem we're trying to solve...?

Ole

---

From: Tim Chown <[email-masked]>
Date: Tue, 14 Mar 2017 10:57:21 +0000

Hi,

> On 14 Mar 2017, at 10:48, [email-masked] wrote:
> 

I think it’s adding Informational clarity, especially for those familiar with thinking ’the IPv4 way’, without adding unnecessary wordage directly to 4291-bis.  

Tim

---

From: [email-masked]
Date: Tue, 14 Mar 2017 12:03:53 +0100

> I think it’s adding Informational clarity, especially for those familiar with thinking ’the IPv4 way’, without adding unnecessary wordage directly to 4291-bis.

Right, that was what I feared.
Including esoteric examples and examples bordering on configuration errors, just isn't going to add clarity in my opinion.

Ole

---

From: [email-masked]
Date: Tue, 14 Mar 2017 13:26:40 +0100 (CET)

> Including esoteric examples and examples bordering on configuration errors, just isn't going to add clarity in my opinion.

Could an IPv6 subnet be defined *without esoteric examples*?

If not - maybe the IPv6 subnet concept is too complex to be useful?

Just asking...

Steinar Haug, AS2116

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 14 Mar 2017 21:48:44 +0900

> If not - maybe the IPv6 subnet concept is too complex to be useful?

Let's go back to IPv4, it's easy to understand.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 14 Mar 2017 13:50:23 +0100

Le 14/03/2017 à 13:48, Lorenzo Colitti a écrit :
> On Tue, Mar 14, 2017 at 9:26 PM, <[email-masked]
> <mailto:[email-masked]>> wrote:
>

Not that either.

Simpler is better.  If simpler could only be other-than-64...

Alex

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

---

From: [email-masked]
Date: Tue, 14 Mar 2017 14:20:23 +0100 (CET)

> Let's go back to IPv4, it's easy to understand.

I hope it's possible to ask for clarifications of the IPv6 subnet model
without returning to IPv4.

I haven't seen a definition of what an IPv6 subnet is. I specifically
haven't seen where it is defined that a given subnet prefix can be
spread across multiple links - especially since RFC 4291 says

"Currently, IPv6 continues the IPv4 model in that a subnet prefix is
associated with one link."

So if this is no longer the case (just like it's not the case that all
IPv6 netmasks are /64 or /127) then it is useful to have this defined
somewhere.

Steinar Haug, AS2116

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Mar 2017 04:32:05 +1300

> Including esoteric examples and examples bordering on configuration errors, just isn't going to add clarity in my opinion.

I think we have no idea yet what the flexibility of IPv6 is going to allow
people to do in future. By the time our descendants get around to
delegating e000::/3 things may look very esoteric indeed. But for now,
I think what jinmei proposes is a good idea - it is completely clear from
the recent discussions that some clarification is needed.

   Brian

---

From: Havard Eidnes <[email-masked]>
Date: Tue, 14 Mar 2017 18:30:01 +0100 (CET)

>>>> I like this idea. Examples along the lines that Lorenzo
>>>> included in his email would also be useful to include, with
>>>> notes on use cases.
>>> 
>> I think it’s adding Informational clarity, especially for
>> those familiar with thinking ’the IPv4 way’, without adding
>> unnecessary wordage directly to 4291-bis.
> 
> Including esoteric examples and examples bordering on
> configuration errors, just isn't going to add clarity in my
> opinion.

I disagree.  Making a clarification implies delineating the border,
and not neccessarily describing the typical situation or usage.  By
necessity you will have to find edge cases along the border.

Do you think there's something which is factually or technically
inaccurate in the draft Jinmei posted?  Do you think some of the
setups which are described are still "within the border" of what's
described in the stadnards but should not be?

It may not be pretty, but it's perhaps time to own up to what we've
begat?

Regards,

- Håvard

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 14 Mar 2017 17:55:05 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Brian E Carpenter

> But for now, I think what jinmei proposes is a good idea - it is completely
> clear from the recent discussions that some clarification is needed.

+1

I found Jinmei-san's I-D to be quite clear and to the point. Not sure I would muddy it up with too many specific examples, of too many corner cases. What is in there now is factual, and clearly expressed. Going off on tangents will create endless debates as to whether some corner case is a misconfiguration or not, intended by the Founding Fathers or not, and just prolong the misconceptions about a rigid 64-bit boundary.

Bert

---

From: 神明達哉 <[email-masked]>
Date: Tue, 14 Mar 2017 11:26:41 -0700

At Tue, 14 Mar 2017 13:06:50 +0900,

> mention in the IETF or in the industry) are not fully aware of their

Thanks for reading the draft and for the prompt feedback.

> impact. As I see it, the core issues here are:

I see the possibility of generalization.  In particular, we could
generalize the term/concept of "subnet prefix" so that it doesn't
limit the context to SLAAC.  At least in the initial version of the
draft, however, I intentionally focused on the prefixes advertised via
PIOs in order to avoid distraction or unnecessary controversy from the
primary clarification I wanted to make first (which itself was deemed
to be sufficiently subtle).  If others also think it helpful to
generalize the discussion as a continuation of this draft, I'm happy
to revise the draft that way.

>    - IPv6 addresses don't specify any on-link information

This one actually seems to be covered by RFC5942 (although it's a
different question whether it's well understood and/or whether a
further clarification attempts help).

>    - For most (but not all) unicast addresses, subnet prefixes are 64 bits

I'm not sure if this is directly relevant to the separation of on-link
and subnet prefixes.

>    link can support multiple subnet prefixes.

Same for the latter.  I see the former is related to the fact that
on-link prefixes are independent from subnet prefixes, but I'm not so
sure if this will be in the scope of "generalized clarification".

--
JINMEI, Tatuya

---

From: james woodyatt <[email-masked]>
Date: Tue, 14 Mar 2017 12:19:39 -0700

Hi everyone,

First, my thanks to Jinmei-san for this well-written draft. I have only minor quibbles with it, most of which were already surfaced by Lorenzo, and the rest are probably nits not worth mentioning at this point.

I’d like to respond to a comment that came in the ensuing discussion. I think it’s relevant.

> IPv6 netmasks are /64 or /127) then it is useful to have this defined

p1. In my proposal for additional text in revising RFC 4291, I noted that the sentence highlighted above is a) superseded by The IPv6 Subnet Model [RFC5942], which coincidentally provides a definition of an IPv6 subnet in section 1, and b) I offered an alternative formulation of that text with the statement updated to match current reality accordingly.

p2. A fine example of an existing technology where a subnet is shared across multiple links is "Extending an IPv6 /64 Prefix from a Third Generation Partnership Project (3GPP)  Mobile Interface to a LAN Link” [RFC7278]. Another that comes to mind is a certain application of "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks” [RFC6282] at HOMENET routers connected to residential LAN networks behind IPv6 Customer Edge Routers that implement "Basic Requirements for IPv6 Customer Edge Routers” [RFC7084].

Clearly, that sentence in RFC 4291 highlighted above, which persists in the latest draft of I-D.ietf-6man-rfc4291bis too, is a source of confusion. We have published many RFCs, several of them in the Standards Track, that conflict absolutely with that statement. It’s definitely not an accurate statement anymore, if it ever was.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 14 Mar 2017 18:54:59 -0400

Lorenzo Colitti <[email-masked]> wrote:
    > * IPv6 addresses don't specify any on-link information

    > * For most (but not all) unicast addresses, subnet prefixes are 64
    > bits per RFC 4291.
    > * A given subnet prefix can be spread across multiple links, and a
    > given link can support multiple subnet prefixes.

Is it reasonable for some routers to RA for a PIO as on-link on some
interfaces/ports, and not on others?   I think that this doesn't work unless
you mix in some kind of proxy-ND.

My goal in asking this is to reduce some of the pushback from the reasonable
proposal (in other places, such as homenet) that home wifi not be bridged to
wired, and that different frequencies should have their own prefixes.

The alternative is that all interfaces get not-on-link, and we manage /128
routes, which seems slightly dumb to do on the wired side.

    > A corollary to the above is that subnet prefixes don't specify any
    > on-link information. The fact that the subnet prefix is "almost
    > always" 64 bits long doesn't mean that the on-link prefix cannot be
    > /48, /89 or /120. The fact that the on-link prefix is /120 doesn't
    > mean that nodes on that link have to have addresses in that /120.

Can we do something useful with this?
It seems to me that with DHCPv6 doing assignment, that we could.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 14 Mar 2017 19:01:03 -0400

> associated with one link."

My goal is to get rid of layer-2 games; most of which were caused by lack of
subnets in IP4b., They have become huge un-seeable/un-traceable protocols
stacks of various kinds of poorly implemented STP.

v6 prefixes are plentiful, and we should use them... but we haven't found
"the" solution to discovery across subnets, and haven't made side-wide
multicast work easily, so we are doing site-wide discovery via other methods.

So, many want to keep bridging networks with 1000:1 bandwidth ratios
(GbE vs -70dbm wifi at 1Mb/s... )

Maybe there are some happy middle ground that comes from the revelation
that subnets != links.

---

From: 神明達哉 <[email-masked]>
Date: Tue, 14 Mar 2017 17:08:34 -0700

At Tue, 14 Mar 2017 09:47:49 +0100,

> (not the 64) must be in the rt tables of routers with routes towards

Thanks for the feedback.  I'm not sure how to interpret this, but in
any event, adding a new MAY or MUST is clearly out of scope of this
draft.  It only intends to explain what the current specifications try
to specify in case it may no be very clear.

>     should be required in the IPv6 Addressing Architecture.

No it doesn't, and it's intentional.

>     subnet.  This is the crux of it.

I'm not sure what this means.

>     than 64, SLAAC/Ethernet can not work.

There's no recommendation in this draft; it only talks about facts.
Anyway, it's true that if (SLAAC subnet) plen is larger (or shorter)
than 64 SLAAC over Ethernet does not work.  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.

>     than 64, SLAAC/Ethernet can work by using 64 for SLAAC and plen for

I'm not sure what this means.  But, as long as the current
specifications go, SLAAC doesn't work on Ethernet if the subnet prefix
is smaller (or larger for that matter) than 64.  If you are trying to
propose loosening it, that's fine - please write a proposal in a
separate draft.  But that's out of scope of this draft, which only
talks about what current standards state.

> 3. The draft would benefit from dealing with LL addresses too.

Perhaps, but I intentionally made it more focused to avoid
distraction, at least for the 00 version.

> > local prefixes, are out of scope of this document.

I'll skip any LL-specific discussion to avoid distraction.  If and
when we see the need to cover this topic within this draft, I'll come
back to these points.

> > they are specified in the same single PIO.
[...]
> and make wrong recommendations.  Maybe you want this draft to clarify

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.

> least two distinct prefixes to the end-user: one for SLAAC and one for

Perhaps, but such a discussion is out of scope of this draft.

> single /64 to an end user does not get into widespread use.

Ditto.

> on-link prefix is same as the SLAAC prefix in the rt table.

Yes (although the admin would disable sending redirects if this is
really the operation they want and their router supports the knob),
that's why the draft says "first sent to a default router".  Anyway,
as admitted this is an imaginary use case.  I didn't intend to insist
that's necessarily realistic.

> subnet is the SLAAC's /64 (not the 'onlink's /80).

I don't see why.

> 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.

>   that subnet uses the shortest plen of the two; that could be a value

(Aside from whether this makes sense or not) again, there's no
recommendation in this draft.  It only explains what current protocol
specifications state, just more explicitly.

--
JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 16 Mar 2017 12:02:54 +0100

> to specify in case it may no be very clear.

The explanation may be better if it also illustrated some of the 
side-effects.  One side-effect of using distinct on-link|SLAAC prefixes 
is that the routing towards that subnet has a particular plen.

> No it doesn't, and it's intentional.

Ok, this is good to know.

It is the most important point why I got in this discussion.

So, it is not because the onlink|SLAAC prefixes may be distinct that the 
4291 would recommend 64bit IIDs.  There may be other reason.

> I'm not sure what this means.

It means that in order to have distinct onlink|SLAAC prefixes one has to 
have distinct routing towards that subnet too.

> than 64 SLAAC over Ethernet does not work.

Ok

>  It's already covered in

But this text does not say what is the plen of routes towards that subnet.

> talks about what current standards state.

Noted.

[...]
> this draft, but I could refer to those RFCs as example cases if and

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.

> Perhaps, but such a discussion is out of scope of this draft.

But if nobody allocates two distinct prefixes, what are the users of two 
distinct prefixes going to use?

Or is it just theory?

>> single /64 to an end user does not get into widespread use.

Well... ok.

> that's necessarily realistic.

Ok.

>> subnet is the SLAAC's /64 (not the 'onlink's /80).

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

> 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.

> specifications state, just more explicitly.

Ok, noted.

Alex

---

From: 神明達哉 <[email-masked]>
Date: Thu, 16 Mar 2017 10:43:58 -0700

At Thu, 16 Mar 2017 12:02:54 +0100,

> have distinct routing towards that subnet too.

I'm still not sure how to interpret it, but I guess it's related to
the discussion on cases of /64 SLLAC subnet and /80 on-link prefixes,
below.  So I'll defer it to that part.

> 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.  On that
point RFC5942 would be a better reference.

> Issues", RFC7278 "64share", various RFCs of Proxy Mobile IP, and other

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).  Can you be more
specific about specifically which text of RFC7278 misunderstand the
separation?

> distinct prefixes going to use?

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.

>                         +----------(another subnet) ----Neighbor1

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.

> 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.  But, to me, that's a totally different
topic.

--
JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 17 Mar 2017 14:34:35 +0100

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.
>>
> 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.

>>>> 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?
>
> 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:
>>
>> 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.
>>
>> 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.
>
> 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
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 17 Mar 2017 15:02:27 +0100

> 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.  But, to me, that's a
> totally different topic.

Let me say it is the same topic.

Because at a point in the draft you say:
> For example, the fact that the length of an on-link prefix can be
> 48, 80 or other bits is not contradictory to the fact that [RFC4291]
> states the interface identifiers (and therefore subnet) of a
> particular set of addresses are 64 bits in length.  Only SLAAC
> subnet prefixes have an indirect implication with the addressing
> architecture as noted in Section 2.

To stress this agreement, it is possible to write it in relationship to 63.

We agreed earlier that what's important for routing is the shortest 
prefix between the onlink and the SLAAC prefix.

The dichotomy onlink|SLAAC could support a recommendation of larger than
63bit IIDs _only_ if the onlink prefix were shorter than or equal to 63.

Something like:
"When the dichotomy onlink|SLAAC is in place [ref], and the onlink
  prefix is shorter than or equal to 63, the Interface ID of unicast
  addresses can be longer than 63; also see IPv6-over-foo refs".

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 18 Mar 2017 03:17:26 +1300

>   addresses can be longer than 63; also see IPv6-over-foo refs".

Why would you ever need to write that? *By definition*, (prefix length) + (IID length) == 128.

The so-called "dichotomy" doesn't affect this identity at all.

   Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 17 Mar 2017 15:58:00 +0100

Le 17/03/2017 à 15:17, Brian E Carpenter a écrit :
>> Le 16/03/2017 à 18:43, 神明達哉 a écrit : [...]
>>> For example, the fact that the length of an on-link prefix can
>>> be 48, 80 or other bits is not contradictory to the fact that
>>> [RFC4291] states the interface identifiers (and therefore subnet)
>>> of a particular set of addresses are 64 bits in length.  Only
>>> SLAAC subnet prefixes have an indirect implication with the
>>> addressing architecture as noted in Section 2.
>>
>> The dichotomy onlink|SLAAC could support a recommendation of larger
>> than 63bit IIDs _only_ if the onlink prefix were shorter than or
>> equal to 63.
>>
>> Something like: "When the dichotomy onlink|SLAAC is in place [ref],
>> and the onlink prefix is shorter than or equal to 63, the Interface
>> ID of unicast addresses can be longer than 63; also see
>> IPv6-over-foo refs".
>

prefix len + IID len == 128 does not mean a certain part must be 64, and 
that is good.

It does however mean that when IID len is 63 the prefix len must be 65; 
that is not good because it does not consider "dichotomy" between onlink 
prefix and SLAAC prefix.

> The so-called "dichotomy" doesn't affect this identity at all.

The "dichotomy" concept implies that if the IID is 65, the SLAAC prefix 
must be 63 yet the onlink prefix could be 60.

I.e. onlink plen < SLAAC plen
      &&
      SLAAC plen + IIDlen == 128.

Alex

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

---

From: 神明達哉 <[email-masked]>
Date: Fri, 17 Mar 2017 14:12:46 -0700

At Fri, 17 Mar 2017 14:34:35 +0100,

> a Router that is in the path from the Internet towards that link.

I now understand you're more concerned about those configuration
matters.  But I have to say that's out of scope of my draft.  It
basically talks about host behaviors regarding on-link and subnet
prefixes.  You may not like the scope, but I have no plan to broaden
it to that direction (I basically want to keep it focused).  If you
think that's an important topic, my last word on that point in this
thread is this famous phrase: feel free to write your own draft on
that topic.  (Below I'm basically skipping points relevant to this
particular point.)

> prefix for SLAAC and another for onlink determination.

I don't see how this is relevant to this draft.

> > The LAN link is configured as a /64 and the 3GPP radio interface is

This behavior (using an RA on an interface/link than the received one,
re-advertising a received RA on the other link) itself is already
quite peculiar, but I still don't see confusion between on-link and
SLAAC subnet prefixes here.

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

Ignoring the peculiarity, the UE performs SLAAC with the received /64
prefix and generates a 128-bit IPv6 address
2001:db8:ac10:f002:1234:4567:0:9.  So this /64 is an SLAAC subnet
prefix.  The /128 notation simply means it's a 128-bit IPv6 address.
When re-advertising the /64 to the LAN interface, while it's not
really clear from the RFC text itself, but I guess it usually has both
the L and A flags set, so they would be used both as an SLAAC subnet
and on-link prefixes.

> overall, yet an address is formed on the interface?  Is it SLAAC?  Is it

neither.

> should rather say "the SLAAC subnet prefix could be for example 63bit".

It couldn't, unless we update RFC4862 as such.  I don't even
understand how the external route setup affects the length of
interface identifiers, but even if there's some sensible explanation
of it, that doesn't change the fact that RFC4862 doesn't allow an
SLAAC subnet prefix to be other than 64 when the length of IID is 64.
If you don't like the current protocol limitation, that's fine -
please write a new proposal to update RFC4862.  But that's out of
scope of this draft: it only explains what's current specified without
stating that's good or bad.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Fri, 17 Mar 2017 14:39:14 -0700

At Fri, 17 Mar 2017 15:58:00 +0100,

> It does however mean that when IID len is 63 the prefix len must be 65;

To be very precise: when IID len is 63, an "SLAAC subnet" prefix len
must be 65 (but an on-link prefix len doesn't have to be so).

> that is not good because it does not consider "dichotomy" between onlink

I don't understand what this "consider" means, but the combination of
IID len=63, SLAAC subnet prefix len=65, on-link prefix len=60 is
totally valid (whether or not it's useful in practice).  That's
basically all my draft tries to explain.

> must be 63 yet the onlink prefix could be 60.

Right, and that's valid as noted above.

I'm feeling I now have to give up understanding what you're trying to
say...I'll basically stop responding at this point.

--
JINMEI, Tatuya

---

From: [email-masked]
Date: Fri, 17 Mar 2017 23:20:17 +0100

Alexandre,

it is a little hard to understand what you want to achieve with your messages.
if you want something explained, perhaps we should sit down in Chicago.
if you want to have something changed, please write a draft and explain your proposal and your ideas.

Best regards,
Ole

---

From: Mark Smith <[email-masked]>
Date: Sat, 18 Mar 2017 09:24:06 +1100

> say...I'll basically stop responding at this point.

I too don't really understand the point of having an IID that is less
bits than the prefix length. I'm also not quite sure what it actually
would be in practice.

In practice, would it be e.g.,?

- router interface assigned 2001:db8::1/60

- RA PIO 2001:db8::/64, A=1, L=1

As far as I can see, the bits between the /60 and /64 are wasted, as
they're serving no purpose. It would also cause the host to believe
that destinations outside the /64 but within the /60 are off-link (if
there actually are any destinations), where in reality they're
probably directly reachable over the link, rather than the traffic
having to be hair-pinned through the router.

I'm not sure there is much value exploring and explaining valid but in
practice configurations that would cause more confusion than any
operational value they could provide. (I'm reminded of IPv4 subnet
masks, prior to CIDR, that could have non-contiguous 1 bits.
Interesting in theory, operationally terrible in practice.)

Regards,
Mark.

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 18 Mar 2017 10:39:49 +0100

Supposedly, as we speak, there is some decision pondered over, about 
recommending (or not) 64bit IIDlens in 4291bis.

In making that decision, the onlink|SLAAC distinction should have no 
role.  It is not an indicator striking a balance either way.

Alex