Subject: Fwd: New Version Notification for draft-zerorafolks-6man-ra-zero-lifetime-00.txt

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 3 Jul 2018 18:39:27 +0900

Hi,

wanted to post the following to the list. It's a very simple document that
makes it possible to send RAs PIOs with zero valid lifetimes when the link
layer can guarantee that there is only one router on the link (e.g., in the
case of a point-to-point link).

One use case is to support the new reduced-mobilty modes provided by 5G
networks that Wu-chi mentioned in:

https://www.ietf.org/mail-archive/web/ipv6/current/msg30461.html

The thought here is that instead of all traffic going to long-lived IPv6
prefixes, which increase latency and use more network bandwidth because
they have to hairpin through a mobility anchor, it would be more efficient
if the majority of traffic could go to shorter-lived prefixes.

Because most mobile apps already have the ability to resume connections
(since they have to deal with devices moving out of range, users abruptly
turning off wifi, etc.), such apps could opt in to lower-latency IP
addresses if they were prepared to deal with those addresses going into
lame-duck mode or even abruptly disappearing.

Regardless of whether Wu-Chi's option gains consensus or not it seems to me
that for this scheme to work we'll need to be able to communicate to hosts
that their IPv6 addresses are no longer routed to them in order for this
scheme to work.

Cheers,
Lorenzo

============
A new version of I-D, draft-zerorafolks-6man-ra-zero-lifetime-00.txt
has been successfully submitted by Lorenzo Colitti and posted to the
IETF repository.

Name:           draft-zerorafolks-6man-ra-zero-lifetime
Revision:       00
Title:          Zero valid lifetimes on point-to-point links
Document date:  2018-06-30
Group:          Individual Submission
Pages:          4
URL:
https://www.ietf.org/internet-drafts/draft-zerorafolks-6man-ra-zero-lifetime-00.txt
Status:
https://datatracker.ietf.org/doc/draft-zerorafolks-6man-ra-zero-lifetime/
Htmlized:
https://tools.ietf.org/html/draft-zerorafolks-6man-ra-zero-lifetime-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-zerorafolks-6man-ra-zero-lifetime

Abstract:
   This document allows implementations to accept low or zero valid
   lifetimes in Router Advertisement Prefix Information Options in cases
   where it is known that there can only be one router on the link.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Fernando Gont <[email-masked]>
Date: Tue, 3 Jul 2018 12:29:01 +0200

Lorenzo & Erik,

Just quickly read the doc. Some comments/questions:

> 3.  Changes to RFC 4862
> 
>    The following clause is added between points 1 and 2 of clause e,
>    Section 5.5.3 of [RFC4862]:
> 
>    2. If the link-layer guarantees that there is only one node on the
>       link from which the host can receive Router Advertiesements (e.g.,
>       if the link is a point-to-point link, such as a PPP link or a 3GPP
>       link as defined in [RFC6459]), and the link has another prefix of
>       the same scope with sufficient Valid Lifetime, set the valid
>       lifetime of the corresponding address to the advertised Valid
>       Lifetime.

A few comments/questions:

* I think that RFC4862, in general, assumes possible multiple routers on
the network. The ability of a single router being able to speak for the
whole network would seem to be a different operating mode (although I
realize that the same idea is being applied to the ipv6-only flag?)

* When you say "only oe node sending RAs on the link" is because of the
security considerations or because you need this to be the case for this
"feature" to be of use?

> 5.  Security Considerations
> 
>    The denial-of-service attack that motivated this restriction cannot
>    be mounted on a link where no other devices can send Router
>    Advertisements to the host.

I think that if the goal is to prevent attacks, the security
considerations section should instead note that you are assuming
deployment of RA-Guard or the like.

The problem here if that in order for this feature to work, you needs
*all nodes* to accept (by default) PIOs with a valid lifetime of 0. And
they would be accepting them on all networks, not just those one which
you assume RA-guard or the like. That is, if you want all nodes to
accept (by default) PIO valid lifetimes of 0, then they would become
vulnerable on networks where RA-guard or the like is not deployed.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 3 Jul 2018 19:54:46 +0900

> realize that the same idea is being applied to the ipv6-only flag?)

This proposal is limited only to those networks where there is by
construction only one router. There are many such networks - for example,
all 4G networks are like this.

> security considerations or because you need this to be the case for this

It's only because of the security considerations. To re-state simply:

   1. There is only an attack vector on links where there can be more than
   one on-link device sending RAs to you.
   2. There are a large number of networks that are point-to-point and
   therefore can only have one on-link device sending RAs to you
   3. Therefore, on such networks, the attack vector does not exist and
   does not need to be protected against.

> deployment of RA-Guard or the like.

The goal is not to prevent attacks. The goal is to be able to accept RAs
with a valid lifetime of 0 on networks where it is safe to do so.

> vulnerable on networks where RA-guard or the like is not deployed.

That's not exactly true. You need all nodes supporting this functionality
to accept zero lifetimes *on networks where they can guarantee that it is
safe*. A simple implementation could say, for example, "this link is
point-to-point, so it's safe to accept zero-lifetime RAs". Those networks
where it is safe by construction (e.g,. networks that use point-to-point
links) can use this functionality.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 3 Jul 2018 13:11:29 +0200

Lorenzo,

On 07/03/2018 12:54 PM, Lorenzo Colitti wrote:
> On Tue, Jul 3, 2018 at 7:30 PM Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> construction only one router. There are many such networks - for
> example, all 4G networks are like this.

I'm not saying there are not such networks. I'm rather saying that SLAAC
operates without such constraint.

> It's only because of the security considerations. To re-state simply:

I'd clarify that in the document.

>     does not need to be protected against.

How do you get nodes to accept such RAs for these scenarios, while
preventing them from accepting malicious RAs on others?

> That's not exactly true. You need all nodes supporting this
> functionality to accept zero lifetimes *on networks where they can
> guarantee that it is safe*. A simple implementation could say, for
> example, "this link is point-to-point, so it's safe to accept
> zero-lifetime RAs". Those networks where it is safe by construction
> (e.g,. networks that use point-to-point links) can use this functionality.
What happens on the client side? i.e., are you suggesting some sort of
knob that controls whether such RAs are accepted? What does it default
to? How is th default value overriden?

Thanks,

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 3 Jul 2018 15:43:37 +0000

Thanks so much!

If you need anything from me,  just yell!  😊

Mike

From: ipv6 [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Tuesday, July 3, 2018 6:55 AM
To: Fernando Gont <[email-masked]>
Cc: 6man <[email-masked]>; lorenzo=[email-masked]; [email-masked]
Subject: Re: Fwd: New Version Notification for draft-zerorafolks-6man-ra-zero-lifetime-00.txt

On Tue, Jul 3, 2018 at 7:30 PM Fernando Gont <[email-masked]<mailto:[email-masked]>> wrote:

This proposal is limited only to those networks where there is by construction only one router. There are many such networks - for example, all 4G networks are like this.

  1.  There is only an attack vector on links where there can be more than one on-link device sending RAs to you.
  2.  There are a large number of networks that are point-to-point and therefore can only have one on-link device sending RAs to you
  3.  Therefore, on such networks, the attack vector does not exist and does not need to be protected against.
I think that if the goal is to prevent attacks, the security
considerations section should instead note that you are assuming
deployment of RA-Guard or the like.

The goal is not to prevent attacks. The goal is to be able to accept RAs with a valid lifetime of 0 on networks where it is safe to do so.

That's not exactly true. You need all nodes supporting this functionality to accept zero lifetimes *on networks where they can guarantee that it is safe*. A simple implementation could say, for example, "this link is point-to-point, so it's safe to accept zero-lifetime RAs". Those networks where it is safe by construction (e.g,. networks that use point-to-point links) can use this functionality.

The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.

---

From: "Ackermann, Michael" <[email-masked]>
Date: Tue, 3 Jul 2018 16:21:40 +0000

Please disregard
Message sent to wrong list.

From: ipv6 [mailto:[email-masked]] On Behalf Of Ackermann, Michael
Sent: Tuesday, July 3, 2018 11:44 AM
To: Lorenzo Colitti <lorenzo=[email-masked]>; Fernando Gont <[email-masked]>
Cc: 6man <[email-masked]>; [email-masked]; DePage, Joseph B. <[email-masked]>
Subject: RE: Fwd: New Version Notification for draft-zerorafolks-6man-ra-zero-lifetime-00.txt

Thanks so much!

Mike

From: ipv6 [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Tuesday, July 3, 2018 6:55 AM
To: Fernando Gont <[email-masked]<mailto:[email-masked]>>
Cc: 6man <[email-masked]<mailto:[email-masked]>>; lorenzo=[email-masked]<mailto:lorenzo=[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Fwd: New Version Notification for draft-zerorafolks-6man-ra-zero-lifetime-00.txt

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 4 Jul 2018 12:05:47 +0900

> operates without such constraint.

Right. This proposal cannot be used for SLAAC in general but only on
certain networks.

> I'd clarify that in the document.

I thought this was already pretty clear in the document. Can you be more
specific on what you'd like to see?

> preventing them from accepting malicious RAs on others?

The SLAAC implementation in the node needs to be modified. A simple
implementation could simply accept zero-lifetime RAs on any interfaces that
had the IFF_POINTOPOINT flag set, for example.

> to? How is th default value overriden?

See suggestion above. A knob is another option. Because it creates the risk
of exposing the node to DOS attacks, presumably the default would be set to
true.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 4 Jul 2018 09:48:37 +0200

On 07/04/2018 05:05 AM, Lorenzo Colitti wrote:
> On Tue, Jul 3, 2018 at 8:12 PM Fernando Gont <[email-masked]
>     > On Tue, Jul 3, 2018 at 7:30 PM Fernando Gont
>     <[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >

My question/comment is that if one expects such constraints, then that's
not slaac.

Similarly, I've seen the argument for not standardizing a default route
option for dhcpv6 is that, architecturally speaking, the DHCPv6 server
may not know wel enough about the network (among other things) -- but
the same could be said for that: in many scenarios it may know very
well, and also be configured by the same staff that plays with routers.

> specific on what you'd like to see?

You specify that this only applies if there's a single router on the
link. But if the only reason for this requirement is "security", then
you don't care how many routers are on the link, but just that there is
protection against attacks that involve spoofed RAs. e.g., if you had
something like RA-Guard (without flaws) that, say, allows RAs received
on two switch ports (where legitimate routers are connected), but all
the client ports at the switch are policed, it is irrelevant how many
routers there are on the link.

OTOH, the security considerations section *should* say that you expect
the link to be protected against attacks that involve spoofed attacks --
whether by something like ra-guard, or by segmenting the network (which,
at the end of the day, a PPP conection is doing as a side effect).

> implementation could simply accept zero-lifetime RAs on any interfaces
> that had the IFF_POINTOPOINT flag set, for example.

Spell this out in the I-D. Making this explicit makes the proposal more
sensible than if e.g. it looks like the change would apply to all
interfaces and be on by default.

That said, what about P2P links over broadcast networks? Such interfaces
would be mareked as P2P, but at the end of the day an attacker could
still perform ra-based attacks by simply encapsulating the RA packet as
appropriate....

> See suggestion above. A knob is another option. Because it creates the
> risk of exposing the node to DOS attacks, presumably the default would
> be set to true.

I think these the answers to these questions should be in the body of
the I-D.

Regardless of whether the proposal is acceptable to the wg (e.g. I have
some concerns about essentially tweaking slaac for a different operation
mode, as described above), making it explicit how this could be usable
without creating vulnerabilities (e.g., be "on" only for p2p links)
would be helpful to reduce the push-back from the wg, I'd guess.

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 4 Jul 2018 17:06:33 +0900

> My question/comment is that if one expects such constraints, then that's

I don't know what you mean by "that's not SLAAC" means, so I can't answer
that.

> well, and also be configured by the same staff that plays with routers.

That's off-topic, but there's a fundamental difference. It is a common
deployment scenario that the DHCPv6 server is off-link, centralized, and
reachable only by relays. It is never a deployment scenario that the device
receiving addresses via SLAAC is not connected to the link it's getting
addresses from. By definition, it has an interface on that link and
therefore knows what the link type is.

> routers there are on the link.

Sure. But the problem is that the client doesn't have any reliable way of
knowing if RA guard is in effect on a link. We can say that "the client
should accept zero-lifetime RAs if it knows RA guard is on", but that won't
help since it doesn't know if RA guard is on.

> at the end of the day, a PPP conection is doing as a side effect).

Sure, I can change the text to say that it's safe for the host to accept
zero-lifetime RAs if it's impossible for it to receive a spoofed RA. That
seems pretty obvious. But in order to do anything useful for this fact, the
host must know that it's on such a link.

> interfaces and be on by default.

I'll try to clarify.

> still perform ra-based attacks by simply encapsulating the RA packet as

A P2P link is by definition a link with only two nodes on it. For that
attack to work someone would have to convince the other device to decap an
RA packet without changing the TTL and forward a packet with a link-local
address, both of which are forbidden.

> would be helpful to reduce the push-back from the wg, I'd guess.

Well, you're the only one pushing back at the moment :-)

---

From: Fernando Gont <[email-masked]>
Date: Wed, 4 Jul 2018 10:27:50 +0200

On 07/04/2018 10:06 AM, Lorenzo Colitti wrote:
> On Wed, Jul 4, 2018 at 4:51 PM Fernando Gont <[email-masked]
> I don't know what you mean by "that's not SLAAC" means, so I can't
> answer that.

SLAAC doesn't impose requirements on e.g. ow many routers there can be
on the link. If now you need to change that (a condition for this to be
of use), then you are changing that fundamentalllllllll operation mode.

> reachable only by relays. It is never a deployment scenario that the
> device receiving addresses via SLAAC is not connected to the link it's
> getting addresses from. By definition, it has an interface on that link
> and therefore knows what the link type is.

My comment is: your proposal is only valid on some specific deployment
scenario. Well, a DHCPv6 option for default route is valid on some
specific deployment scenario, too.

> Sure. But the problem is that the client doesn't have any reliable way
> of knowing if RA guard is in effect on a link.

But (modulo what I say below), you could make this operate on a p2p link
because protection to such attacks is performed via network segmentation.

> We can say that "the
> client should accept zero-lifetime RAs if it knows RA guard is on", but
> that won't help since it doesn't know if RA guard is on.

What I would say is something along the lines of "this proposal is only
applicable to scenarios where nodes are protected from attacks that rely
on forged RA packets. Such protection can be provided by mechanisms such
as ra-guard, or by segmenting the network as in the case of a P2P link".

> zero-lifetime RAs if it's impossible for it to receive a spoofed RA.
> That seems pretty obvious. But in order to do anything useful for this
> fact, the host must know that it's on such a link.

Well, it has to, or otherwise it would be opening the door to attack.
So if you implement this, you might "default accept" on p2p links, and
"default deny" on everything else (in which case you'd have to somehow
override this default setting).

> attack to work someone would have to convince the other device to decap
> an RA packet without changing the TTL and forward a packet with a
> link-local address, both of which are forbidden.

If the P2P link is virtual, one could easily do that.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 4 Jul 2018 12:29:41 +0100

> If the P2P link is virtual, one could easily do that.

this is kinda the problem really.  SLAAC doesn't have a mechanism for 
determining the link type and consequently behaving differently on 
different link types.  If we accept the principal that SLAAC can do 
this, then there would be no reason not to move forward with this ID.

In order to do this, there would be a need for some type of signaling 
mechanism to get this link state information up the protocol stack and 
presented into SLAAC as a flag so that SLAAC could portably determine: 
"this is link-type X", and therefore behaviour variations could occur 
depending on the value of X.

Nick

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 4 Jul 2018 20:40:00 +0900

On Wed, Jul 4, 2018 at 8:29 PM Nick Hilliard <[email-masked]> wrote:

> different link types.

Why do you say that SLAAC needs such a mechanism? Isn't it sufficient that
SLAAC *implementations* have that mechanism? Implementations of SLAAC do
know what link type they are connected to.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 4 Jul 2018 12:41:15 +0100

Lorenzo Colitti wrote on 04/07/2018 12:40:
> Why do you say that SLAAC needs such a mechanism? Isn't it sufficient 
> that SLAAC *implementations* have that mechanism? Implementations of 
> SLAAC do know what link type they are connected to.

as Fernando pointed out, virtual links.

Nick

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 4 Jul 2018 20:43:23 +0900

> as Fernando pointed out, virtual links.

How can the implementation running on that link not know what link type it
is? If the implementation thinks a link is point-to-point when it isn't, it
will fall over completely - for example, sending packets directly on the
link without knowing that it instead has to do ND.

---

From: Ole Troan <[email-masked]>
Date: Wed, 4 Jul 2018 15:21:01 +0300

> On 4 Jul 2018, at 14:43, Lorenzo Colitti <lorenzo=[email-masked]> wrote:
> 
> How can the implementation running on that link not know what link type it is? If the implementation thinks a link is point-to-point when it isn't, it will fall over completely - for example, sending packets directly on the link without knowing that it instead has to do ND.
> -------------------------------------------------

Quite. An ND implementation must obviously need to know the data-link layer type/properties.

That “everything “ has become Ethernet has made us collectively lose the notion that IP ran on top on anything...

Ole

---

From: Fernando Gont <[email-masked]>
Date: Wed, 4 Jul 2018 14:53:41 +0200

On 07/04/2018 01:40 PM, Lorenzo Colitti wrote:
> On Wed, Jul 4, 2018 at 8:29 PM Nick Hilliard <[email-masked]
> <mailto:[email-masked]>> wrote:
> 

My point is that you cannot assume that if the link is p2p you will not
have RA-based attacks, because if the p2p link is virtual, an attacker
can forge a p2p(RA) and attack the P2P link.

Same reason for which I'm able to debug p2p virtual inks with a third
machine, even when only two systems are suppose to be on the link.

Thanks,

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 4 Jul 2018 14:34:20 +0100

> Quite. An ND implementation must obviously need to know the data-link 

obviously, yes - this is covered in the ND specification (rfc4861), but 
we're talking about SLAAC rather than ND and the whole idea about SLAAC 
is that it was intended to be far enough up the protocol chain that it 
could be insulated from issues relating to link-type peculiarities. 
This is why there is a notable absence of link-type quirks in rfc4862, 
which is remarkable, given its age.

Regarding what draft-zerorafolks-6man-ra-zero-lifetime is suggesting, do 
we carve out an exception to say that SLAAC should behave in one way in 
one specific set of circumstances and a different way in every other 
situation because it's convenient to do so?  In this case we're 
acknowledging that it's ok from a protocol design point of view to 
ignore architectural principals when they get in the way.

Or do we apply design principals and acknowledge that different 
link-type categories have different characteristics and may need 
different behaviours - which is ok, but in order to avoid layer 
violations, the SLAAC protocol would need to be formally updated to 
include the concept of a link-type SLAAC flag which could be used to 
formally determine what sort of things SLAAC should do on a particular 
link type.

> notion that IP ran on top on anything...

quite the opposite - right now, I'm on a point-to-point vpn running over 
one underlying network running docsis and another running dsl/pppoe. 
We've just become spoiled because SLAAC is so link-agnostic  :-)

Nick

---

From: David Farmer <[email-masked]>
Date: Wed, 4 Jul 2018 08:45:50 -0500

Agreed, and I think the text added to RFC 4862 is sufficiently clear and
doesn't need to be modified. However, given the prevalence of Ethernet and
other link-types that simulated Ethernet, and an abundance of clarity,
maybe someplace else in the document, be explicit that Ethernet and
Ethernet-like link-types cannot automatically know that a link is
point-to-point or not and that the added clause explicitly doesn't apply
them.

Thanks

On Wed, Jul 4, 2018 at 7:21 AM, Ole Troan <[email-masked]> wrote:

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

-- 
===============================================
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: Ole Troan <[email-masked]>
Date: Thu, 5 Jul 2018 09:43:05 +0300

Nick,

[top-posting]

What we’re talking about here is quite different from the IPv4 situation, where you have a link specific address resolution protocol (ARP) and partly link-specific configurations protocols (DHCP/IPCP). 

We already have exceptions to the lifetime rules. I don’t see that making exceptions for the case where a host is connected to a link where there by definition can only be one router makes SLAAC less link type agnostic. It makes it more aware of link properties, which I think makes sense. 

Cheers 
Ole

> On 4 Jul 2018, at 16:34, Nick Hilliard <[email-masked]> wrote:
> 
> obviously, yes - this is covered in the ND specification (rfc4861), but we're talking about SLAAC rather than ND and the whole idea about SLAAC is that it was intended to be far enough up the protocol chain that it could be insulated from issues relating to link-type peculiarities. This is why there is a notable absence of link-type quirks in rfc4862, which is remarkable, given its age.
> 
> Regarding what draft-zerorafolks-6man-ra-zero-lifetime is suggesting, do we carve out an exception to say that SLAAC should behave in one way in one specific set of circumstances and a different way in every other situation because it's convenient to do so?  In this case we're acknowledging that it's ok from a protocol design point of view to ignore architectural principals when they get in the way.
> 
> Or do we apply design principals and acknowledge that different link-type categories have different characteristics and may need different behaviours - which is ok, but in order to avoid layer violations, the SLAAC protocol would need to be formally updated to include the concept of a link-type SLAAC flag which could be used to formally determine what sort of things SLAAC should do on a particular link type.
> 
> quite the opposite - right now, I'm on a point-to-point vpn running over one underlying network running docsis and another running dsl/pppoe. We've just become spoiled because SLAAC is so link-agnostic  :-)
> 
> Nick

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 5 Jul 2018 23:09:18 +0100

Ole Troan wrote on 05/07/2018 07:43:
> What we’re talking about here is quite different from the IPv4
> situation, where you have a link specific address resolution protocol
> (ARP) and partly link-specific configurations protocols (DHCP/IPCP).

uh, ok.  Not quite sure why you're bringing ipv4 up here, but whatever.

> We already have exceptions to the lifetime rules. I don’t see that
> making exceptions for the case where a host is connected to a link
> where there by definition can only be one router makes SLAAC less
> link type agnostic. It makes it more aware of link properties, which
> I think makes sense.
I'm not arguing about whether the aim of the draft is a good idea or 
not, just that it would be a sounder idea to approach the whole thing 
from a architectural point of view and formally introduce the concept of 
link-state to SLAAC.  This can be done relatively easily by means of a 
link-type flag, for example, the sort of link-type flag that you see in 
ISIS, STP, OSPF and many other link-local protocols which have a 
requirement for doing different things on different link types based on 
parameter negotiation.

There are two reasons for suggesting this: first, it's not always 
possible for a host to determine the link type automatically and 
secondly, the draft as it stands is proposing a gigantic layer violation 
from ~L4 down to ~L1.  From an architectural point of view, this is 
ugly, and from a protocol design point of view, it's not really a good 
idea to build them into bolt-on protocol enhancements -- which is why in 
other protocols, this exact parameter is specified explicitly.

Nick

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 6 Jul 2018 10:07:27 +0900

> requirement for doing different things on different link types based on

I don't think that's a good trade-off unless you see other compelling use
cases. Adding flags and negotiations to SLAAC would increase complexity and
create opportunities for misconfiguration. We haven't needed it so far. And
as I argue below, SLAAC is actually very tightly coupled to low-level link
details.

> from ~L4 down to ~L1.

But SLAAC is really not a L4 protocol. It requires detailed knowledge of
many layer 2 and layer 3 parameters such as:

   - MAC addresses: to generate for EUI-64 and RFC 7217 IIDs
   - Link type (example: to apply custom per-link values of parameters such
   as DupAddrDetectTransmits
   - Whether the link is multicast-capable or not (it doesn't run otherwise)

It needs to be capable of sending packets that are impossible to send with
standard socket APIs, such as DAD probes with a source address of ::. It
needs to check the TTL of received messages. And so on.

>From an architectural point of view, this is

Also consider: the particular bolt-on enhancement proposed in this draft
has by construction a lime-limited lifespan. Once IPv4 is gone any link
without RA guard is entirely unusable and both the restriction in RFC 4862
section 5.5.3 and this draft will be obsolete and the standard text and
code can safely be deleted.

---

From: Ole Troan <[email-masked]>
Date: Fri, 6 Jul 2018 10:58:39 +0300

Nick,

> On 6 Jul 2018, at 01:09, Nick Hilliard <[email-masked]> wrote:
> 

You made the claim that this would make ND/SLAAC link specific. I gave examples of what that actually looks like. 

> I'm not arguing about whether the aim of the draft is a good idea or not, just that it would be a sounder idea to approach the whole thing from a architectural point of view and formally introduce the concept of link-state to SLAAC.  This can be done relatively easily by means of a link-type flag, for example, the sort of link-type flag that you see in ISIS, STP, OSPF and many other link-local protocols which have a requirement for doing different things on different link types based on parameter negotiation.

ND has some adaption to the link type. Ethernet addresses or ISATAP or links without addresses (or those that are not multicast capable). 

Those are adaptions to the properties of the link layer.

> There are two reasons for suggesting this: first, it's not always possible for a host to determine the link type automatically and secondly, the draft as it stands is proposing a gigantic layer violation from ~L4 down to ~L1.  From an architectural point of view, this is ugly, and from a protocol design point of view, it's not really a good idea to build them into bolt-on protocol enhancements -- which is why in other protocols, this exact parameter is specified explicitly.

Can you give examples of when a node is not able to know the link layer it’s connected to?

Ole

---

From: Erik Kline <[email-masked]>
Date: Fri, 6 Jul 2018 17:09:19 +0900

> Can you give examples of when a node is not able to know the link layer it’s connected to?

I think the differentiation of interest may also include properties of
the link layer to which its connected.  If I have two laptops
connected with a cross-over (or auto-idx) ethernet cable, it's both
Ethernet (which the node does know "automatically") and "effectively
P2P", which can only be known *administratively*.

The same applies to the VLAN-per-client wifi deployment model.  802.11
can be known implicitly, but "guaranteed p2p" can only be known
administratively.

---

From: Ole Troan <[email-masked]>
Date: Fri, 6 Jul 2018 11:17:56 +0300

Erik,

> can be known implicitly, but "guaranteed p2p" can only be known

Right, if you are talking about point to point Ethernet specifically. I guess there isn’t really such a thing. 

It would be nice to specify. I don’t know if that would involve IEEE or not. 

Ole

---

From: Fernando Gont <[email-masked]>
Date: Fri, 6 Jul 2018 15:19:31 +0200

> It would be nice to specify. I don’t know if that would involve IEEE or not. 

If you do p2p over e.g. ethernet, it looks like p2p, but you may still
be subject to attack.

So for virtual links, being "p2p" doesn't imply you cannot be sucject to
link-local attacks.

---

From: Ole Troan <[email-masked]>
Date: Fri, 6 Jul 2018 17:12:43 +0300

> On 6 Jul 2018, at 16:19, Fernando Gont <[email-masked]> wrote:
> 

Given that p2p “over” Ethernet is not specified I have no way of knowing what you mean. 

> So for virtual links, being "p2p" doesn't imply you cannot be sucject to

Protection of a virtual p2p might be considered a property of the link. 

Ole

---

From: Fernando Gont <[email-masked]>
Date: Fri, 6 Jul 2018 16:19:08 +0200

> Given that p2p “over” Ethernet is not specified I have no way of knowing what you mean. 

I mean, you create what looks like a point to point link, of course.

> Protection of a virtual p2p might be considered a property of the link. 

In which case, as already noted, you don't care what's the underlying
link, but what you care is whether you are protected from spoofed RAs or
not.

---

From: David Farmer <[email-masked]>
Date: Fri, 6 Jul 2018 09:34:39 -0500

> link, but what you care is whether you are protected from spoofed RAs or

Point-to-point(P2P) is both a topology and a link-type, most any link-type
can be implemented in a P2P topology, but a P2P link-type can only be
implemented in a P2P topology.  So an Ethernet can be implemented in a P2P
topology, but that doesn't make it a P2P link-type. Ethernet is most
definitely not a P2P link-type. Ethernet is a multi-access link-type.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 6 Jul 2018 16:49:22 +0200

On 07/06/2018 04:34 PM, David Farmer wrote:
> 
> 
> Point-to-point(P2P) is both a topology and a link-type, most any
> link-type can be implemented in a P2P topology, but a P2P link-type can
> only be implemented in a P2P topology.  So an Ethernet can be
> implemented in a P2P topology, but that doesn't make it a P2P link-type.
> Ethernet is most definitely not a P2P link-type. Ethernet is a
> multi-access link-type.

he-ipv6: flags=209<UP,POINTOPOINT,RUNNING,NOARP>  mtu 1480
        inet6 fe80::c90a:8407  prefixlen 64  scopeid 0x20<link>
        inet6 2001:470:4:bc9::2  prefixlen 64  scopeid 0x0<global>
        sit  txqueuelen 1000  (IPv6-in-IPv4)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

This interface has the pointopoint flag set. Still, you can spoof any
packets into it.

Thanks,

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 6 Jul 2018 16:33:11 +0100

Ole Troan wrote on 06/07/2018 08:58:
> ND has some adaption to the link type. Ethernet addresses or ISATAP 
> or links without addresses (or those that are not multicast 
> capable).
> 

I thought we had already agreed that we're talking about rfc4862 rather 
than rfc4861?

>> secondly, the draft as it stands is proposing a gigantic layer 
>> violation from ~L4 down to ~L1.  From an architectural point of 
>> view, this is ugly, and from a protocol design point of view, it's 
>> not really a good idea to build them into bolt-on protocol 
>> enhancements -- which is why in other protocols, this exact 
>> parameter is specified explicitly.
> 

We need to clarify the language here. 
draft-zerorafolks-6man-ra-zero-lifetime defines a mechanism for dropping 
the RA lifetime in situations where there is some form of link which 
connects exactly two ipv6-speaking devices.  As far as the language of 
the draft is concerned, the underlying network type is left undefined.

Separate to this, we have well defined concepts relating to different 
types of lower layer point-to-point links (e.g. radio links, NMBAs, ppp 
links, STM, tunnels, etc).  Note that there are plenty of technologies 
which enable collections of each of these link types to be bridged 
together into constructions that look like "traditional" layer 2 
broadcast domains, even if they are nothing of the sort.

Separate again to this, there are plenty of situations where you can 
define a traditional l2 broadcast domain network where only two devices 
are defined and where it would be desirable for these devices to treat 
the link as being "point-to-point" in the sense of the draft above, even 
if there is essentially nothing stopping an extra device from being 
bridged into the network.

These three things are separate but 
draft-zerorafolks-6man-ra-zero-lifetime conflates them in some ways, 
possibly because its authors have a very specific application in mind 
(relating to cellular network access), which seems to be leading them to 
suggest that creating a carve-out for their requirement isn't a big 
deal, and that it's just fine to create a protocol hack to suit their 
immediate needs.

The problem is, they're redefining value ranges relating to a core 
aspect of SLAAC in order to suit a very specific application, and the 
one thing that isn't carefully defined is the one thing that's going to 
cause problems - namely how layer 3 interfaces deal with underlying link 
characteristics, and what that means in practice.  It's no secret that 
link management on network devices is an area which causes uncommonly 
awful implementation headaches.

So, an ipv6 router in the general case has no way of canonically 
determining whether it really is on a network segment with only a single 
device at the other end, and there are applications for this draft which 
are well outside the context of the term that its authors seem to be 
thinking about.

This is why it's really not ok for this draft to gloss over this entire 
area, and why it's important for this problem to be approached from an 
architectural point of view rather than from exigency.

Nick

---

From: Mark Smith <[email-masked]>
Date: Mon, 9 Jul 2018 06:25:24 +1000

On Sat., 7 Jul. 2018, 00:35 David Farmer, <[email-masked]> wrote:

>> > Protection of a virtual p2p might be considered a property of the
>> link..
>>

A key give away is does the link support link layer addressing or not, and
how big is that address space, meaning does it support more than two
addresses.

Link layer addressing isn't needed on a true p2p link, because the only
place that a frame can be sent is to the single node at the other end of
the link.

Regards,
Mark.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 16 Jul 2018 22:30:20 -0400

> "this is link-type X", and therefore behaviour variations could occur

This seems like an internal API/implementation
issue/quality-of-implementation concern.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Michael Richardson <[email-masked]>
Date: Mon, 16 Jul 2018 23:21:06 -0400

Nick Hilliard <[email-masked]> wrote:
    > to SLAAC.  This can be done relatively easily by means of a link-type
    > flag, for example, the sort of link-type flag that you see in ISIS,
    > STP, OSPF and many other link-local protocols which have a requirement
    > for doing different

I don't think we need to transmit "this is a PPP link" on a PPP link.
Maybe we need something for ethernet to help identify the various kinds of
ways of using ethernet.  That seems like a different (orthogonal) project to
me.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 16 Jul 2018 23:25:21 -0400

> P2P", which can only be known *administratively*.

And a switch connected to a single station is essentially identical!
(And we also can't know that one laptop isn't L2-bridging to another
ethernet-like network... )

Rather than continue to claim we are doing L2-tricks to simulate the
big fat 10base1 COAX cable, I would like us to to the other way, and
admit that we build networks/meshes of P2P ethernet links.

I would be very happy to be able to set the PPP flag on an ethernet
interface (as an administrative action... maybe LLDP could determine it)

---

From: Michael Richardson <[email-masked]>
Date: Mon, 16 Jul 2018 23:27:09 -0400

> This interface has the pointopoint flag set. Still, you can spoof any

With link-local source and destination addresses?

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 17 Jul 2018 13:29:55 +0000

> From: Michael Richardson
> 
> I would be very happy to be able to set the PPP flag on an ethernet interface
> (as an administrative action... maybe LLDP could determine it)

I don't understand this. An Ethernet interface can support native IP (v4 and v6) and multiple PPPoE sessions simultaneously. What would a PPP flag on an Ethernet interface mean?

Once you have a PPPoE link up, that is its own (effectively L2, since it isn't L3) interface.
Barbara

---

From: Michael Richardson <[email-masked]>
Date: Wed, 18 Jul 2018 21:09:32 -0400

STARK, BARBARA H <[email-masked]> wrote:
    >> interface 

    > I don't understand this. An Ethernet interface can support native IP
    > (v4 and v6) and multiple PPPoE sessions simultaneously. What would a
    > PPP flag on an Ethernet interface mean?

It would mean that there is only one other station on the wire.
That ND is meaningless.

There are huge number of L2 tricks in ethernet that might where a
mesh/ring/tree of point to point ethernet links are assembled to make it look
like a single broadcast domain (orange hose).  In a network that is only
IPv6, it might be better implemented as a series of PPP IPv6 links with a L3
routing protocol, rather than an L2 routing protocol.

    > Once you have a PPPoE link up, that is its own (effectively L2, since

So I know that one can run PPPoE on the link, but I'm not really saying
one is doing that.