Subject: clarification regarding PIO

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 16 Nov 2016 09:29:43 +0100 (CET)

Hi,

I am confused.

http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml

3	Prefix Information	[RFC4861]
17	IP Address/Prefix Option	[RFC5568]
18	New Router Prefix Information Option	[RFC4068]

https://tools.ietf.org/html/rfc6275#section-7.2

which one of these options does the above RFC update?

We need to understand this in the PIO-X context because we're unsure if 
4861 PIO (3) format is the one we updated in the PIO-X and we chose the 
"next available bit". RFC4861 has no "updated by" documents that seems to 
introduce any new PIO flags that I can find.

So is the PIO-X draft as currently written ok, and the mobile stuff is 
either option 17 or 18 above, and we don't have to care about that because 
we're modifying option 3?

Would it make sense to modify type 17 and 18 for X bit as well?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 16 Nov 2016 17:53:28 +0900

Is it the case that the flags that can be present in each of the 3
different PIO formats:

   - Are the same, and:
   - Will remain the same in the future because they are drawn from a
   common registry?

I would certainly hope so. Anything else seems like a recipe for bugs.

On Wed, Nov 16, 2016 at 5:29 PM, Mikael Abrahamsson <[email-masked]>
wrote:

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 16 Nov 2016 18:35:46 +0900

Le 16/11/2016 à 17:29, Mikael Abrahamsson a écrit :
>  3    Prefix Information    [RFC4861] 17    IP Address/Prefix Option
> [RFC5568] 18    New Router Prefix Information Option    [RFC4068]
>

The first one (value 3). Mobile IPv6 RFC6275 modifies the PIO sent by
HAs on the home link to help them build lists of Home Agents. This
touches the same Reserved1 field that PIO-X touches currently.

(the other two are for Fast Mobile IPv6; these Options (value 17 and 18)
are not PIOs; I have never seen them on the cellular networks where you
plan for PIO-X, because there is no Mobile IPv6 on them in the first
place; you would have to check F-PMIPv6 RFC5949 too, because there are
some claims of it being used in the cellular networks where you plan for
PIO-X).

> We need to understand this in the PIO-X context because we're unsure
> if 4861 PIO (3) format is the one we updated in the PIO-X and we
> chose the "next available bit".

I agree, this check is wise to do.

> RFC4861 has no "updated by" documents that seems to introduce any new
> PIO flags that I can find.

I agree.

In this discussion, it is worth considering other ways of encoding too,
even though your suggestion may still be the best one.

One could create a new "PIO" called "PIO-X", by creating a new type for
"IPv6 Neighbor Discovery Option Formats". Presumably type 38 at
http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-5
(this is what FMIPv6 designers did when MIPv6 existed: instead of taking
an additional bit in that Reserved field they asked for a new type.)

This new option "PIO-X" would not contain the prefix itself but tell
that the preceding PIO is _the_ prefix being Xclusively for the receiver.

One would like to make sure existing implementations of receivers dont
get messed up... in this sense a separate option (PIO-X) that relates to
the unmodified option (PIO) simply being situated right after it, may
make sense. Otherwise some implementation may break just because that
Reserved field is no longer 0, and thus prohibit the stack from even
forming an address in that prefix.

This would have to be tested anyways.

Also, one would rely somehow on the RFC Flags Expansion options for RA,
although I am not sure how much implemented is it...

Alex

>
> So is the PIO-X draft as currently written ok, and the mobile stuff
> is either option 17 or 18 above, and we don't have to care about
> that because we're modifying option 3?
>

---

From: Erik Kline <[email-masked]>
Date: Thu, 17 Nov 2016 09:25:09 +0900

> touches the same Reserved1 field that PIO-X touches currently.

Thanks.  I'll update the PIO-X draft with the R bit, shift the
proposed X bit one to the right, and scan other documents for other
allocations of PIO flags...

As for a new ND option type for a new PIO-X type, I would rather not
do that.  That would completely negate the backward compatibility
benefit.

(And trying to support backward compatibility by transmitting the same
prefix in both PIO and PIO-X options in a single RA would seem to me
to be just needlessly inflating the size of the RA.)

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 17 Nov 2016 12:23:21 +0900

> do that.  That would completely negate the backward compatibility

The backward compatibility depends on how the previous implementer 
imagined the future.  One would send the new PIO-X encoding to old 
non-PIO-X computers see whether backward compatibility works.

Alex

---

From: [email-masked]
Date: Thu, 17 Nov 2016 14:25:11 +0900

Alex,

> The backward compatibility depends on how the previous implementer imagined the future.  One would send the new PIO-X encoding to old non-PIO-X computers see whether backward compatibility works.

That's not how it is specified in 4861. It is designed to be forward compatible.

Reserved1      6-bit unused field.  It MUST be initialized to zero
                     by the sender and MUST be ignored by the receiver.

Cheers,
Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 18 Nov 2016 10:55:52 +0900

Ole,

>                      by the sender and MUST be ignored by the receiver.

YEs, but as mentioned there is an update of the Reserved1 field by 
RFC6275 "Mobile IPv6":
> Reserved1
>
>       Reduced from a 6-bit field to a 5-bit field to account for the
>       addition of the above bit.

so a stack programmer will no longer bzero() that Reserved1 field and 
will no longer ignore it at receiver.

The way in which s/he does that will tell whether or not a new PIO-X bit 
is well tolerated or not.

Alex