Subject: Re: [Last-Call] Last Call: <draft-ietf-6man-ra-pref64-07.txt> (Discovering PREF64 in Router Advertisements) to Proposed Standard - PLC consistency

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 6 Nov 2019 08:19:10 +0100

Le 05/11/2019 à 15:50, The IESG a écrit :
> 
> The IESG has received a request from the IPv6 Maintenance WG (6man) 
> to consider the following document: - 'Discovering PREF64 in Router 
> Advertisements' <draft-ietf-6man-ra-pref64-07.txt> as Proposed 
> Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to
> the [email-masked] mailing lists by 2019-11-27. Exceptionally,
> comments may be sent to [email-masked] instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.

Hi,

draft says:
> Scaled Lifetime field SHOULD by default be set to the lesser of 3 x 
> MaxRtrAdvInterval divided by 8, or 8191

If MaxRtrAdvInterval is 1 (RFC6275 'Mobile IPv6', radvd.conf) then the
division wont work, so the 'lesser' wouldnt be computed.

Then, by 'lifetime', in the cited text below and throughout the
document, one means the 'Scaled Lifetime' of this option, right?

> Routers SHOULD check and compare the following information:
> 
> o  set of PREF64 with non-zero lifetime;
> 
> o  set of PREF64 with zero lifetime.

Finally, for my curiosity, I wonder what kind of algorithm for checking
is consideredin each case.  Is it a precise checking, or more relaxed?
For example, how does it compare a /96 to a /64 (with a precise checking
they cant match, but with a longest match checking they could); would an
absolute or a partial majority in the set be needed to win the check, etc.

Alex

> 
> Abstract
> 
> 
> This document specifies a Neighbor Discovery option to be used in 
> Router Advertisements to communicate NAT64 prefixes to hosts.
> 
> 
> 
> 
> The file can be obtained via 
> https://datatracker.ietf.org/doc/draft-ietf-6man-ra-pref64/
> 
> IESG discussion can be tracked via 
> https://datatracker.ietf.org/doc/draft-ietf-6man-ra-pref64/ballot/
> 
> 
> No IPR declarations have been submitted directly on this I-D.
> 
> 
> 
> 
> _______________________________________________ IETF-Announce mailing
> list [email-masked] 
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: Jen Linkova <[email-masked]>
Date: Thu, 7 Nov 2019 07:08:41 +1100

> division wont work, so the 'lesser' wouldnt be computed.

We can add the following text: 'if 3 x MaxRtrAdvInterval  is less than
8 then the Scaled Lifetime field SHOULD by default be set to 1',

On the side note: it looks to me that RFC6275 contradicts 'MUST' in RFC4861:

RFC6275: "Routers supporting mobility SHOULD be able to be configured
with a smaller MinRtrAdvInterval value and MaxRtrAdvInterval value....
MinRtrAdvInterval 0.03 seconds, MaxRtrAdvInterval 0.07 seconds"
while RFC4861  states that  "MaxRtrAdvInterval ..MUST be no less than
4 seconds" and "MinRtrAdvInterval...MUST MUST be no less than 3
seconds").

At the same time RFC6275 is not formally updates RFC4861..

> document, one means the 'Scaled Lifetime' of this option, right?

It actually does not matter, as zero Scaled lifetime means zero
lifetime, and non-zero Scaled Lifetime means non-zero actual lifetime.

> absolute or a partial majority in the set be needed to win the check, etc.

2001:db8::/96 and 2001:db8::/64 are two different prefixes IMHO.
'Longest prefix match' etc applies when you are finding a prefix a
particular IP address belongs to, not when you compare two prefixes.
Also please note that it's just a check for configuration consistency
within a LAN/PvD.

> --
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call

-- 
SY, Jen Linkova aka Furry

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 7 Nov 2019 10:02:07 +0100

> particular IP address belongs to, not when you compare two prefixes.

Ok.

And with respect to the question of how many members in a set must be 
equal in order to declare consistency?  All of them?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 7 Nov 2019 14:40:55 +0100

Jen,

Le 07/11/2019 à 10:02, Alexandre Petrescu a écrit :
>>>> Scaled Lifetime field SHOULD by default be set to the lesser of
>>>> 3 x MaxRtrAdvInterval divided by 8, or 8191
>>> 
>>> If MaxRtrAdvInterval is 1 (RFC6275 'Mobile IPv6', radvd.conf)
>>> then the division wont work, so the 'lesser' wouldnt be
>>> computed.
>> 
>> We can add the following text: 'if 3 x MaxRtrAdvInterval  is less
>> than 8 then the Scaled Lifetime field SHOULD by default be set to
>> 1',

Sounds reasonable text resolution, I agree.

>> RFC6275: "Routers supporting mobility SHOULD be able to be
>> configured with a smaller MinRtrAdvInterval value and
>> MaxRtrAdvInterval value.... MinRtrAdvInterval 0.03 seconds,
>> MaxRtrAdvInterval 0.07 seconds" while RFC4861  states that
>> "MaxRtrAdvInterval ..MUST be no less than 4 seconds" and
>> "MinRtrAdvInterval...MUST MUST be no less than 3 seconds").
>> 
>> At the same time RFC6275 is not formally updates RFC4861...

I do not know.

On one hand, I fully agree: RFC6275 does not formally update RFC4861:
there is no "Updates:" tag in its front page.  In that sense one might
think about requesting an Errata for adding such a tag, in the DMM WG.

On another hand, while working with implementation I never cared to
check whether the RFC formally updates one another.  The software _had_
to be updated, yes, but not cared about the RFC because once it's an RFC
one can hardly touch on it.

Alex

>>> Finally, for my curiosity, I wonder what kind of algorithm for
>>> checking is consideredin each case.  Is it a precise checking, or
>>> more relaxed? For example, how does it compare a /96 to a /64
>>> (with a precise checking they cant match, but with a longest
>>> match checking they could); would an absolute or a partial
>>> majority in the set be needed to win the check, etc.
>> 
>> Also please note that it's just a check for configuration
>> consistency within a LAN/PvD.
>> 
>>>> 
>>>> Abstract
>>>> 
>>>> 
>>>> This document specifies a Neighbor Discovery option to be used
>>>> in Router Advertisements to communicate NAT64 prefixes to
>>>> hosts.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________ IETF-Announce
>>>> mailing list [email-masked] 
>>> -- last-call mailing list [email-masked]

---

From: Jen Linkova <[email-masked]>
Date: Fri, 8 Nov 2019 12:28:10 +1100

> one can hardly touch on it.

I'm very surprised. So let's say I'm implementing a router or I have
some other reasons to know what valid ranges for SLAAC
variables/timers are.
I open the spec (namely RFC4861) and I'd read there things like
"MaxRtrAdvInterval MUSTbe no less than 4 seconds and no greater than
1800 seconds" and "AdvDefaultLifetime MUST be either zero or between
MaxRtrAdvInterval and 9000 seconds". Then I'd check the list of
"Updated by:" and would find out that RFC8319 changed those
requirements by updating RFC4861:
"In Section 6.2.1, inside the paragraph that defines
   MaxRtrAdvInterval, change 1800 to 65535 seconds.

   In Section 6.2.1, inside the paragraph that defines
   AdvDefaultLifetime, change 9000 to 65535 seconds.".

So I'd expect that MaxRtrAdvInterval, MUST no less than 4 seconds and
no greater than 65535 seconds., while AdvDefaultLifetime MUST be
either zero or between MaxRtrAdvInterval and  65535 seconds.

I'd have no way to know that RFC6275 recommends MaxRtrAdvInterval
value outside of the allowed range.

I might be wrong but I'm under impression that if a new RFC
contradicts (== clearly violates MUST/MUST NOT) in a previous RFC, the
latter needs to be updated. Otherwise we are going to end up with
conflicting standards. If I'm wrong and it's not how it's supposed to
work that I'm going to enjoy another round of quite entertaining
discussion about inserting IPv6 extension headers, no matter what
RFC8200 says ;)

---

From: Jen Linkova <[email-masked]>
Date: Fri, 8 Nov 2019 12:54:45 +1100

> think about requesting an Errata for adding such a tag, in the DMM WG.

Submitted:
https://www.rfc-editor.org/errata/eid5898

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 8 Nov 2019 10:00:27 +0100

> https://www.rfc-editor.org/errata/eid5898

I thank you.

Alex

---

From: Ole Troan <[email-masked]>
Date: Fri, 8 Nov 2019 10:08:14 +0100

> value outside of the allowed range.

As long as you don't support Mobile IP do you care?
And largely no-one supports mobile IP.
Punted to transport.
Like all the other hard problems at the network layer.

O

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 8 Nov 2019 10:15:16 +0100

I support the document and its advancement.

Le 08/11/2019 à 02:28, Jen Linkova a écrit :
>> On one hand, I fully agree: RFC6275 does not formally update 
>> RFC4861: there is no "Updates:" tag in its front page.  In that 
>> sense one might think about requesting an Errata for adding such a 
>> tag, in the DMM WG.
>> 
>> check whether the RFC formally updates one another.  The software
>> _had_ to be updated, yes, but not cared about the RFC because once
>> it's an RFC one can hardly touch on it.
> 
> variables/timers are. I open the spec (namely RFC4861) and I'd read 
> there things like "MaxRtrAdvInterval MUSTbe no less than 4 seconds 
> and no greater than 1800 seconds" and "AdvDefaultLifetime MUST be 
> either zero or between MaxRtrAdvInterval and 9000 seconds". Then I'd 
> check the list of "Updated by:" and would find out that RFC8319 
> changed those requirements by updating RFC4861: "In Section 6.2.1, 
> inside the paragraph that defines MaxRtrAdvInterval, change 1800 to 
> 65535 seconds.
> 
> contradicts (== clearly violates MUST/MUST NOT) in a previous RFC, 
> the latter needs to be updated. Otherwise we are going to end up with
> conflicting standards.

One can only be happy to see consistency between docs - I am.

And, I can only hope that the better consistency between docs ("Update"
tags, MinRtrAdvInterval) means that PREF64 would be used where Mobile
IPv6 is used.

> If I'm wrong and it's not how it's supposed to work that I'm going
> to enjoy another round of quite entertaining discussion about
> inserting IPv6 extension headers, no matter what RFC8200 says ;)

I see what you mean :-)

I dont want that kind of entertaining discussion.

Implementation-wise, I would like to hope that, if I were an open source
implementer, I could implement and test PREF64 in its target environment
without absolutely needing to pay money.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 8 Nov 2019 11:00:06 +0100

This is a diversion to Mobile IPv6 discussion, whose place is probably 
not on this last-call email list.

> Like all the other hard problems at the network layer.

Ole,

I agree with you with the sense that Mobile IPv6 is largely not 
supported by anyone.

I like the briefness of the expression of being punted to transport 
layer like other hard problems.

However, I think the statement is too reducing.

When people implemented Mobile IPv6 and its derivatives they also 
implemented many add-ons that were needed for mobility such as driver 
support (software), WiFi handovers (link layer), NAT traversal and more. 
  Many of these aspects were migrated to 3GPP technologies, Windows 
technologies and more.  There are no RFCs for these technologies, but 
they were at least inspired, if not outright created, by works during 
Mobile IPv6 implementations.

In addition to the obvious transport layer that you mention, but that I 
dont know precisely what is referred to; in addition to the less obvious 
phy and mac layers replacements, Mobile IPv6 replacements also happen at 
application layer: maintaining connections up by a Mobile Router happen 
very often by using VPN software - I think that is app layer.  I am 
talking about deployed systems in trains and cars.

There is also the session layer: skype maintains reachability (but not 
ongoing calls) by resisting mobility events, at the session layer, I think.

So, I dont think one can reduce the Mobile IPv6 concepts to just being 
punted to transport layer.

And, as surprising as one might find, I think PREF64 is part of a set of 
technologies designed for mobility environments.  PREF64 solves a 
problem that DS-MIP (Dual Stack, RFC 5555) was supposed to solve too. 
And also a problem where 'double stack' (two stacks side by side, no 
translation) is supposed to be the best solution.

Yet, PREF64 seems to be more successful.  I do not disagree.

Alex