Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT)

From: Warren Kumari <[email-masked]>
Date: Mon, 4 Sep 2017 17:43:12 -0400

I'd like to note that that there is continuing discussion on this
draft on the v6 ops list (yup, after WGLC and IETF LC :-)). I've only
been able to somewhat monitor it, but have asked the v6ops chairs for
input. Much of the discussion has been interesting, but not
necessarily pertaining exactly to this document.
Fred kindly asked the list:
https://mailarchive.ietf.org/arch/msg/v6ops/bpEDtnYkbvJQZAx_r6mtEhdNxrw
for anything substantive for the document (keeping in mind that it has
already gone through WGLC and IETF LC).

So far it doesn't seem like there are any other major changes needed,
other than "asking that the applicability comment that communication
between such nodes on a LAN should go through a connecting router
(which seems to me a given due to the relationship with routing)
should be documented." and David Farmer's followup --
https://mailarchive.ietf.org/arch/msg/v6ops/_-QlBqGk9dChoFOhxigf5WlxYDY

Does anyone have anything else *substantive*? If so, I may have to
kick this back to the WG for another round.

W

On Tue, Aug 22, 2017 at 7:31 PM, Suresh Krishnan
<[email-masked]> wrote:
> Hi Gunter,
>   Thanks for the proposed text changes. They adequately address my DISCUSS
> points. I am hoping you will also converge in the discussion with Lorenzo on
> the actual value for the timer and/or specify an applicability statement. I
> will clear once the new revision posts.
>
> Regards
> Suresh
>
> On Aug 21, 2017, at 8:57 AM, Van De Velde, Gunter (Nokia - BE/Antwerp)
> <[email-masked]> wrote:
>
> Hi Suresh,
>
> Many thanks for the review and finding these issues. What do you think of
> the proposals below to fix those points of attention?
>
>    ----------------------------------------------------------------------
>    DISCUSS:
>    ----------------------------------------------------------------------
>
>    * Section 4
>
>    It is not clear what you intend here
>
>    "IPv6 Router Advertisement Interval = 300s"
>
>    The router advertisement interval is not configured as an absolute value
> but as
>    minimum and maximum bounds (MinRtrAdvInterval and MaxRtrAdvInterval)
> which are
>    used to calculate the actual advertisement interval. When the RA is sent
> from
>    an interface, the actual interval is an uniformly distributed random
> value
>    between the MinRtrAdvInterval and MaxRtrAdvInterval. At the very minimum
> you
>    need to clarify if you would like to have this as a lower bound or as an
> upper
>    bound.
>
> GV> I changed the line to make it more clear that the timer indicates the
> maximum Advertisement Interval
> GV>          <t>Maximum IPv6 Router Advertisement Interval = 300s</t>
>
>    ----------------------------------------------------------------------
>    COMMENT:
>    ----------------------------------------------------------------------
>
>    * Section 4
>
>    -> I think text is needed here to handle the case where the DNS server is
>    provided in the RA itself  (RFC8106)
>
>    "In addition it will use stateless DHCPv6 to get the IPv6 address of the
> DNS
>    server"
>
>    -> I am not sure what is the motivation for this text.
>
>    "however it SHOULD NOT use stateful DHCPv6 to receive a service provider
>    managed IPv6 address"
>
>    -> This text seems incorrect
>
>    "due to the L-bit set, it SHOULD send this traffic to the First Hop
> Provider
>    Router"
>
>    I think it should be the exact opposite. i.e. say *unset* instead of set
>
>    "due to the L-bit being unset, it SHOULD send this traffic to the First
> Hop
>    Provider Router"
>
> GV> What about the following modification in the text:
>
> OLD:
> The architected result of designing the RA as documented above is
>   that each UE/subscriber gets its own unique IPv6 prefix for which it
>   can use SLAAC or any other method to select its /128 unique address.
>   In addition it will use stateless DHCPv6 to get the IPv6 address of
>   the DNS server, however it SHOULD NOT use stateful DHCPv6 to receive
>   a service provider managed IPv6 address.  If the UE/subscriber
>   desires to send anything external including other UE/subscriber
>   devices (assuming device to device communications is enabled and
>   supported), then, due to the L-bit set, it SHOULD send this traffic
>   to the First Hop Provider Router.
>
> New:
> The architected result of designing the RA as documented above is
> that each UE/subscriber gets its own unique IPv6 prefix for which it
> can use SLAAC or any other method to select its /128 unique address.
> Either stateless DHCPv6 <xref target="RFC3736">RFC3736</xref> or IPv6
> Router Advertisement Options for DNS Configuration
> <xref target="RFC8106">RFC8106</xref> can be used to get the
> IPv6 address of the DNS server. If the UE/subscriber desires to send
> anything external including other UE/subscriber devices (assuming device
> to device communications is enabled and supported), then, due to the
> L-bit being unset, it SHOULD send this traffic to the First Hop Provider
> Router.</t>
>
>
>
> Kind Regards,
> G/
>
>

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 5 Sep 2017 10:32:59 +1200

Warren,

I believe it's substantive that the text refers to sending unicast
RAs without clarifying whether this means that they are sent
with a unicast layer 2 address and a multicast layer 3 address
(as per RFC6085) or that they are sent with both layer 2 and
layer 3 addresses being unicast. At the moment, an implementer
has to decide which of these is intended. If either is OK,
that could be stated too.

Specifically this clarification seems to be needed right after:

> 4.  IPv6 Unique Prefix Assignment
> 
>    When a UE connects to the shared provider managed network and is
>    attached, it will initiate IP configuration phase.  During this phase
>    the UE will, from an IPv6 perspective, attempt to learn the default
>    IPv6 gateway, the IPv6 prefix information, the DNS information
>    RFC8106 [RFC8106], and the remaining information required to
>    establish globally routable IPv6 connectivity.  For that purpose, the
>    the UE/subscriber sends a RS (Router Solicitation) message.
> 
>    The First Hop Router receives this UE/subscriber RS message and
>    starts the process to compose the response to the UE/subscriber
>    originated RS message.  The First Hop Provider Router will answer
>    using a unicast RA (Router Advertisement) to the UE/subscriber.

Regards
   Brian Carpenter

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 5 Sep 2017 14:52:45 +0000

Hi Warren,

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Warren Kumari
> Sent: Monday, September 04, 2017 2:43 PM
> To: Suresh Krishnan <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>; The IESG <[email-masked]>
> Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT)
> 

Yes, my substantive comments are found here and as given below:

https://www.ietf.org/mail-archive/web/v6ops/current/msg27499.html

Thanks - Fred
[email-masked]

---
1) In section 2:

    " o  Two devices (subscriber/hosts), both attached to the same provider
       managed shared network should only be able to communicate through
       the provider managed First Hop Router"
 
Please change to say:
 
    "o  Two devices (subscriber/hosts), both attached to the same provider
       managed shared network should only be able to communicate through
       the provider managed First Hop Router unless the shared network
       explicitly permits peer-to-peer operations"

2) In Section 4:

  " If the UE/subscriber
   desires to send anything external including other UE/subscriber
   devices (assuming device to device communications is enabled and
   supported), then, due to the L-bit set, it SHOULD send this traffic
   to the First Hop Provider Router."

Please change to:

    "If the UE/subscriber
   desires to send anything external including other UE/subscriber
   devices (assuming device to device communications is enabled and
   supported), then, due to the L-bit set, it SHOULD send this traffic
   to the First Hop Provider Router unless the shared network
   explicitly permits peer-to-peer operations."

---

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 6 Sep 2017 00:18:45 +0900

>        explicitly permits peer-to-peer operations"

AIUI this opinion is in the rough.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 5 Sep 2017 16:02:07 +0000

Lorenzo,

On shared media, unless there is some form of L2 partitioning peer-to-peer is
possible even if there are no Redirects. I can simply call up my neighbor on the
phone and ask for their MAC address, then we can do peer-to-peer without
even needing any coordination with the router.

So, the document either needs to talk about L2 partitioning or acknowledge
that (on some link types) peer-to-peer is inevitable. I prefer the latter because
peer-to-peer provides a necessary optimization on some link types.

Thanks - Fred

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Tuesday, September 05, 2017 8:19 AM
To: Templin, Fred L <[email-masked]>
Cc: Warren Kumari <[email-masked]>; Suresh Krishnan <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]>; The IESG <[email-masked]>
Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT)

On Tue, Sep 5, 2017 at 11:52 PM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
Please change to say:

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 6 Sep 2017 01:29:41 +0900

> peer-to-peer provides a necessary optimization on some link types.

Partitioning is in the applicability statement.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 5 Sep 2017 16:37:12 +0000

Hi Lorenzo,

I don’t see anything about L2 partitioning anywhere in the document. And, if there
is no L2 partitioning then peer-to-peer is possible even if the document says hosts
“should” go through a default router.

This is a fact (not an opinion) that the document needs to address.

Thanks - Fred

Sent: Tuesday, September 05, 2017 9:30 AM

On Wed, Sep 6, 2017 at 1:02 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
So, the document either needs to talk about L2 partitioning or acknowledge
that (on some link types) peer-to-peer is inevitable. I prefer the latter because
peer-to-peer provides a necessary optimization on some link types.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 5 Sep 2017 18:59:25 +0200 (CEST)

So while this says they should be isolated, I think this text could be 
made clearer.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 5 Sep 2017 17:40:21 +0000

Hi Mikael,

> From: Mikael Abrahamsson [mailto:[email-masked]]
> Sent: Tuesday, September 05, 2017 9:59 AM
> Cc: Lorenzo Colitti <[email-masked]>; [email-masked]; [email-masked]; draft-ietf-v6ops-
> [email-masked]; [email-masked]; Van De Velde, Gunter (Nokia - BE/Antwerp)
> <[email-masked]>; Suresh Krishnan <[email-masked]>; The IESG <[email-masked]>

Right, and I said:

+++
 In section 2:

Please change to say:
 
+++

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 5 Sep 2017 18:24:37 +0000

Another issue with the document is that "shared network" is not an RFC4861 link
type. RFC4861 link types that could fall under the category of "shared network"
include: "multicast capable", "non-broadcast multiple access" and "shared media".
In all of these cases, it must be assumed that any pair of nodes can communicate
peer-to-peer unless prevented from doing so by some form of L2 partitioning.

The document also says:

  "o  Allow for the greatest flexibility across host implementation to
      allow for the widest range of addressing and configuration
      mechanisms to be employed.  The goal here is to ensure that the
      widest population of UE implementations can leverage the
      availability of IPv6"

So, restricting the link types on which these mechanisms could be applied would
seem to be in contrast with this goal.

In any event, the document needs to clarify what it means by "shared network"
by citing the applicable RFC4861 link types.

Thanks - Fred

---

From: Warren Kumari <[email-masked]>
Date: Sat, 9 Sep 2017 15:49:06 -0400

[ Top-post ]

Yup, I was thinking that, while substantive, that would be handled
while still keeping it in IESG eval -- but, I've just gone back and
re-read the threads, especially all of the mail (~102) after the IESG
/ telechat, and I've decided that I will have to return it to the WG.
Seeing as it has already had a WGLC, I expect that the next one can be
compressed.

The good news is that a: there have been a number of suggestions /
provided text to improve the document, and b: I'd expect the next IESG
eval to go easily.

Sorry all,
W

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 10 Sep 2017 09:58:19 +0900

Warren,

care to summarize the main issues that caused you to do this? We'll want to
make sure we don't spend too much time discussing issues that did not
materially impact this decision.

Cheers,
Lorenzo

---

From: Warren Kumari <[email-masked]>
Date: Sun, 10 Sep 2017 17:04:40 -0400

[ - IESG, -Gunter (he gets a copy as part of
draft-ietf-v6ops-unique-ipv6-prefix-per-host@), -v6chairs@ ]

> materially impact this decision.

Sure.

During IESG review, some of the IESG raised questions and suggested
text to improve the document. We received responses from the authors
saying that the questions, along with Suresh's DISCUSS, would be
addressed. We did not see an updated draft, and it's difficult to keep
the patched version in one's head. So, I don't know exactly what it
looks like now, but here are some of the considerations that
influenced my decision:

1: Brian Carpenter's:
"I believe it's substantive that the text refers to sending unicast
RAs without clarifying whether this means that they are sent
with a unicast layer 2 address and a multicast layer 3 address
(as per RFC6085) or that they are sent with both layer 2 and
layer 3 addresses being unicast. At the moment, an implementer
has to decide which of these is intended. If either is OK,
that could be stated too.".

2: Fred Templin's "unless the shared network explicitly permits
peer-to-peer operations" -- in my view adding this exact text didn't
seem to have support, but clarifying what is meant by a "shared
network" would be useful.
This was also mentioned in EKR's ballot -- ballot text is all below (I
don't want it to get lost when being LCed).

3: I do not believe that I ever saw a resolution to Lorenzo's "I'll
also point out yet again that this value is in conflict with RFC 7772
in the case of networks that are provide service for battery-powered
devices. The text should either be changed to follow that RFC or to
explain the reason for the conflict." -- I personally don't care what
the value is (I wasn't really thinking that this would occur much on
battery-powered devices, but I may be completely wrong), but I *do*
think that if it conflicts with RFC 7772 it needs to note this.

4: Much of the thread above David Farmer's
https://mailarchive.ietf.org/arch/msg/v6ops/i72cb0r6fVbxhZLhr4qybppwP6Q

5: Simply the amount of discussion after IESG eval, and IETF LC (I
think that the number is something like 100 and >350 respectively) --
while many of them wandered afar from the actual draft (and, often,
topic :-)) it is hard to make the claim that the document is really
clear and has strong consensus from this.

I'd note that #1, 2, and 4 are very closely related, and I think
should be fairly easily addressed. I'm also happy for the chairs to
have a compressed 2 WGLC (if they think appropriate).

Incidentally (but in no way relevant), I happen to really like the
idea / document, and would like to see it published (soon!).
w

-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Copy-n-paste of ballot
=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Suresh KrishnanDiscuss

Discuss (2017-08-16)

* Section 4

The router advertisement interval is not configured as an absolute
value but as minimum and maximum bounds (MinRtrAdvInterval and
MaxRtrAdvInterval) which are used to calculate the actual
advertisement interval. When the RA is sent from an interface, the
actual interval is an uniformly distributed random value between the
MinRtrAdvInterval and MaxRtrAdvInterval. At the very minimum you need
to clarify if you would like to have this as a lower bound or as an
upper bound.

Comment (2017-08-16)

* Section 4

-> I think text is needed here to handle the case where the DNS server
is provided in the RA itself  (RFC8106)

"In addition it will use stateless DHCPv6 to get the IPv6 address of
the DNS server"

"however it SHOULD NOT use stateful DHCPv6 to receive a service
provider managed IPv6 address"

"due to the L-bit being unset, it SHOULD send this traffic to the
First Hop Provider Router"

Warren KumariYes

Deborah BrungardNo Objection

Ben CampbellNo Objection

Comment (2017-08-16)

I have no technical comments, but a number of editorial comments:

- General: I think this could use another proofreading and/or editing
pass for the following issues:
-- Inconsistent tense--especially use of future or present continuous.
-- Wordy and convoluted sentences
-- Use of "/" as a conjunction.

- Abstract:
The abstract is longer and more detailed than is useful. The last
paragraph could have stood alone as the abstract.
It's not clear to me if "hosts (subscribers)" means something
different than "hosts" in context.

-1:
Please expand "IA_NA" on first use.
s/"This document will focus..."/"This document focuses..."

"As such the use
   of IPv6 SLAAC based subscriber and address management for provider
   managed shared network services is the recommended technology of
   choice, as it does not exclude any known IPv6 implementation."
Does this document make that recommendation, or is that some
pre-existing recommendation?

-3: "The Best Current Practice documented in this note is to provide a
   unique IPv6 prefix to hosts/subscribers devices connected to the
   provider managed shared network."

The sentence hard to follow. Consider "This document recommends...".
I'm not sure how to interpret "hosts/subscribers devices"

"Each unique IPv6 prefix can
   function as control-plane anchor point to make sure that each
   subscriber is receiving"
s/"... subscriber is receiving ..."/"... subscriber receives..."

-4: Is "First Hop Provider Router" different than "First Hop Router"?

In the last bullet (L-flag=0), are NEVER and ALWAYS in all-caps
expected to have different meaning than if they had normal
capitalization?

The sentence starting with "The architected result of designing the RA
as documented above..." is convoluted and hard to follow.

"... however it SHOULD NOT use stateful DHCPv6 to receive
   a service provider managed IPv6 address": Is that really a
normative requirement, or is it a statement of fact about existing
requirements?

"it SHOULD send this traffic
   to the First Hop Provider Router." : statement of fact?

- 5: "To reduce
   undesired resource consumption on the First Hop Router the desire is
   to remove UE/subscriber context in the case of non-permanent UE, such
   as in the case of WiFi hotspots as quickly as possible. "
Convoluted sentence.

"A possible solution is to use a subscriber inactivity timer which, after
   tracking a pre-defined (currently unspecified) number of minutes,
   deletes the subscriber context on the First Hop Router."

s/which/that   (Consider " ... timer that deletes...after a
predetermined number of minutes"

-7: "The
   combination of both IPv6 privacy extensions and operator based
   assignment of a Unique IPv6 Prefix per Host provides each
   implementing operator a tool to manage and provide subscriber
   services and hence reduces the experienced privacy within each
   operator controlled domain."

I have trouble following that sentence. Is the point to say that
providing tools to manage and provide services reduces privacy in
general? As worded, it almost sounds like this is meant as a feature,
which I assume is not the case.

Spencer DawkinsNo Objection

Comment (2017-08-15)

One nit:

Please consider moving

   Benefits of unique
   IPv6 prefix over a unique IPv6 address from the service provider
   include improved subscriber isolation and enhanced subscriber
   management.

to the first paragraph of the Abstract. I’m assuming that this
explains the “needs that have arisen” in the first sentence of the
Abstract, of course.

Mirja KühlewindNo Objection

Comment (2017-08-14)

To me this seems approriate for BCP; I'm saying this because this was
mentioned in the shepherd-write-up as it was brought up by the gen-art
review.

Please also consider the following comment from the gen-art review
(Thanks Joel!):
"The issue of status for the document (BCP vs Informational) is for the IESG
   to conclude.  However, even if it is a BCP, as I understand the purpose,
   this document is intended to describe the practices to be used when a
   provider has decided to deploy a /64 per host.  The wording that is chosen
   throughout the document makes it appear that the underlying decision about
   such a deployment is also a recommended practice."
I agree that wording could be made clearer here!

Alexey MelnikovNo Objection

Comment (2017-08-12)

Radius should have an informative reference on first use.

Kathleen MoriartyNo Objection

Comment (2017-08-15)

Thank you for addressing the SecDir review:
https://mailarchive.ietf.org/arch/msg/secdir/wWp_0vlmsz7Ss-nowjhehYImOeg

Eric RescorlaNo Objection

Comment (2017-08-15)

Document: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.txt

I found the discussion of the shared network medium a bit
confusing. As I understand it, the idea is that if we are
on a shared network and we have the same prefix, I might
try to send to you directly. What you want to do is make
that not happen by having each node have a separate prefix.
Correct? If so, perhaps promote this bullet, and also have
it describe the problem and why this provides a solution:

   o  Two devices (subscriber/hosts), both attached to the same provider
      managed shared network should only be able to communicate through
      the provider managed First Hop Router

It's a bit unclear to me how much you are saying that
something is current practice versus how much you are
recommending it. For instance, the abstract reads more
like what you would expect for PS.

   This document outlines an approach utilising existing IPv6 protocols
   to allow hosts to be assigned a unique IPv6 prefix (instead of a
   unique IPv6 address from a shared IPv6 prefix).  Benefits of unique
   IPv6 prefix over a unique IPv6 address from the service provider
   include improved subscriber isolation and enhanced subscriber
   management.

But then S 4 seems to be documenting:

   The IPv6 RA flags used for best common practice in IPv6 SLAAC based
   Provider managed shared networks are:

   The use of a unique IPv6 prefix per UE adds an additional level of
   protection and efficiency as it relates to how IPv6 Neighbor
   Discovery and Router Discovery processing.  Since the UE has a unique
   IPv6 prefix all traffic by default will be directed to the First Hop
   provider router.  Further, the flag combinations documented above
   maximise the IPv6 configurations that are available by hosts
   including the use of privacy IPv6 addressing.

It's not quite clear to me why unique prefixs are needed here if
people set L=0. Is it that people ignore L=0?

Finally, I'm a bit confused about how to read this text about the
L=0 bit in cases where I have multiple devices rather than just one
at the customer prem. Say I have a topology with a home router
and devices behind it. I.e.,

                    Service Provider
                           |
                           |
                        Customer
                         Router
                           |
               +-----------+-----------+
               |           |           |
             Host 1      Host 2      Host 3

I assume what happens here is that the router gets prefix X, assigns
itself XY, and then the Hosts get XA, XB, XC, etc, a la 7278. Is that
right? If so, my question is about packets coming into the Router from
the SP, which have (say) XA.  The text about the L-flag suggests that
the router should send them back to the gateway, but that's clearly
not right. What am I missing?

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 11 Sep 2017 09:01:47 +0200

To this Fred's point,

It seemed to me obvious and did not care to reply until now.

Le 05/09/2017 à 16:52, Templin, Fred L a écrit :
[...]
>         explicitly permits peer-to-peer operations"

I fully agree.

And I think this is what happens in practice: on WiFi, ND multicast 
messages are exchanged without going to Access Router (first-hop IP 
router), even if the RA is unicast from the AR to individual nodes, and 
even if each node has a distinct /64 on same shared media.

Do you think otherwise?

>     explicitly permits peer-to-peer operations."

Agreed, same reason as above.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 11 Sep 2017 19:39:20 +0000

Hi Warren,

> Sent: Sunday, September 10, 2017 2:05 PM
> To: Lorenzo Colitti <[email-masked]>
> Cc: Suresh Krishnan <[email-masked]>; [email-masked]; [email-masked]

I agree. "Shared network" is not  an RFC4861 supported link type. The
supported link types are given in RFC4861 Sections 2.2 and 3.2, and this
document needs to observe the RFC4861 terminology. For example, in
the abstract and/or introduction it could say something like "shared
network types such as multicast-capable, non-broadcast multi-access
(NBMA), shared media, etc. [RFC4861]" and then the term "shared
network"  could be used throughout the document.

Having said that, however, all of those RFC4861 supported link types
support peer-to-peer communications without having to send all traffic
through a router. In order to prevent that, this document would have to
require that L2 partitioning must be used. Otherwise, this document is
essentially deprecating peer-to-peer (including the Redirect function)
even for link types where it may provide useful benefits.

Thanks - Fred

> >> >>> First

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Sep 2017 08:48:37 +1200

>>         the provider managed First Hop Router"

That's a lower-case should, not even an RFC2119 SHOULD. So there is no
need to add an "unless" clause. It doesn't matter whether the exception
is "unless the shared network explicitly permits peer-to-peer operations"
or "unless it's Thursday afternoon". "Should" doesn't mean "must."

Fred said:

> In order to prevent that, this document would have to

Again, it does not require or deprecate, it only recommends. And don't
forget that peer-to-peer operation will only happen for link-local
addresses or for announced on-link prefixes, neither of which are
covered by the concept "unique-ipv6-prefix-per-host". The draft is
100% clear on this:

"   o  L-flag = 0 (the prefix is not an on-link prefix, which means that
      the UE/subscriber will NEVER assume destination addresses that
      match the prefix are on-link and will ALWAYS send packets to those
      addresses to the appropriate gateway according to route selection
      rules.)"

So I don't agree that this text needs changing.

    Brian

---

From: Warren Kumari <[email-masked]>
Date: Mon, 11 Sep 2017 18:00:54 -0400

On Mon, Sep 11, 2017 at 3:39 PM, Templin, Fred L
<[email-masked]> wrote:
> document needs to observe the RFC4861 terminology.

I do not agree with you that it needs to use RFC4861 terminology (nor,
I think, does the WG) -- I do however think that it would be useful
for the document to clarify what it *does* mean when it says "shared
network" -- it uses the term 11 times, and some description of what it
is meaning would be (IMO) useful. EKR's ballot also expressed
confusion on this:

--------
Eric Rescorla No Objection Comment (2017-08-15)

-----

I'm also fine if the WG disagrees and feels that everyone reading this
will understand what a "shared network" is (and where all things like
an RA/RS will reach on one).

> For example, in
> require that L2 partitioning must be used.

Depends what you mean by "prevent", and what you think that document
is trying to accomplish - the abstract says:
"While
   this is still viable and operates as designed, there are some large
   scale environments where this concept introduces significant
   performance challenges and implications, specifically related to IPv6
   router and neighbor discovery.

   management."

It doesn't say "make it completely impossible for subscribers to
communicate" or "enforce isolation for security", or "prevent
peer-to-peer".

W

> Otherwise, this document is

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 11 Sep 2017 22:27:54 +0000

Hi Brian,

> From: v6ops [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Monday, September 11, 2017 1:49 PM
> To: [email-masked]

Peer to peer can happen for non-link-local addresses if there is a Redirect,
or if I call my neighbor up on the phone and ask him for his MAC address
and then set up a static neighbor cache entry.

>       addresses to the appropriate gateway according to route selection

Unless there is a Redirect (or a static neighbor cache entry gets added).

> So I don't agree that this text needs changing.

You should agree that this document is not intending to deprecate
peer-to-peer? If yes, then the document should make that clear.

Thanks - Fred

---

From: "Brzozowski, John" <[email-masked]>
Date: Mon, 11 Sep 2017 22:37:56 +0000

Jumping in a little late here, FWIW the only item we (Gunter and I) really intend on addressing is Lorenzo’s comment.  It is perfectly valid.  Gunter and I meant to address the same and have been emailing to resolve the request.

All other comments are largely unrelated.  Volume does not imply relevance.

John
+1-484-962-0060

-----Original Message-----
From: Warren Kumari <[email-masked]>
Date: Sunday, September 10, 2017 at 17:04
To: Lorenzo Colitti <[email-masked]>
Cc: Brian Carpenter <[email-masked]>, v6ops <[email-masked]>, "[email-masked]" <[email-masked]>, Suresh Krishnan <[email-masked]>
Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT)
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, Gunter Van de Velde <[email-masked]>
Resent-Date: Sunday, September 10, 2017 at 17:05

    
    
    Sure.

    1: Brian Carpenter's:

    

    

    
    Suresh KrishnanDiscuss
    
    Discuss (2017-08-16)
    
    * Section 4

    
    
    Comment (2017-08-16)
    
    * Section 4

    

    

    
    Warren KumariYes

    Ben CampbellNo Objection
    
    Comment (2017-08-16)

    
    - Abstract:
    
    -1:
    
    "As such the use

    

    

    
    
    - 5: "To reduce

    
    -7: "The

    
    Comment (2017-08-15)
    
    One nit:
    
    Please consider moving
    
       Benefits of unique

    
    Comment (2017-08-14)

    
    
    Comment (2017-08-12)

    
    Comment (2017-08-15)

    
    Comment (2017-08-15)

    

    

    

                        Service Provider
                               |
                               |
                            Customer
                             Router
                               |

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 11 Sep 2017 22:43:23 +0000

Hi Warren,

> From: Warren Kumari [mailto:[email-masked]]
> Sent: Monday, September 11, 2017 3:01 PM
> Cc: Lorenzo Colitti <[email-masked]>; Suresh Krishnan <[email-masked]>; [email-masked]; draft-ietf-v6ops-unique-
> [email-masked]
> I do not agree with you that it needs to use RFC4861 terminology

That surprises me. This document is about an interpretation of RFC4861,
and the RFC4861 terminology should apply.

> (nor,

Are you prepared to say that, if two subscribers find out through some
means that they could communicate directly without going through the
router, that this document does not prevent them from doing so? If
yes, then let's have that on the list.

Thanks - Fred

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 12 Sep 2017 16:13:52 +0900

> and the RFC4861 terminology should apply.

This document is not an interpretation of 4861 and is under no such
obligations. In any case - RFC 4861 section 2.2 is clearly not a taxonomy
of link types, it's a list of link *properties*. Example: "variable MTU"
(which is one of the bullets of that section) is not a link type.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 12 Sep 2017 14:43:18 +0000

Hi Lorenzo,

Comments below:

Fred

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Tuesday, September 12, 2017 12:14 AM
To: Templin, Fred L <[email-masked]>
Cc: Warren Kumari <[email-masked]>; Suresh Krishnan <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT)

This document is not an interpretation of 4861 and is under no such obligations.

Ø  The document makes an interpretation of what the A=1; L=0 bit assignments

Ø  for PIOs means within this context. That makes it an interpretation of RFC4861.

In any case - RFC 4861 section 2.2 is clearly not a taxonomy of link types, it's a list of link *properties*. Example: "variable MTU" (which is one of the bullets of that section) is not a link type.

Ø    Section 2.2 is titled: “Link Types” and Section 3.2 is titled: “Supported Link Types”

Ø    The type descriptions are understood to line up with actual IP data links. For

Ø    example, Ethernet and WiFi are examples of multicast-capable links, tunnel

Ø    virtual links are an example of NBMA links, etc. These are the link types that

Ø    IPv6 ND operates over, and have been specified that way since RFC1970.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 13 Sep 2017 03:21:30 +0900

On Tue, Sep 12, 2017 at 11:43 PM, Templin, Fred L <[email-masked]
> wrote:
>
> In any case - RFC 4861 section 2.2 is clearly not a taxonomy of link
> types, it's a list of link *properties*. Example: "variable MTU" (which is
> one of the bullets of that section) is not a link type.
>
>
>
You're not actually suggesting that "variable MTU" is a link type, are you?

---

From: 神明達哉 <[email-masked]>
Date: Tue, 12 Sep 2017 11:56:08 -0700

> So I don't agree that this text needs changing.

+1.  I don't even understand why we are discussing this level of
things in the context of draft-ietf-v6ops-unique-ipv6-prefix-per-host.

My interpretation of the draft has always been that it explains *one*
way to provide each individual host with a unique IPv6 prefix for
*some* environments.  While it mildly recommends their way for others
who share the same motivation, it doesn't insist that's *the* only way
to operate an IPv6 network or it doesn't change any protocol
specifications.  I've just re-read the entire 07 version of the draft
and still have the same impression.

Although some more editorial clarifications might make the point even
super crystal clearer, I don't see the need for the level of wordsmith
nitpicking discussed in this lengthy thread.  For example, it's true
that adding "unless redirect is sent" to the above cited bullet would
make the idea of this draft even clearer than 100%, the current text
is already clear enough to me if you read it with the entire context.
Same for the definition of "shared network".

Assuming the main source of the objections is based on the
interpretation that this draft prohibits other ways of operation,
(although the draft doesn't read that way to me) a couple of higher
level clarifications might help us move forward:

- note in the introduction that this draft doesn't intend to prevent
  other way of network operation such as allowing direct p2p
  communication between hosts in the shared link.  it totally depends
  on operational requirements and assumptions of each environment.
- rephrase the seemingly controversial bullet in Section 2 so it's
  more obvious it's just a part of motivation, not a requirement (let
  alone some kind of standard).  e.g.
  From:
   o  Two devices (subscriber/hosts), both attached to the same provider
      managed shared network should only be able to communicate through
      the provider managed First Hop Router
  To:
   o  Make sure two devices (subscriber/hosts), both attached to the
      same provider managed shared network, will only be able to
      communicate through the provider managed First Hop Router

--
JINMEI, Tatuya

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 12 Sep 2017 21:41:18 +0200

Le 12/09/2017 à 20:56, 神明達哉 a écrit :
[...]

>        communicate through the provider managed First Hop Router

This IP Host-to-Host communication does happen on shared media, unless 
someone forbids it somehow with some iptables filtering.

Or maybe we want to clarify at which level of the ISO OSI stack is this 
"communicate through".

For example: at APP layer, make sure two subscribers both attached to 
same provider managed shared network, will only be able to communicate 
through the provider's managed App Server; at network layer, allow for 
direct communications.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 12 Sep 2017 20:17:48 +0000

Sent: Tuesday, September 12, 2017 11:22 AM

On Tue, Sep 12, 2017 at 11:43 PM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:
In any case - RFC 4861 section 2.2 is clearly not a taxonomy of link types, it's a list of link *properties*. Example: "variable MTU" (which is one of the bullets of that section) is not a link type.

>    Section 2.2 is titled: “Link Types” and Section 3.2 is titled: “Supported Link Types”

>    The type descriptions are understood to line up with actual IP data links. For

>    example, Ethernet and WiFi are examples of multicast-capable links, tunnel

>    virtual links are an example of NBMA links, etc. These are the link types that

>    IPv6 ND operates over, and have been specified that way since RFC1970.

Ø    RFC4861 gives an example.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 13 Sep 2017 07:51:18 +0200

Le 12/09/2017 à 22:17, Templin, Fred L a écrit :
> *From:*Lorenzo Colitti [mailto:[email-masked]]
> *Sent:* Tuesday, September 12, 2017 11:22 AM
> *To:* Templin, Fred L <[email-masked]>
> *Cc:* Warren Kumari <[email-masked]>; Suresh Krishnan 
> <[email-masked]>; [email-masked]; 
> [email-masked]
> *Subject:* Re: [v6ops] Suresh Krishnan's Discuss on 
> draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT)
> 
> On Tue, Sep 12, 2017 at 11:43 PM, Templin, Fred L 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     types, it's a list of link *properties*. Example: "variable MTU"
>     ØSection 2.2 is titled: “Link Types” and Section 3.2 is titled:
>     “Supported Link Types”
> 
>     ØThe type descriptions are understood to line up with actual IP data
>     links. For
> 
>     Øexample, Ethernet and WiFi are examples of multicast-capable links,
>     tunnel
> 
>     Øvirtual links are an example of NBMA links, etc. These are the link
>     types that
> 
>     ØIPv6 ND operates over, and have been specified that way since RFC1970.
> 
> ØRFC4861 gives an example.

I think it is possible to decide that a particular link is of a 
particular 'link type' too by looking at the MTU value that is 
advertised on the link in the RA.

If there is no MTU value in RA - it's likely to be an Ethernet and family.

If there is smaller than 1280 value - it's likely to be either Ethernet, 
or some other IoT kind constrained of link.

If there is a larger than 1280 value - it's likely to be one of those 
core network links like ATM and FDDI which support MTU of up to 65k.

One could test a Host on that link see at which point it fragments by 
varying the MTU value in RA and then ping -s 'size': one will notice 
IPv6 Fragments popping up.  The threshold 'size' is the MTU of that link.

Whether or not dedicated-/64-per-Host applies on these links types - 
only  this draft could tell, or no.

Alex

---

From: Ole Troan <[email-masked]>
Date: Wed, 13 Sep 2017 09:14:25 +0200

> and still have the same impression.

The document has:
   Intended status: Best Current Practice

I think when something has that label, people unsurprisingly reads it as _the_ recommended way of doing things.
It also labels doing it any other way as not best current practice.

A simple fix to those concerns are:
s/Best Current Practice/Informational

Ole

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 13 Sep 2017 07:55:50 +0000

+1

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Ole Troan
Sent: mercredi 13 septembre 2017 09:14
To: 神明達哉 <[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT)

The document has:

Ole

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Wed, 13 Sep 2017 14:11:29 +0000

New version is submitted, taking the IETF LC comments into account, including Suresh comment about maximum RA interval and Lorenzo’s substantial note about 300s vs 600s RA interval for battery constraint devices. 

G/

On 10/09/2017, 23:04, "Warren Kumari" <[email-masked]> wrote:

    
    
    Sure.

    1: Brian Carpenter's:

    

    

    
    Suresh KrishnanDiscuss
    
    Discuss (2017-08-16)
    
    * Section 4

    
    
    Comment (2017-08-16)
    
    * Section 4

    

    

    
    Warren KumariYes

    Ben CampbellNo Objection
    
    Comment (2017-08-16)

    
    - Abstract:
    
    -1:
    
    "As such the use

    

    

    
    
    - 5: "To reduce

    
    -7: "The

    
    Comment (2017-08-15)
    
    One nit:
    
    Please consider moving
    
       Benefits of unique

    
    Comment (2017-08-14)

    
    
    Comment (2017-08-12)

    
    Comment (2017-08-15)

    
    Comment (2017-08-15)

    

    

    

                        Service Provider
                               |
                               |
                            Customer
                             Router
                               |

---

From: 神明達哉 <[email-masked]>
Date: Wed, 13 Sep 2017 07:47:10 -0700

At Wed, 13 Sep 2017 09:14:25 +0200,

> It also labels doing it any other way as not best current practice.

I see it, but even so, and even if I were a kind of operator who wants
to allow p2p host communication in the link, I'd have no problem with
the proposal of this draft.  It's pretty clear to me that not allowing
it is part of its motivation and it's 'the best current practice' when
you have that motivation.  If I don't share that motivation I would
just consider it not applicable to my use case.

That said...

> s/Best Current Practice/Informational

...I have no problem with this resolution.  After all, I have no stake
in the proposal of this draft, and I don't care about its document
category.  I just think the current discussion is unproductive.  I'd
welcome any easy way out from it.

--
jinmei

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 13 Sep 2017 16:06:20 +0000

+1

> Sent: Wednesday, September 13, 2017 12:14 AM

---

From: Suresh Krishnan <[email-masked]>
Date: Wed, 13 Sep 2017 13:40:48 -0400

Thanks Gunter and John. The new version addresses my DISCUSS and COMMENTs. I have cleared.

Regards
Suresh

> On Sep 13, 2017, at 10:11 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Sep 2017 08:37:26 +1200

> Thanks Gunter and John. The new version addresses my DISCUSS and COMMENTs. I have cleared.

Sadly though it has at least one significant nit and one remaining ambiguity, as I
just reported. I hope they can be fixed before we see an approval notice.

   Brian