Subject: [v6ops] p2p links without ND

From: Mark Smith <[email-masked]>
Date: Mon, 22 Feb 2016 07:27:00 +1100

On 21 February 2016 at 21:34, Gert Doering <[email-masked]> wrote:
> Hi,
>
> On Sun, Feb 21, 2016 at 11:49:48AM +1100, Mark Smith wrote:
>> The trouble is,
>>
>> 2001:db8::/64 via p2p-link
>>
>> is ambiguous.
>>
>> It could be saying that the address space is assigned to the p2p-link
>> itself, or it could be saying the address space is behind or assigned to
>> the device at the other end of the link.
>
> A "link" does not have an address.  So it's either "the device on the
> other end" or "something behind the device on the other end", which
> does not make a difference to the device on *this* side of the link.
>
> "Stuff the packet into the tube, done".
>

So, with this "Stuff the packet into the tube, done" approach on a p2p
link, what happens if the packet's destination address isn't present
on the device or behind the device at the other end?

<snip>

Regards,
Mark.

---

From: Ivan Pepelnjak <[email-masked]>
Date: Sun, 21 Feb 2016 21:36:10 +0100

Forwarding loop. TTL expires. Welcome to the 80s.

Sent from my iPad

> On 21 Feb 2016, at 21:27, Mark Smith <[email-masked]> wrote:
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Philip Homburg <[email-masked]>
Date: Sun, 21 Feb 2016 22:13:01 +0100

>on the device or behind the device at the other end?

If the device is a host, nothing. Hosts do not forward packets.
If the prefix is not onlink, nothing (error ICMP).
If the vendor has some experience with p2p links, the router will not send
the packet back on the same p2p link as it arrived from, so again nothing.

---

From: Gert Doering <[email-masked]>
Date: Sun, 21 Feb 2016 22:29:47 +0100

Hi,

> on the device or behind the device at the other end?

What happens if you send a packet towards your default gateway and
the destination address isn't presend "behind the device at the other
end"?

It will either be sent somewhere onward, or get dropped.

Jinmei-san pointed to the RFC that explains that it MUST be dropped if
the other end points the address back towards the same link - and for
all other purposes, there is no difference between "send down the tube"
and "send to an explicitely specified gateway on a multiaccess network".

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Mark Smith <[email-masked]>
Date: Mon, 22 Feb 2016 08:43:23 +1100

On 22 Feb 2016 8:29 AM, "Gert Doering" <[email-masked]> wrote:
> the other end points the address back towards the same link

"One specific case in which a Destination Unreachable message is sent with
a code 3 is in response to a packet received by a router from a
point-to-point link, destined to an address within a subnet assigned to
that same link (other than one of the receiving router's own addresses). In
such a case, the packet MUST NOT be forwarded back onto the arrival link."

What if the receiving router doesn't know about the "subnet assigned to
that same link"?

Is it a requirement that all interfaces attached to a link have addresses
from all of the prefixes on a link? What checks for that, and where will
the error message be logged?

> - and for

---

From: Tore Anderson <[email-masked]>
Date: Sun, 21 Feb 2016 22:58:35 +0100

(snip)

«p2p links without ND» sounds like a rather shoddy implementation to
me. Even though you won't need ND to discover link-layer addreses on
p2p links, you're still going to need it for DAD, NUD, SLAAC, default
router discovery, more-specific routes discovery, RDNSS discovery, etc.
etc. etc.

From what I can tell, RFC 4861 doesn't in any way exempt p2p links from
supporting ND (see excerpt below). What exactly gave people this idea?

3.2.  Supported Link Types

   Neighbor Discovery supports links with different properties.  In the
   presence of certain properties, only a subset of the ND protocol
   mechanisms are fully specified in this document:

     point-to-point - Neighbor Discovery handles such links just like
                      multicast links.  (Multicast can be trivially
                      provided on point-to-point links, and interfaces
                      can be assigned link-local addresses.)

     multicast      - Neighbor Discovery operates over multicast capable
                      links as described in this document.

Tore

---

From: Philip Homburg <[email-masked]>
Date: Sun, 21 Feb 2016 23:34:38 +0100

In your letter dated Sun, 21 Feb 2016 22:58:35 +0100 you wrote:
> p2p links without ND sounds like a rather shoddy implementation to
> me. Even though you won't need ND to discover link-layer addreses
> on p2p links, you're still going to need it for DAD, NUD, SLAAC,
> default router discovery, more-specific routes discovery, RDNSS
> discovery, etc.  etc. etc.
> 
> From what I can tell, RFC 4861 doesn't in any way exempt p2p links
> from supporting ND (see excerpt below). What exactly gave people
> this idea?

So far I haven't seen any p2p link where the remote end responded 
to a neighbor solicitation. But maybe I'm just unlucky.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 22 Feb 2016 07:00:39 +0100 (CET)

> and "send to an explicitely specified gateway on a multiaccess network".

There is no difference here between a P2P link and broadcast media.

I've seen for instance DHCPv6-PD implementations that will not null-route 
the aggregate it receives meaning if you get a /56, you assign /64 on your 
internal interface, all the other 255 /64:s will have a nice routing loop 
ping/pong:ing between the delegating router and the DHCPv6-PD receiving 
router.

There are a lot of devices that will do the wrong thing if they're not 
configured correctly, both for p2p and broadcast media.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: [email-masked]
Date: Mon, 22 Feb 2016 09:03:00 +0100

> router discovery, more-specific routes discovery, RDNSS discovery, etc.

at least with regards to the implementations I'm familiar with, that means no ND address resolution. address resolution on a link without L2 addresses is in any case meaningless. by implication that also means we don't do NUD.

multi-access networks aren't around much any more, after the yellow cable went out of fashion. John B's draft on per host /64s, got me thinking that we can trivially represent an Ethernet (wired or wireless) as a set of point to point links. then we can largely remove dynamic address resolution also on Ethernet. for wireless that's quite attractive. anyone have the energy to join me writing it up for BA?

cheers,
Ole

---

From: Ivan Pepelnjak <[email-masked]>
Date: Mon, 22 Feb 2016 09:08:18 +0100

On Mon, Feb 22, 2016 at 9:03 AM, <[email-masked]> wrote:

> at least with regards to the implementations I'm familiar with, that means
> no ND address resolution. address resolution on a link without L2 addresses
> is in any case meaningless. by implication that also means we don't do NUD.
>
> multi-access networks aren't around much any more, after the yellow cable
> went out of fashion. John B's draft on per host /64s, got me thinking that
> we can trivially represent an Ethernet (wired or wireless) as a set of
> point to point links. then we can largely remove dynamic address resolution
> also on Ethernet. for wireless that's quite attractive. anyone have the
> energy to join me writing it up for BA?
>

Can't resist asking this question: why did we have to go through 20 years
of sidetracking and reinventing wheels to come back to the conclusions that
first-hop network device should be a router, that 64 bit addresses are long
enough and that CLNP did the right thing with host routing on the network
edge?

Cheers,
Ivan

---

From: Gert Doering <[email-masked]>
Date: Mon, 22 Feb 2016 09:21:22 +0100

Hi,

> supporting ND (see excerpt below). What exactly gave people this idea?

Implementations I know do DAD and SLAAC (dunno about NUD, though).

What is not done is link-layer address discovery, because there is no 
need to do so - and the paragraph above acknowledges this.

Mark wants implementations to do that, as far as I can discern, as he
wouldn't otherwise know whether or not the peer has a given address - and
I maintain this does not truly matter.

Gert Doering
        -- NetMaster

---

From: [email-masked]
Date: Mon, 22 Feb 2016 10:24:59 +0100

[...]

> Can't resist asking this question: why did we have to go through 20 years of sidetracking and reinventing wheels to come back to the conclusions that first-hop network device should be a router, that 64 bit addresses are long enough and that CLNP did the right thing with host routing on the network edge?

the main problem is that we are software engineers. given a set of constraints we'll figure out a solution to your problem. the constraints have typically been "router ports are expensive" or "I already have a bridge here", or my application must be on the same L2 (e.g. Bonjour).

Resulting in a very complex set of layer violating features (SAVI, RA/DHCP guards, ND/ARP snooping, multicast/unicast rewrite, RA throttling...) in bridges and APs. Perhaps the pendulum is on its way back and we have an opportunity to set things right?

A subnet model with p2p links between router and host have none of these problems.

Best regards,
Ole

---

From: Mark Smith <[email-masked]>
Date: Mon, 22 Feb 2016 20:31:25 +1100

> I maintain this does not truly matter.

So one of the reasons I think it would be useful is that it is better to
not send a packet as soon as it is known the destination doesn't exist.

Probing for an addresses presence, and then tracking its continued presence
with NUD puts a router in a position to drop the packet as soon as the
packet arrives at the link where the address space exists.

Methods such as the RFC4333 text or /127 are reactionary, they're trying to
suppress the consequences of forwarding a packet for which the destination
doesn't exist, rather than discovering if the destination exists, using an
existing discovery mechanism.

There is certainly the issue of neighbor cache DoS attacks, but we cannot
avoid having to solve or mitigate them for multiaccess links, and that
method could easily be applied to p2p links, as conceptually they can be
treated as multi access links with 2 hosts, as RFC4861 does.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 22 Feb 2016 10:33:52 +0100 (CET)

On Mon, 22 Feb 2016, [email-masked] wrote:

> Resulting in a very complex set of layer violating features (SAVI, 
> RA/DHCP guards, ND/ARP snooping, multicast/unicast rewrite, RA 
> throttling...) in bridges and APs. Perhaps the pendulum is on its way 
> back and we have an opportunity to set things right?

Yes, I hope so. I keep advising people to not share /64 between customers. 
This is perfectly doable with a lot of equipment (for instance several 
models of L3 switches from the past 5 years), but I receive pushback 
because "it's not how we do things" (which for me is a bad reason), or 
"service discovery doesn't work" (which actually is a valid concern).

I've advised some people to use protocol based vlans to make a 
vlan-per-customer for IPv6 with its own /64 per customer, and keep IPv4 
ethertypes the same way they do things now (multiple customers per vlan, 
SAVI etc), and some never thought about this and thought it was an 
interesting idea, and some others thought it was too complicated.

---

From: Mark Smith <[email-masked]>
Date: Mon, 22 Feb 2016 21:07:22 +1100

> A subnet model with p2p links between router and host have none of these problems.

So all of this is actually one of my main motivations behind:

Indicating Link-Local Unicast Destinations are Off-Link
https://tools.ietf.org/id/draft-smith-6man-link-locals-off-link-00.txt

Moving to a hub-and-spoke forwarding model at layer 2 (perhaps with
multiple hubs), gives us the ability to preserve the address space and
routing aggregation advantages that a multi-access link provides, with
all attached hosts sharing a single /64 prefix, while inserting a
router between each and every host, with the router also being a
traffic inspection point between all other destinations, allowing I
think much easier implementation of protections such as SAVI, RA/DHCP
guards etc. etc.

I think the two current gaps are:

- the link-local assumption of on-link, and the inability to override
that assumption

- multicast propagation so that protocols such as Bonjour continue to
operate across all of the same link attached hosts

I'm not at all against the idea of delegating prefixes to hosts.
However I think it should be an alternative option to multiple hosts
sharing a single /64, rather than a replacement. I can see some
networks might have a mix of both per-host/64 while others hosts still
share a /64, perhaps with a hub-and-spoke forwarding link-layer.

Regards,
Mark.

---

From: [email-masked]
Date: Mon, 22 Feb 2016 11:20:22 +0100

> https://tools.ietf.org/id/draft-smith-6man-link-locals-off-link-00.txt

in a p2p model link-local is constrained to the link. just like you expect it to be.

> - the link-local assumption of on-link, and the inability to override

that's not a gap. you most definitely do not want link-locals to work across links.

> operate across all of the same link attached hosts

protocols that can only operate on a single link are broken.
multicast on p2p links are trivial.

> share a /64, perhaps with a hub-and-spoke forwarding link-layer.

in a p2p model you can use whatever addressing model suits you.
(including single address to each endpoint on the link if you so desire.).

Best regards,
Ole

---

From: Mark Smith <[email-masked]>
Date: Mon, 22 Feb 2016 22:12:27 +1100

> in a p2p model link-local is constrained to the link. just like you expect it to be.

We're not talking about the same thing then.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 22 Feb 2016 12:39:51 +0000

Note, if the p2p link uses PPP, then there is already a keep-alive, so why use NUD on such a link?  Additionally, if both ends of the link are routers, use a /127 as specified in RFC6164.    I agree with all that Ole has said.   Also, please look at guidance in RFC 5942 for when to issue address resolution and what is on- vs. off-link. 

Hemant

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, February 22, 2016 5:20 AM
To: Mark Smith
Cc: v6ops list; Tore Anderson
Subject: Re: [v6ops] p2p links without ND

Best regards,
Ole

---

From: Tore Anderson <[email-masked]>
Date: Mon, 22 Feb 2016 14:37:16 +0100

* [email-masked]

> > p2p links, you're still going to need it for DAD, NUD, SLAAC,
> at least with regards to the implementations I'm familiar with, that
> means no ND address resolution. address resolution on a link without
> L2 addresses is in any case meaningless. by implication that also
> means we don't do NUD.

The subject of this thread says just "ND". That's much more than
address resolution. If p2p links didn't support ND full stop, then IPv6
wouldn't work in 3GPP networks as currently specified for example (they
require SLAAC).

Anyway. Address resolution might not be relevant on p2p links, but
that's not all NS/NA can be used for. The NA target link-layer _option_
is after all not mandatory on link layers that don't have addresses.

DAD is another use case that comes to mind; detecting that both sides
of the link are attempting to use, say, fe80::1, seems as useful to me
on a true p2p link as it is on an Ethernet link. But how can one do DAD
without NA?

I'll readily admit that omitting support for NA on p2p links is
unlikely to cause any major operational problems - I just haven't seen
any text in any RFC that is permitting implementers to do just that.
Unless you can point me what I've been missing, it seems rather sloppy
to me to cut that particular corner. It can't possibly be very
difficult to support, can it?

Tore

---

From: Philip Homburg <[email-masked]>
Date: Mon, 22 Feb 2016 15:35:02 +0100

In your letter dated Mon, 22 Feb 2016 14:37:16 +0100 you wrote:
> unlikely to cause any major operational problems - I just haven't
> seen any text in any RFC that is permitting implementers to do just
> that.  Unless you can point me what I've been missing, it seems
> rather sloppy to me to cut that particular corner. It can't possibly
> be very difficult to support, can it?

Like I said, it seems to be operation practice to not do NS/NA on p2p links.

Anyone have a difference experience?

---

From: Gert Doering <[email-masked]>
Date: Mon, 22 Feb 2016 15:38:08 +0100

Hi,

> on a true p2p link as it is on an Ethernet link. But how can one do DAD

PPP does DAD (for fe80:: at least) by means of IPv6CP.

Gert Doering
        -- NetMaster

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 22 Feb 2016 14:48:32 +0000

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Gert Doering
Sent: Monday, February 22, 2016 9:38 AM
To: Tore Anderson
Cc: v6ops list
Subject: Re: [v6ops] p2p links without ND

>PPP does DAD (for fe80:: at least) by means of IPv6CP.

DAD and NS/NA are twins because soon as DAD is used, the link has on-link nodes and NS/NA is also used.   If the desired behavior for p2p is to not use NS/NA, then each end of the p2p link should be configured to be off-link to each other and thus no DAD nor NS/NA is used.

Hemant

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 22 Feb 2016 16:00:43 +0100 (CET)

On Mon, 22 Feb 2016, Tore Anderson wrote:

> DAD is another use case that comes to mind; detecting that both sides of 
> the link are attempting to use, say, fe80::1, seems as useful to me on a 
> true p2p link as it is on an Ethernet link. But how can one do DAD 
> without NA?

Apart from when you're looping a POS-interface and DAD kicks in and 
disables the IPv6 part of the interface. Been there, done that.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 22 Feb 2016 16:22:05 +0100

> to a neighbor solicitation. But maybe I'm just unlucky.

In some cellular links on which I work the UE does send NS and the 
router soes seem to reply with RA.  (not sure the RA is the right thing 
to answer to an NS, and there is no identifier in these two messages to 
correlate them, like in DHCP a transaction ID).

Many recent 4G USB dongles feature real MAC addresses allocated by IEEE 
and dongle manufacturer (i.e. guaranteed unique, not random as in USBnet).

Alex

---

From: Tore Anderson <[email-masked]>
Date: Mon, 22 Feb 2016 16:36:41 +0100

* Philip Homburg

> Like I said, it seems to be operation practice to not do NS/NA on p2p

Well, NS and NA are different things, so I'll respond separately:

- Regarding NS: It makes perfect sense that you'd not see many NS
  packets on a p2p link, as there's not any link-layer addresses that
  need resolving. However I'd expect to see them as a result of DAD
  taking place, and I can imagine that NUD could be useful as well.

- Regarding NA: If an IPv6 node receives a valid NS on a p2p link, I do
  not see any reason why it should be ignored. To the best of my
  knowledge, no IPv6 standard states that a node is permitted to do so.
  Until I see differently, I'd say that an implementation that doesn't
  bother to answer NS with NA do not fully comply to the standards.
  Whether or not the interface is p2p or not makes no difference.

> Anyone have a difference experience?

Well, I just tested the only p2p link type I use daily, which is 3GPP
mobile broadband. My provider is Telenor - I think they're using
Ericsson GGSNs. All of my NSes to the GGSN's LLA were answered with NAs
just fine, so yes indeed, I do have a different experience than you.

That said, I am painfully aware that 3GPP modems are notorious for
doing all sorts of crazy stuff (ref. the recent RFC7278 thread) - but I
have reason to believe the NAs in this case are actually coming from
the GGSN and not being generated in the modem firmware:

First, I made sure to use a direct PPP connection to the serial device
so my Linux host saw a true p2p interface. No fake Ethernet or anything
like that.

Second, I observed the NS->NA delay: it was stable at around ~20-25 ms
while the link was idle, and jumped up to ~100-125 ms while I was
downloading some large files.

Third, the different NS->NA delays while the link was idle and loaded
corresponded perfectly to the RTTs in a ping6 session I had going to a
GUA in Telenor's network: 20-25 ms while idle, 100-125 ms under load.

Tore

---

From: 神明達哉 <[email-masked]>
Date: Mon, 22 Feb 2016 10:58:32 -0800

At Mon, 22 Feb 2016 08:43:23 +1100,

> What if the receiving router doesn't know about the "subnet assigned to

As I said before, this doesn't matter for the BSD implementation since
it doesn't check this condition: so in this case the packet would just
be dropped and an ICMPv6 destination error would be returned.

Yes, that's not fully compliant to what the RFC says.  But I guess
other implementations may be behaving more or less similarly in
practice.  It seems to me that some other posts in this thread
(e.g. https://mailarchive.ietf.org/arch/msg/v6ops/L_MEQZ_FgPG94c4DLGzSmZ2nISM)
suggest that may actually be the more common practice.

--
JINMEI, Tatuya

---

From: Mark Smith <[email-masked]>
Date: Tue, 23 Feb 2016 06:27:31 +1100

On 22 Feb 2016 11:39 PM, "Hemant Singh (shemant)" <[email-masked]> wrote:
>
> Note, if the p2p link uses PPP, then there is already a keep-alive, so
why use NUD on such a link?  Additionally, if both ends of the link are
routers, use a /127 as specified in RFC6164.

Probably can't (/127s work reliably in RAs?) and don't want to in
residential broadband over PPPoE - customer being able to plug a PC
directly on avoids forcing them to buy a router and is useful for
troubleshooting.

I've helped enable 100s of p2p /64s because of this requirement, and since
.au is a BYO CPE market, I desire automated robustness via protocols rather
than manual configuration, attention to detail and technical competence
from the person at the other end of the link.

How many of those PPPoE links are vulnerable to ping-pongs because of no ND
of the link? I don't know, but since I don't control the CPE, I can't
control it either.

ISPs can only rely on robustness measures on their end of the link. Since
/127s and RFC4333 measures are far end/customer end mitigations they're not
as good as local end ones.

I'd much rather have my end perform ND, not send the packet if there is no
address present, and deal with the ND cache DoS possibility - because on my
end I can, reliably.

>   I agree with all that Ole has said.   Also, please look at guidance in
RFC 5942 for when to issue address resolution and what is on- vs. off-link.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 22 Feb 2016 19:43:08 +0000

From: Mark Smith [mailto:[email-masked]] 
Sent: Monday, February 22, 2016 2:28 PM
To: Hemant Singh (shemant)
Cc: Tore Anderson; v6ops list; [email-masked]
Subject: RE: [v6ops] p2p links without ND

>Probably can't (/127s work reliably in RAs?) and don't want to in residential broadband over PPPoE - customer being able to plug a PC directly on avoids forcing them to buy a >router and is useful for troubleshooting.

I have already said if both ends of a p2p link are routers, then RFC6164 allows use of a /127.  Of course, the /127 is not configured using a prefix from the RA if that is what you meant above.   The /127 is configured manually at each end since the Subnet-Router anycast address conflicts with the /127.  

RFC6164 does not cover router to host or host to host p2p links.

Hemant

---

From: [email-masked]
Date: Mon, 22 Feb 2016 20:54:51 +0100 (CET)

> as good as local end ones.

To me a /127 is suitable for "real" p2p links (SDH/SONET and similar),
and is not really a consumer technology at all.

Some years ago I personally saw the amazing loop that could be created
with a /64 being used on an STM-256/OC-768 link between a Juniper and
a Cisco router. We quickly reconfigured to a /127. Problem solved. (For
the curious: The Gathering 2010...)

Steinar Haug, AS2116

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 22 Feb 2016 13:23:08 -0800

> at least with regards to the implementations I'm familiar with, that means no ND address resolution. address resolution on a link without L2 addresses is in any case meaningless. by implication tha…

NS/NA in a case of NUD do not need to contain LLAs. So, NUD is still 
usable as IP layer reachability detection of your next hop, right.

- Jouni

---

From: [email-masked]
Date: Tue, 23 Feb 2016 09:04:50 +0100

Jouni,

> NS/NA in a case of NUD do not need to contain LLAs. So, NUD is still usable as IP layer reachability detection of your next hop, right.

yes, but typically in this case the router wouldn't keep state for its neighbours. no state no NUD.

cheers,
Ole

---

From: Mark Smith <[email-masked]>
Date: Tue, 23 Feb 2016 20:07:49 +1100

residential broadband over PPPoE - customer being able to plug a PC
directly on avoids forcing them to buy a >router and is useful for
troubleshooting.
>
> I have already said if both ends of a p2p link are routers, then RFC6164
allows use of a /127.

I think you said use a /127, not that you were allowed to use a /127.

>Of course, the /127 is not configured using a prefix from the RA if that
is what you meant above.

What I meant was that I don't know if /127s can be conveyed in RAs, whether
residential CPE would handle them correctly, and even if they did, there
are good and valid reasons to use per customer /64s over their PPP/PPPoE
sessions.

> The /127 is configured manually at each end since the Subnet-Router
anycast address conflicts with the /127.

And certainly something you can't expect residential users to do, and a
portion of network engineers who don't pay attention to detail and who
aren't thorough.

> RFC6164 does not cover router to host or host to host p2p links.

Certainly not. The answer for p2p links isn't and cannot always be "use
/127s".

Regards,
Mark.

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Tue, 23 Feb 2016 12:15:21 +0000

From: Mark Smith [mailto:[email-masked]] 
Sent: Tuesday, February 23, 2016 4:08 AM
To: Hemant Singh (shemant)
Cc: Tore Anderson; Ole Troan; v6ops list
Subject: RE: [v6ops] p2p links without ND

>What I meant was that I don't know if /127s can be conveyed in RAs, whether residential CPE would handle them correctly, and even if they did, there are good and valid reasons to use per customer >/64s over their PPP/PPPoE sessions.

Certainly  a /127 cannot be used in an RA because the address has to be configured manually due to conflict with the anycast address.  A residential CPE has to use automatic means for address configuration.

Hemant

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 23 Feb 2016 11:09:45 -0800

Ole,

> yes, but typically in this case the router wouldn't keep state for its neighbours. no state no NUD.

The case I was after here is where the p2p link is up (thus no 
link-specific information to indicate anything is wrong) but the next 
hop IP layer is dead and the upper layer traffic one is using does not 
provide "positive reachability confirmation". Eventually failing NUD 
determines the next hop is unreachable. Not that this would fix the 
situation but atleast the stack now knows the (only) next hop it has to 
send all its packets through is unreachable..

- Jouni

---

From: [email-masked]
Date: Tue, 23 Feb 2016 20:24:56 +0100

Jouni,

> The case I was after here is where the p2p link is up (thus no link-specific information to indicate anything is wrong) but the next hop IP layer is dead and the upper layer traffic one is using does not provide "positive reachability confirmation". Eventually failing NUD determines the next hop is unreachable. Not that this would fix the situation but atleast the stack now knows the (only) next hop it has to send all its packets through is unreachable..

router - router: BFD, routing protocol keepalives
router - host: host has state (from router discovery) and can do NUD if it cares.

(assuming no L2 keepalives).

cheers,
Ole

---

From: Tore Anderson <[email-masked]>
Date: Tue, 23 Feb 2016 20:53:36 +0100

* [email-masked]

> router - host: host has state (from router discovery) and can do NUD

Yep. For that to work, though, the router will need to respond to the
host's NUD/NS queries with NAs.

My impression from reading this thread has been that some (most?)
routers/stacks won't bother to do. Have I misunderstood?

Tore

---

From: [email-masked]
Date: Tue, 23 Feb 2016 21:00:44 +0100

Tore,

> routers/stacks won't bother to do. Have I misunderstood?

I would consider that implementation broken.

cheers,
Ole

---

From: Philip Homburg <[email-masked]>
Date: Wed, 24 Feb 2016 13:15:06 +0100

>I would consider that implementation broken.

I wonder about the statistics. 

I agree that also on p2p links nodes should respond to a NS with an NA if
the address is configured on the interface.

However, if most systems at the moment don't do that, then it will be an
uphill battle.

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 25 Feb 2016 15:32:32 -0800

2/23/2016, 11:24 AM, [email-masked] kirjoitti:
>>>>> at least with regards to the implementations I'm familiar with, that means no ND addreans we don't do NUD.
>>>>ss resolution. address resolution on a link without L2 addresses is in any case meaningless. by implication that also me

Agree, though BFD or routing protocols cannot be universally assumed to 
be on all router - router links.

> router - host: host has state (from router discovery) and can do NUD if it cares.

Right, this is acually case what I mainly had in mind.

- Jouni