Subject: [v6ops] Some comments on 'IPv6 Point-to-Point Links' / draft-palet-v6ops-p2p-links-03

From: Mark Smith <[email-masked]>
Date: Tue, 15 Oct 2019 11:16:39 +1100

Hi Jordi,

I started this review a while ago, intending to get it finished before now.

It isn't finished yet, however with IETF 106 coming, there's enough
below to work on.

Regards,
Mark.

--
Hi Jordi,

Some comments on the above ID.

* 3.2.  Rationale for using /127

It may be worth mentioning that the effectiveness of this relies on
both ends of the link being configured with addresses from within the
/127, and that if that doesn't occur due to human error through
omission, nothing in IPv6 will detect and notify of that situation. If
the link is successfully carrying traffic, then people can assume the
link's configuration is correct and complete.

This is because although in IPv6 (and IPv4) we think about assigning a
prefix to a link, in reality and practice, what we actually do is
configure addresses from within a prefix to interfaces attached to a
link. There is nothing in IPv6 that demands that all interfaces
attached to a link have addresses from all of the prefixes assigned to
the link, and it is a valid IPv6 configuration if all link interfaces
don't have addresses from all link prefixes.

The only IPv6 prefix that requires all interfaces on a link to have
addresses from within it is the Link-Local prefix.

A scenario I imagine is where two people are bringing up a Internet
transit link between a service provider and a small enterprise. The
small enterprise router has a default route towards the service
provider. The service provider configures their link end with their
/127, however the small enterprise overlooks it, because it isn't a
routine task for them. As Internet access will work, it may appear
that the link has been correctly configured with /127s at both ends.
However, the ping-problem now exists with a "/127 link" due to the
default route.

This might sound a bit contrived, however the point is that humans are
involved and can make errors, and to be assured that the /127 prefix
mitigates the problem it is supposed to, human operators must check
that both addresses are configured on the link, because IPv6 won't,
and the link carrying transit traffic isn't a positive confirmation of
/127 configuration correctness.

So in this section it may be worth adding some text like:

"If using a /127 prefix, configuration of each of the addresses within
the /127 prefix, at each respective end of the link, must be actively
validated by the network operator. A missing /127 address from one end
of the link, with a local route pointing out that end of the link that
covers the missing /127 address, such as a default route, causes a
"ping-pong" scenario to exist for the missing /127 address. The link
could still be successfully carrying transit traffic, and IPv6 will
not report any errors, because IPv6 doesn't require or nor check to
ensure all interfaces attached to a link has addresses from all
prefixes assigned to the link, excepting the Link-Local prefix per
[RFC 4291]."

* Lack of full RFC 4861 ND implementation on point-to-point links

The fundamental root cause of the ping-pong problem is some IPv6
implementations not performing full Neighbor Discovery (NS/NA) on
addresses that the prefix says could exist on the link.

IPv6 implementations are assuming that all addresses within the prefix
must exist at the other end of the point-to-point link, and send the
traffic straight onto the link. If the address doesn't exist, and
there is a covering route back in the other direction, the ping-pong
problem occurs.

Full Neighbor Discovery is doing more than just resolving the
link-layer address of an IPv6 address. Neighbor Discovery is also
determining if the address exists. Even if a point-to-point link
doesn't have link-layer addresses to resolve, ND determining if an
address exists on the link is very beneficial because it will prevent
the ping-pong problem occurring entirely regardless of the IPv6 prefix
length being used on the link.

So in my above SP and small enterprise example, the service provider
router would try to ND NS for the missing far end /127, and if it
doesn't successfully discover it's existence, then the SP router won't
put packets onto the point-to-point link that would end up being
ping-ponged.

(I think this should be covered somewhere in this draft, but not
necessarily directly after 3.2 above. Just convenient to put it here
to use the SP / small enterprise example to demonstrate how performing
full ND prevents ping-pong entirely.)

* 4.  Numbering Choices

I don't think we should be referring to links as "numbered" or
"unnumbered". If "numbers" are IPv6 addresses, all links are numbered,
because RFC 4291 requires that all interfaces attached to a link have
at least a Link-Local "number" or address from the Link-Local prefix.

The principle of least surprise means that we need to be factual in
our terminology and descriptions. I could imagine somebody who doesn't
know IPv6 that well being surprised to discover their "unnumbered"
link has numbers on it. They may even briefly panic because they think
somebody breached their router security.

An completely accurate and a most least surprising term for a link
with interfaces that only has Link-Local Addresses is a "Link-Local
Addresses Only" link, or "Link-Local Only" link. "Link-Local Only" is
the also the abbreviated title of RFC 7404 "Using Only Link-Local
Addressing inside an IPv6 Network", so using that term in this ID is
consistent.

* 4.1.  GUA (Global Unicast Addresses)

nit: extra "and"  I think.

"It provides full
   functionality for both <>and<> end-points of the point-to-point links and
   consequently, facilitates troubleshooting."

probably should be:

"It provides full
   functionality for both end-points of the point-to-point links and
   consequently, facilitates troubleshooting."

* 4.2.  ULA (Unique Local Addresses)

"This
   approach may cause numerous problems and therefore is strongly
   discouraged."

I'd suggest adding in "when carrying Internet traffic". It wouldn't
cause any issues with PMTUD links carrying ULA traffic within the
local ULA domain/ /48 prefix.

i.e.

"This approach may cause numerous problems when carrying Internet
traffic and therefore is strongly discouraged."

I think it would be worth referring to RFC 6752, "Issues with Private
IP Addressing in the Internet", as it also services as more in depth
discussion on this general issue, although from a private IPv4
addressing perspective.

So something like:

"ULAs are IPv6 private addresses, not intended to be used as source or
destination addresses across the Internet. This issue also exists in
IPv4 when using RFC 1918 addresses on links carrying IPv4 Internet
traffic. [RFC 6752] discusses this issue for IPv4, with much of the
discussion applying similarly to IPv6 and ULAs."

"However, this approach is valid if, following Section 2.2 of
   [RFC4443], and despite using ULA for the point-to-point link, the
   router is configured with at least one GUA and the source of the
   ICMPv6 messages are always a GUA."

I'd suggest referencing the IPv6 Default Address Selection RFC, as
that is what will pick the GUA source address for a GUA destined
ICMPv6 message.

e.g.

"However, this approach is valid if, following Section 2.2 of
   [RFC4443], and despite using ULA for the point-to-point link, the
   router is configured with at least one GUA and the source of the
   ICMPv6 messages are always a GUA, per the IPv6 Default Address
Selection algorithm [RFC6724]."

* 4.3.  Unnumbered

Per-above, replace "unnumbered" with "Link-Local Only" or similar and
adjust the text to suit.

"While this might work for routers, it does not work for devices that
   can't request a prefix delegation over DHCPv6 and are therefore left
   without any usable GUA to allow traffic forwarding."

I'm a little confused by this. Is this describing a router can't do
DHCPv6-PD and therefore would have only link-local addresses?

Is the comment about not having a usable GUA preventing traffic
forwarding really referring to the route not having an address that
can be used for ICMPv6 messages that need to be sent across more than
one link?

If my understanding is correct, I think it might be better to say it
that way, i.e. "The router will need to have a suitable routeable
address, such as an appropriate GUA or ULA address, to use as a source
for ICMPv6 messages."

It's probably a bit of pedantry, however I expect a router with only
link-local addresses will forward packets regardless, however if it
needed to send an ICMPv6 message it would have no choice but to choose
a link-local source address due to IPv6 Default Address Selection. I
think they would be sent, however they should then be being dropped by
the next router towards the destination.

I can't think of much use for it, however I think it might be a valid
configuration. IPv6 hosts are expected to deal with ICMPv6 packets
being lost, so this would just be a perverse case of ICMPv6 packet
loss. If the hosts either don't ever trigger PMTUD, or use RFC 4821
"Packetization Layer Path MTU Discovery" then a pure link-local only
router setup might even work without issue.