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

[JORDI PALET MARTINEZ <[e-mail]>]

Hi Mark,

First of all thanks a lot for this detailed review and all the text provided, and excuse the late answer (extremely overbooked the last months).

I'm still working in a review of the document (while involved in other documents to review as well), but I'm almost done with this one and will publish a new version before the cut-off.

Regards,
Jordi
@jordipalet
 
 

El 15/10/19 2:17, "v6ops en nombre de Mark Smith" <[e-mail] en nombre de [e-mail]> escribió:

    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.
    
    _______________________________________________
    v6ops mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/v6ops
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.