Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07'

From: james woodyatt <[email-masked]>
Date: Fri, 1 Sep 2017 10:24:07 -0700

On Aug 31, 2017, at 16:23, Brian E Carpenter <[email-masked]> wrote:
> On 31/08/2017 20:13, David Farmer wrote:
>> On Aug 30, 2017, at 19:11, Lorenzo Colitti <[email-masked]> wrote:
>>> 
>>> If there are any multicast RA/PIOs for these prefixes, they should have
>>> A=0; L=0 (cf RFC8028).
>>> 
>>> But I'm not sure why there would be any multicast RAs. They don't
>>> seem to be needed. The draft talks about unicast RAs.
>> 
>> Unicast RAs would require the router to keep state on all its clients
>> regardless of its IP addresses and across IP address changes. That doesn't
>> scale. It's much better for the router to send a multicast RA on each
>> separate L2 link, knowing that it will go only to the host on that link
>> that has that prefix.
> 
> Nevertheless,
> (a) the draft says unicast.
> (b) hypothetically there *is* no separate L2 link for multicast; there is just a
> logical separation for unicast purposes. That seems to be what Ole described.

I think this is the basic reason I misunderstood the draft not to require L2 isolation. It seems to me like the current draft still admits the potential utility of using this scheme without L2 isolation, and I think it leaves way too many open questions about how that would work, including the question of how redirects should work.

Cannot support until this issue is resolved.

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 2 Sep 2017 16:13:41 +0900

> logical separation for unicast purposes. That seems to be what Ole

Layer-2 unicast, yes. They are unicast to the host and have an IPv6
destination address of ff02::1.

---

From: David Farmer <[email-masked]>
Date: Mon, 4 Sep 2017 13:23:17 -0500

> destination address of ff02::1.

I to believe that is the intent, but that needs to be explicitly said in
the draft.  Further, the draft seems to only discuss the formation of RAs
that are sent in response to an RS, the draft should also
explicitly discuss the periodic RAs sent by the router.  Even if that is as
simple as saying they should be formed the same, and using same unicast L2,
multicast L3 addressing, as the RAs sent in response to an RS.

Thanks.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Fred Baker <[email-masked]>
Date: Mon, 4 Sep 2017 11:38:48 -0700

Thought for today...

Warren, Ron, Lee, and I are wondering how much of all this relates to the draft mentioned in the subject line. I saw a note from, I think, Lorenzo the other day 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. 

Is there anything else here that comments specifically on this draft and should be considered in IESG review? If so, please respond and highlight it.

On other matters, by all means please discuss. You might consider changing the thread, though.

Sent using a machine that autocorrects in interesting ways...

> On Aug 31, 2017, at 9:49 AM, David Farmer <[email-masked]> wrote:
> 
> You are talking about redirects as if they are a universal good, and yes
> they are necessary in some situations, but they also have security
> considerations. You claim the draft is ignoring the potential usefulness of
> redirects in some environments and yes it is.  However, you are ignoring
> the potential additional security that not having redirects has in other
> environments.
> 
> Further, you have not discussed any advantages that the use of prefix per
> host subnets model has over the classic multiple hosts per subnet model in
> an insecure environment to justify the increased use of number resources by
> prefix per host subnets model. Please explain some of the use cases you
> think their are and why the prefix per host subnets model with redirects
> has any kind of advantage over the classic multiple hosts per subnet model.
> 
> Thanks.
> 
> On Thu, Aug 31, 2017 at 10:18 AM, Templin, Fred L <[email-masked]
>> wrote:
> 
>> Hi,
>> 
>> 
>> 
>> The simple point in all of this is that Redirects are (and will remain) a
>> 
>> useful component of IPv6 ND, yet this document seems to deprecate
>> 
>> their use in all cases even for links where use of Redirects is essential

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 5 Sep 2017 08:17:58 +1200

On 05/09/2017 06:23, David Farmer wrote:
> the draft.

I can't see into the authors' minds, so I don't know the intent. When I
see the word 'unicast in the description of an IPv6 packet, I assume that
its destination IPv6 address is a unicast addresses. If that isn't what
they mean, it certainly needs to be stated in full detail. Sending a
message with a multicast layer 3 destination to a unicast layer 2
destination on a multicast-capable link is unusual.

> Further, the draft seems to only discuss the formation of RAs

Indeed.

   Brian

---

From: Ole Troan <[email-masked]>
Date: Mon, 4 Sep 2017 22:22:35 +0200

> Sending a

RFC6085.

Ole

---

From: David Farmer <[email-masked]>
Date: Mon, 4 Sep 2017 15:28:14 -0500

On Mon, Sep 4, 2017 at 1:38 PM, Fred Baker <[email-masked]> wrote:

> Thought for today...
>
> Warren, Ron, Lee, and I are wondering how much of all this relates to the
> draft mentioned in the subject line. I saw a note from, I think, Lorenzo
> the other day 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.
>
> Is there anything else here that comments specifically on this draft and
> should be considered in IESG review? If so, please respond and highlight it.
>

Adding to Lorenzo's request;

Security, in the form of UE/subscriber isolation, is not mentioned in the
abstract or introduction of draft-ietf-v6ops-unique-ipv6-prefix-per-host-07.
If UE/subscriber isolation is truly a fundamental aspect of this solution,
which I and I think several others in the WG think it is, then it should
probably be at least mentioned in the abstract or the introduction.

I think it should also be noted, maybe in a paragraph at the end of section
2. If it were practical, for security reasons it would be justified, to
deploy individual physical or logical links on a per UE/subscriber basis
(such as completely separate VLANs per UE/subscriber). Further, the
proposed deployment model will not use more IPv6 subnet prefixes than if
for security reasons each UE/subscriber were deployed on it's own
individual physical or logical link. However, in most cases this deployment
model, using L2 isolation between UE/subscribers on a shared network, will
be more practical to deploy than separate individual physical or logical
links on a per UE/subscriber basis.

Further, the security considerations section should discuss the
consequences of not providing L2 isolation between UE/subscribers on the
shared network. That is primarily, that a malicious UE/subscriber could
impersonate the provider first hop router, or otherwise communicate
directly with UE/subscribers without first having traffic go through the
provider first hop router, therefore bypassing any inter-UE/subscriber
security policies that might have been applied by the provider.

Finally, it might be worth nothing some place in the draft that redirects
SHOULD be disabled on the provider first hop router facing the share
network, as direct inter-UE/subscriber communications is not intended to be
possible across the shared network.

Thanks.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815 <(612)%20626-0815>
Minneapolis, MN 55414-3029   Cell: 612-812-9952 <(612)%20812-9952>
===============================================

---

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

>> destination on a multicast-capable link is unusual.

Which sort of confirms that it's unusual ;-). This would be a good
reference for the draft, if that is indeed what is intended.

BTW, RFC6085 is explicitly about Ethernet. Is there any reason that
it doesn't apply to any broadcast link-layer?

Thanks
   Brian

---

From: Ole Troan <[email-masked]>
Date: Mon, 4 Sep 2017 22:56:13 +0200

> it doesn't apply to any broadcast link-layer?

Which link-layer are you thinking of?

Ole

---

From: Mark Smith <[email-masked]>
Date: Tue, 5 Sep 2017 08:21:39 +1000

On 5 Sep. 2017 06:33, "Brian E Carpenter" <[email-masked]>
wrote:

While RFC6085 is useful to have in our toolbox,I think it would be better
to IPv6 layer unicast RAs. That encodes the intent of which set of devices
are intended to receive the RA in the DA in this scenario (i.e. a set of
one).

If the draft is discussing a Wifi service provider scenario, which I think
is likely, then RAs should probably also be unicast to save batter power of
client devices per BCP202.

Regards,
Mark.

Thanks
   Brian

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

---

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

> Which link-layer are you thinking of?

Well, OK, I'm a standards freak, but Token Ring and FDDI both support
layer 2 multicast. And as has been pointed out, 802.11 may look like
Ethernet, but it isn't Ethernet. So my question is not about the
prevalence of 802.1 in the real world, but about the generality
of the rule. I assume it would apply in all cases.

   Brian

---

From: Ole Troan <[email-masked]>
Date: Tue, 5 Sep 2017 08:38:42 +0200

Brian,

> of the rule. I assume it would apply in all cases.

RFC6085 applies to any link-layer which uses RFC2464 mapping. Including WIFI.

I agree with you that the document should have been more general. I don't see any reason why this rule couldn't be general. It of course makes some assumptions about keeping the state about the mapping that isn't required in general if the multicast mapping is used. That said, 6085 specifically restricts itself to Ethernet. I guess if we need this clarification on Token Ring we'll cross that barrier when we get to it. ;-)

Best regards,
Ole

---

From: Ole Troan <[email-masked]>
Date: Tue, 5 Sep 2017 08:51:41 +0200

Mark,

> While RFC6085 is useful to have in our toolbox,I think it would be better to IPv6 layer unicast RAs. That encodes the intent of which set of devices are intended to receive the RA in the DA in this scenario (i.e. a set of one).

I would strongly object to this draft mandating one mapping over the other.
My implementation uses L3 multicast -> L2 unicast. And it would be a significant change to send L3 unicast.

> If the draft is discussing a Wifi service provider scenario, which I think is likely, then RAs should probably also be unicast to save batter power of client devices per BCP202.

L2 multicast is what's expensive, so regardless of mapping this results in battery saving.

Ole

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 5 Sep 2017 08:53:20 +0200 (CEST)

On Tue, 5 Sep 2017, Brian E Carpenter wrote:

> prevalence of 802.1 in the real world, but about the generality of the 
> rule. I assume it would apply in all cases.

It's an interesting case. To the IP stack in most OSes, doesn't wifi 
packets received look like they're ethernet framed? So wifi kind of 
pretends to look Ethernet as much as it can, and these kinds of rules 
should be applied to all media types that have L2 
multicast/broadcast/unicast concepts, right?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Mark Smith <[email-masked]>
Date: Tue, 5 Sep 2017 17:36:30 +1000

On 5 Sep. 2017 16:51, "Ole Troan" <[email-masked]> wrote:

Mark,

I would strongly object to this draft mandating one mapping over the other.
My implementation uses L3 multicast -> L2 unicast. And it would be a
significant change to send L3 unicast.

I'm looking at it from the principle of least surprise. A  packet with an
L3 mcast DA in a frame with an L2 unicast DA would be surprising unless
you're expecting it and know it is intentional.

Is the significant change in the area of building up the table of unicast
IPv6 addresses (LLs probably) to unicast to? I haven't been entirely sure
if routers do this or are required to do this,  however I've thought
routers could proactively store RS and MLD message source addresses in
their ND cache, with NUD then being the method that keeps those entries
current.

Per when I did investigations while writing this draft, it seems that if a
router is processing MLDv2 messages, it needs to have or trigger an NS for
the MLDv2 source address.

MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast
IPv6https://tools.ietf.org/id/draft-smith-mldv2-link-unicast-00.txt

> If the draft is discussing a Wifi service provider scenario, which I
think is likely, then RAs should probably also be unicast to save batter
power of client devices per BCP202.

L2 multicast is what's expensive, so regardless of mapping this results in
battery saving.

If RFC6085 was used for more than just RAs, ideally every L3 mcast where
possible i.e. draft above, that makes them less surprising.

Regards,
Mark.

Ole

---

From: Ole Troan <[email-masked]>
Date: Tue, 5 Sep 2017 09:55:23 +0200

Mark,

> I'm looking at it from the principle of least surprise. A  packet with an L3 mcast DA in a frame with an L2 unicast DA would be surprising unless you're expecting it and know it is intentional.

Not it my implementation. Each router - host connection is represented as an interface.

> Is the significant change in the area of building up the table of unicast IPv6 addresses (LLs probably) to unicast to? I haven't been entirely sure if routers do this or are required to do this,  however I've thought routers could proactively store RS and MLD message source addresses in their ND cache, with NUD then being the method that keeps those entries current.

Again talking about my implementation, but I believe this applies generally to unique-ipv6-prefix-per-host,  - there is no ND cache. That's kind of the whole point.

> 
> Per when I did investigations while writing this draft, it seems that if a router is processing MLDv2 messages, it needs to have or trigger an NS for the MLDv2 source address.
> 
> MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast IPv6https://tools.ietf.org/id/draft-smith-mldv2-link-unicast-00.txt

MLD for link-local multicast has no utility in general.

> If RFC6085 was used for more than just RAs, ideally every L3 mcast where possible i.e. draft above, that makes them less surprising.

This draft essentially creates a /64 -> MAC address binding. It doesn't specify what to do with multicast in general.

My implementation does a P2P interface -> MAC address binding. Which of course then takes care of multicast. In RFC6085 fashion.

Cheers,
Ole

---

From: Mark Smith <[email-masked]>
Date: Tue, 5 Sep 2017 18:30:10 +1000

On 5 Sep. 2017 17:55, "Ole Troan" <[email-masked]> wrote:

Mark,

> > While RFC6085 is useful to have in our toolbox,I think it would be
better to IPv6 layer unicast RAs. That encodes the intent of which set of
devices are intended to receive the RA in the DA in this scenario (i.e. a
set of one).

Not it my implementation. Each router - host connection is represented as
an interface.

Again talking about my implementation, but I believe this applies generally
to unique-ipv6-prefix-per-host,  - there is no ND cache. That's kind of the
whole point.

>
> Per when I did investigations while writing this draft, it seems that if
a router is processing MLDv2 messages, it needs to have or trigger an NS
for the MLDv2 source address.
>
> MLDv2 Procedures for Link-Layer Unicast Delivery of Multicast IPv6
https://tools.ietf.org/id/draft-smith-mldv2-link-unicast-00.txt

Sort of off topic for this thread, however that draft is about any groups
for which MLDv2 is used to join. It is a method to L2 unicast over the last
hop, but not limited to single hop groups.

This draft essentially creates a /64 -> MAC address binding. It doesn't
specify what to do with multicast in general.

My implementation does a P2P interface -> MAC address binding. Which of
course then takes care of multicast. In RFC6085 fashion.

Cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Tue, 5 Sep 2017 10:43:30 +0200

> Sort of off topic for this thread, however that draft is about any groups for which MLDv2 is used to join. It is a method to L2 unicast over the last hop, but not limited to single hop groups.

Good point. That's an alternative to what this draft does (essentially limiting the broadcast domain to one host).

Cheers,
Ole

---

From: David Farmer <[email-masked]>
Date: Tue, 5 Sep 2017 08:38:25 -0500

> client devices per BCP202.

I think the draft should be agnostic about whether solicited RAs are sent
unicast or multicast., but unsolicited RA have to be sent multicast.  So, I
propose the following;

In the second paragraph of section 4, s/unicast/solicited/

Then add the following text as the third paragraph of section 4;

In general, a solicited RA response, may be sent either unicast or
multicast. However, an unsolicited RA, which is sent periodically, is
always sent multicast. This is described in [RFC4861], sections 6.2.6 and
6.2.4 respectively. When the First Hop Router sends a multicast RA, either
solicited or unsolicited, it SHOULD only be received by the UE/subscriber
that has been assigned the Unique IPv6 prefix it contains. This is achieved
by sending the packet to the unicast link-layer address of the UE/subscriber
instead of the associated link-layer multicast address [RFC6085].

Thanks

---

From: Fred Baker <[email-masked]>
Date: Tue, 5 Sep 2017 08:23:25 -0700

Sounds like an erratum on RFC 6085.

> On Sep 4, 2017, at 11:53 PM, Mikael Abrahamsson <[email-masked]> wrote:
> 
>> Well, OK, I'm a standards freak, but Token Ring and FDDI both support layer 2 multicast. And as has been pointed out, 802.11 may look like Ethernet, but it isn't Ethernet. So my question is not about the prevalence of 802.1 in the real world, but about the generality of the rule. I assume it would apply in all cases.
> 
> It's an interesting case. To the IP stack in most OSes, doesn't wifi packets received look like they're ethernet framed? So wifi kind of pretends to look Ethernet as much as it can, and these kinds of rules should be applied to all media types that have L2 multicast/broadcast/unicast concepts, right?
> 
> --

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 6 Sep 2017 08:15:10 +1200

> Sounds like an erratum on RFC 6085.

I think that might be wise, but I'm happy to leave that to Ole if
he thinks it's useful.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 6 Sep 2017 08:27:08 +1200

On 06/09/2017 01:38, David Farmer wrote:
...
> multicast. 

That still doesn't explain whether it means L2 or L3 unicast. Even if
we agree with Ole's point that either interpretation is OK, it needs
to be said explicitly.

   Brian

> However, an unsolicited RA, which is sent periodically, is

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 5 Sep 2017 20:44:22 +0000

Hi,

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Brian E Carpenter
> Sent: Tuesday, September 05, 2017 1:27 PM
> To: David Farmer <[email-masked]>; Mark Smith <[email-masked]>
> Cc: v6ops list <[email-masked]>; [email-masked]; [email-masked]
> Subject: Re: [v6ops] Comment on 'draft-ietf-v6ops-unique-ipv6-prefix-per-host-07'
> 

In RFC5214, the RAs use unicast for both L2 and L3. (Also, there are no periodic
RAs - only solicited ones.) And, RFC5214 defines the behavior explicitly.

So, I agree with Brian that the interpretation in this document needs to be
made explicit.

Thanks - Fred

---

From: David Farmer <[email-masked]>
Date: Tue, 5 Sep 2017 17:15:42 -0500

On Tue, Sep 5, 2017 at 3:44 PM, Templin, Fred L <[email-masked]>
wrote:

> > Cc: v6ops list <[email-masked]>; [email-masked];
> [email-masked]

Ok is this explicit enough?

Again, in the second paragraph of section 4, s/unicast/solicited/

When the First Hop Provider Router sends a solicited RA response, or a
periodic unsolicited RA, the RA MUST be sent only to the UE/subscriber that
has been assigned the Unique IPv6 prefix contained in the RA.  This is
achieved by sending a unicast RA response, as detailed in [RFC4861] section
6.2.6, or by sending a multicast RA response or unsolicited RA to the
all-nodes group, as detailed in [RFC4861] section 6.2.4 and 6.2.6, but
instead of using the link-layer multicast address associated with the
all-nodes group, the link-layer unicast address of the UE/subscriber that
has been assigned the Unique IPv6 prefix contained in the RA MUST be used
as the link-layer destination [RFC6085].

In RFC5214, the RAs use unicast for both L2 and L3. (Also, there are no
> periodic

But ISATAP clients know they not doing plain vanilla RFC4861, these clients
don't, so they are expecting periodic unsolicited RAs sent by the router.