Subject: New Version Notification for draft-pioxfolks-6man-pio-exclusive-bit-00.txt

From: Erik Kline <[email-masked]>
Date: Fri, 16 Sep 2016 18:29:28 +0900

A new version of I-D, draft-pioxfolks-6man-pio-exclusive-bit-00.txt
has been successfully submitted by Erik Kline and posted to the
IETF repository.

Name:           draft-pioxfolks-6man-pio-exclusive-bit
Revision:       00
Title:          IPv6 Router Advertisement Prefix Information Option
Exclusive Bit
Document date:  2016-09-16
Group:          Individual Submission
Pages:          13
URL:
https://www.ietf.org/internet-drafts/draft-pioxfolks-6man-pio-exclusive-bit-00.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-00

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 traffic-saving optimizations (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

---

From: Hemant Singh <[email-masked]>
Date: Fri, 16 Sep 2016 07:46:42 -0400

Which specific network is this draft planning to be deployed in and how
many hosts does the network have?

It's a stretch to say traffic is saved if ND and DAD are disabled.
Usually, a DAD probe is sent once by an interface.  ND performs NUD at the
rate of one NS message per sec.   MLD reports are sent every few secs or
thereabouts.

I am also not convinced of the scan attack in section 9.3 or RFC7934 since
RPF can catch if the attack packet source fails RPF.  Routers have a robust
punt path to which too many address resolutions are rate limited.  I agree
the rate limit is not fair, but at least the router does not crash,  Also,
one can use DHCPv6 Leasequery to validate an DHCPv6-assigned address or an
IPv6 PD.   A DAD Proxy on the router can also validate a specific
destination.

I will read rest of the draft and get back.

Regards,

Hemant

On Fri, Sep 16, 2016 at 5:29 AM, Erik Kline <[email-masked]> wrote:

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 16 Sep 2016 14:05:54 +0200 (CEST)

> many hosts does the network have?

Some examples:

https://tools.ietf.org/html/rfc7934 (Host Address Availability Recommendations)
https://tools.ietf.org/html/draft-ietf-v6ops-unique-ipv6-prefix-per-host-01
https://tools.ietf.org/html/draft-yourtchenko-colitti-nd-reduce-multicast-00
https://tools.ietf.org/html/draft-desmouceaux-ipv6-mcast-wifi-power-usage-01

I don't know how many references and justification are warranted within 
the draft. Also, two of four above are expired....

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Hemant Singh <[email-masked]>
Date: Fri, 16 Sep 2016 09:20:53 -0400

It's not correct to say "traffic-saving" when the use case is for
energy-saving nodes which are sleeping most of the time.   As I said, one
won't be able to convince anyone that traffic is saved because as I
articulated, the traffic is minor.   It would be good to change the text to
say something like "especially catering to energy-saving nodes which
support a sleep mode".

It would also be good to create a wiki or a ticket against 6man to collect
the reasons why draft-chakrabarti-nordmark-6man-efficient-nd  was not
adopted.  After all, this draft used an authoritative source to verify a ND
client with - the Registrar and also supports sleep mode.   6lowpan already
uses such mechanisms.

I agree, in absence of draft-chakrabarti-nordmark-6man-efficient-nd, this
X-bit is worth investigating.

Thanks,

Hemant

On Fri, Sep 16, 2016 at 8:19 AM, Mikael Abrahamsson <[email-masked]>
wrote:

> Mikael,
>> Thanks for the pointers - got it.   BTW, if we want energy-efficient IPv6
>> devices, why hasn't the 6man community
>> adopted draft-chakrabarti-nordmark-6man-efficient-nd-07 rather than folks
>> writing new Experimental drafts?  I like what
>> draft-chakrabarti-nordmark-6man-efficient-nd has done so far.
>>
>
> I don't know. I also don't see that these are in opposition to each other.
> PIO-X is a pretty big hammer, suitable for some deployments, but probably
> not for others.
>
>
> --

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 16 Sep 2016 15:38:18 +0200 (CEST)

> say something like "especially catering to energy-saving nodes which

Well, that's not the only use-case. But yes, if more people want to see 
more text on use-case, then we should extend that part. It also saves 
state in the router (imagine host that uses 50 IPv6 addresses, router 
still only has to keep single state, instead of maintaining 50 ND states, 
50 forwarding entries etc.

> It would also be good to create a wiki or a ticket against 6man to 
> collect the reasons why draft-chakrabarti-nordmark-6man-efficient-nd was 
> not adopted.  After all, this draft used an authoritative source to 
> verify a ND client with - the Registrar and also supports sleep mode. 
> 6lowpan already uses such mechanisms.

I have no opinion on this.

> X-bit is worth investigating.

I don't think they solve the same thing. They have some aspects that are 
common, some that are not.

---

From: Hemant Singh <[email-masked]>
Date: Fri, 16 Sep 2016 10:48:29 -0400

On Fri, Sep 16, 2016 at 9:38 AM, Mikael Abrahamsson <[email-masked]>
wrote:

> more text on use-case, then we should extend that part. It also saves state
> in the router (imagine host that uses 50 IPv6 addresses, router still only
> has to keep single state, instead of maintaining 50 ND states, 50
> forwarding entries etc.
>
> Which host has 50 IPv6 /128 addresses bound to one mac-address?

> I am asking the Chair to please comment on  draft-chakrabarti-nordmark-6man-efficient-nd
above.

Thanks,

Hemant

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 16 Sep 2016 18:01:24 +0200 (CEST)

> Which host has 50 IPv6 /128 addresses bound to one mac-address?

THere is nothing in the IPv6 spec that I know that limits the number of 
addresses a host can "take" on a prefix with A=1.

One of my hosts here at home has 8 within my /64. 1 EUI64 and 7 privacy 
extension ones.

---

From: joel jaeggli <[email-masked]>
Date: Fri, 16 Sep 2016 09:15:19 -0700

On 9/16/16 7:48 AM, Hemant Singh wrote:
> 
> 
> On Fri, Sep 16, 2016 at 9:38 AM, Mikael Abrahamsson <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Well, that's not the only use-case. But yes, if more people want to
>     see more text on use-case, then we should extend that part. It also
>     saves state in the router (imagine host that uses 50 IPv6 addresses,
>     router still only has to keep single state, instead of maintaining
>     50 ND states, 50 forwarding entries etc.
> 

In our server architecture we bind the delegated prefix to the loopback,
so the host answers for all them. that wouldn't be possible were L2
entries created.

> 
>         It would also be good to create a wiki or a ticket against 6man
>         to collect the reasons why
>         draft-chakrabarti-nordmark-6man-efficient-nd was not adopted. 
>         After all, this draft used an authoritative source to verify a
>         ND client with - the Registrar and also supports sleep mode.
> I am asking the Chair to please comment on
>  draft-chakrabarti-nordmark-6man-efficient-nd above.
> 
> Thanks,
> 
> Hemant
> 
> 
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 17 Sep 2016 01:20:00 +0900

>> Which host has 50 IPv6 /128 addresses bound to one mac-address?

Any host that chooses to do so.

---

From: Erik Kline <[email-masked]>
Date: Sat, 17 Sep 2016 12:09:36 +0900

This document has nothing whatsoever to do with previous efficient ND efforts.

You're right to suggest that "traffic saving" isn't a complete
description.  The traffic savings and associated energy savings are
minor compared to the traffic the node could send with the, say, 2^64
addresses it could construct.

The greatest benefits are two-fold:

    [1]  savings in terms of time

A node wanting to use a different source address for every socket need
not wait for DAD to complete, if it has knowledge that DAD is
unnecessary.

    [2] "no infrastructure is harmed in the making" of 2^N addresses

If the network and node work together, via a signal like the X bit,
then the node can do lots of things with addresses and know that it's
being "infrastructure-friendly".

Technically a node could use 2^64 optimistic addresses, but without a
signal like the X bit that will just be unfriendly toward the
infrastructure.

I have taken a note to try to clarify this in the next revision (-01).

Thanks,
-Erik

On 16 September 2016 at 22:20, Hemant Singh <[email-masked]> wrote:
> say something like "especially catering to energy-saving nodes which support
> a sleep mode".
>

---

From: Tore Anderson <[email-masked]>
Date: Mon, 19 Sep 2016 10:18:29 +0200

* Erik Kline <[email-masked]>

> has been successfully submitted by Erik Kline and posted to the

Hi Erik,

I'm thinking this mechanism could probably serve as a full replacement
for DHCPv6-PD, handing out larger-than-/64 prefixes. But as the A bit
doesn't do anything for PIOs with prefix lengths other than /64, the
receving node won't know how to use SLAAC to construct local addresses
for prefix lengths <= /63.

One way I think that could be solved would be two advertise two
semi-overlapping PIOs where one is a /64 and a subset of the other,
e.g., like so:

PIO #1 2001:db8::/48        X=1 A=1 L=0
PIO #2 2001:db8:0:1234::/64 X=1 A=1 L=0

Another way would be to include language similar to RFC3633 section
12.1: «for each IA_PD the requesting router assigns a subnet from each
of the delegated prefixes to each of the links to which the associated
interfaces are attached». Then only PIO #1 needs be sent. That won't be
backward compatible with nodes not understanding the X bit, though.

Or if this mechanism is meant only to be used with PIOs with length
equal to /64 then the document should probably say so.

Tore

---

From: Philip Homburg <[email-masked]>
Date: Mon, 19 Sep 2016 14:04:12 +0200

>has been successfully submitted by Erik Kline and posted to the

I see two issues in the current draft. The first is that somehow, routers
have to have persistent state.

Without persistent state what happens if a router reboots?

It may be possible to get around persistent state by stating that a host has to
respond to a NS for an address within the covered prefix, but I'm not sure
what other implications that might have.

The other is hosts that change MAC addresses for privacy reasons. Likely
those hosts will change the link local address as well.

Some discussion may be needed on how and why this mechanism continuous to
work in this case.

---

From: Erik Kline <[email-masked]>
Date: Tue, 20 Sep 2016 18:33:26 +0900

> equal to /64 then the document should probably say so.

In general, only SLAAC says anything specific about PIO lengths.  I
don't think document should over prescribe anything about lengths.

We could say something about some kind of "default, if you've got
nothing better to do" behaviour when the length is /64.  That would
probably, create some autoconf addresses and assign them either to
loopback or the received interface but don't do DAD.

Otherwise, I would imagine that platforms that understand the X bit
would have a mechanism to observe it and take some kind of
platform-specific action.

I'll take a note to document the "if you have no better ideas" behaviour.

---

From: Erik Kline <[email-masked]>
Date: Tue, 20 Sep 2016 18:34:50 +0900

This kind of thing only works in networks have solid layer 2
awareness.  The state maintenance burden is basically the same that of
a router that does DHCPv6-PD snooping.

I will add a comment about the state maintenance expectations for -01.

Thanks,
-Erik