Re: Fwd: New Version Notification for draft-pioxfolks-6man-pio-exclusive-bit-01.txt

[Alexandre Petrescu <[e-mail]>]

Hi,

Thanks for this draft.  It seems a good and different idea for the
stated goals.  It's good also that it lists the other two mechanisms (PD
for hosts and unicast RAs).

I have some questions:
> 4.2.1.  Verify sole recipient
>
> A node receiving a PIO-X option MUST verify that it is the (likely)
> sole intended recipient of the PIO-X RA.  This done by verifying
> that the RA is unicast to the node at the IPv6 layer and, if
> applicable, at the link layer.  On links that provide the node with a
> guarantee that it is the only possible PIO-X RA recipient (e.g.  PPP,
> 3GPP links) this validation step SHOULD NOT be performed.

The intention of this section reads well.  But the offered guarantee is
not sufficient.

The specs IPv6-over-PPP and IPv6-over-3GPP links do not offer any
guarantee of the uniqueness of the Interface ID used in a link-local
address worth that name (guarantee).  Implementations do here what they
want.  Some times the IID is negotiated during the link-setup phase,
other times it is rand(), and yet other times it is derived from a "MAC"
address of this interface with a true OUI but fictitious ID, or from a
more IEEE-real interface of same computer.  These are not really
guarantees of uniqueness more than just that link.  It can be that other
computer forms the same and believes to be Xclusive recipient too.

The IPv6-over-Ethernet-and-derived specs do offer more uniqueness 
guarantees in that there is central allocation of the MAC address; hence 
the Interface ID and the subsequent link-local address are more safe to 
assume unique.  Unfortunately IPv6-over-Ethernet is not used in 3GPP or 
PPP links.

Second, how other than by ND/DAD to verify to be sole owner of that IP 
address?

>   Routers announcing PIO-X RAs may record the source (link-local)
>    address of an RS as the next hop for the exclusive prefix.

Sounds good and necessary, although I am not sure how the Router can 
assume that the source address of an RS it receives is unique 
(especially if it's link-local and formed using unspecified mechanisms). 
  There is a risk that two different 'exclusive' prefixes get a same 
next-hop.

Alex


Le 29/10/2016 à 00:17, Erik Kline a écrit :
> It still has several rough patches, but I've uploaded a -01 for
> discussion.
>
> I'd still like to get 5-7 minutes on the agenda in Seoul, if that's
> feasible.
>
>
> ---------- Forwarded message ---------- From:
> <[e-mail]> Date: 29 October 2016 at 07:14 Subject:
> New Version Notification for
> draft-pioxfolks-6man-pio-exclusive-bit-01.txt To: Mikael Abrahamsson
> <[e-mail]>, Erik Kline <[e-mail]>, Mikael
> Abrahamsson <[e-mail]>
>
>
>
> A new version of I-D, draft-pioxfolks-6man-pio-exclusive-bit-01.txt
> has been successfully submitted by Erik Kline and posted to the IETF
> repository.
>
> Name:           draft-pioxfolks-6man-pio-exclusive-bit Revision:
> 01 Title:          IPv6 Router Advertisement Prefix Information
> Option Exclusive Bit Document date:  2016-10-27 Group:
> Individual Submission Pages:          15 URL:
> https://www.ietf.org/internet-drafts/draft-pioxfolks-6man-pio-exclusive-bit-01.txt
>
>
Status:
> https://datatracker.ietf.org/doc/draft-pioxfolks-6man-pio-exclusive-bit/
>
>
Htmlized:
> https://tools.ietf.org/html/draft-pioxfolks-6man-pio-exclusive-bit-01
>
>
Diff:
> https://www.ietf.org/rfcdiff?url2=draft-pioxfolks-6man-pio-exclusive-bit-01
>
>  Abstract: This document defines a new control bit in the IPv6 RA PIO
> flags octet that indicates that the node receiving this RA is the
> exclusive receiver of all traffic destined to any address within that
> prefix.
>
> Termed the eXclusive bit (or "X bit"), nodes that recognize this can
> perform some optimizations to save time and traffic (e.g. disable ND
> and DAD for addresses within this prefix) and more immediately
> pursue the benefits of being provided multiple addresses (vis.
> [RFC7934] section 3).  Additionally, network infrastructure nodes
> (routers, switches) can benefit by minimizing the number of {link
> layer, IP} address pairs required to offer network connectivity (vis.
> [RFC7934] section 9.3).
>
> Use of the X bit is backward compatible with existing IPv6 standards
> compliant implementations.
>
>
>
>
> 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
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list [e-mail] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>