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

["jouni.nospam" <[e-mail]>]

Hi,

Just nitpicking..


> On Nov 3, 2016, at 7:23 AM, Alexandre Petrescu <[e-mail]> wrote:
> 
> 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

The 3GPP specifications and the associated NAS signaling actually
pass an IID to the UE that is guaranteed to be unique on the "3GPP link”
and the UE is supposed to form its link-local address using that IID (see
PDP Address IE and PDN Address IE). Whether the UE actually follows the
specification is another topic. (this nit is about the IID part, not
doing the verification or forming GUAs..)

- JOuni

> 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
>> --------------------------------------------------------------------
>> 
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------