Subject: [v6ops] Review draft-templin-v6ops-pdhost-02

From: Edwin Cordeiro <[email-masked]>
Date: Mon, 15 Aug 2016 11:26:07 +0200

Document: draft-templin-v6ops-pdhost-02

Reviewers: Ricardo Pelaez-Negro, Edwin Cordeiro, Fred Baker, Naveen K
Lakshman (v6ops draft review team)

Review Date: 15/aug/2016

Summary: The draft provides guidelines for a host that receives a prefix
through DHCPv6-PD and want to use addresses from this prefix on its
interface, specifically in an AERO [RFC 6706] environment

Comments: The draft clearly specify how a host should behave when receiving
a prefix delegation through DHCPv6-PD and want to use addresses from the
received prefix on the interface it used to request the DHCP-PD.
Unfortunately the draft fails to clarify where such behavior is needed and
acceptable. Example of use cases would be a great improvement to provide
such context.
Another recommended improvement would be the inclusion of a diagram that
should show how the proposed behavior differs from the current
specification of IPv6 Prefix Options for DHCPv6 - RFC 3633 (
https://tools.ietf.org/html/rfc3633#section-5.1)
The draft-templin-v6ops-pdhost-02 tries to sort an ambiguity of RFC 3633,
that says "the requesting router MUST NOT assign any delegated prefixes or
subnets from the delegated prefix(es) to the link through which it received
the DHCP message from the delegating router", but RFC 3633 doesn't specify
if addresses from the prefix may be used in the receiving interface. We are
not sure if the current specification from RFC 3633 allows or not the use
of addresses from the received prefix delegation on the interface that
received the prefix delegation.

Recommendation: With a better introduction to the need for this document,
we recommend it to be adopted as working group document, if operators say
"we plan to use this proposal"

BR,

Edwin Cordeiro

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 15 Aug 2016 17:49:52 +0000

Hello Edwin,

Thank you for posting this review. See below for follow-up discussion for the
points you have raised:

Ø  Summary: The draft provides guidelines for a host that receives a prefix through DHCPv6-PD

Yes, that is accurate for the draft in its current form, but I would like to change the
draft to say that it applies to prefix delegations received through any means and not
just DHCPv6 PD. It would say that a prefix delegation includes a communication of
the prefix from the network to the host, and a representation of the prefix in the
network routing system. DHCPv6 PD would then be cited as only one example.

Ø  and want to use addresses from this prefix on its interface, specifically in an AERO [RFC 6706] environment

The correct reference for AERO is ‘draft-templin-aerolink’. But, that should be
understood as only one example – the same techniques can apply to any other
link types including, Ethernet, Wifi, etc.

Ø  Comments: The draft clearly specify how a host should behave when receiving a prefix delegation

Ø  through DHCPv6-PD and want to use addresses from the received prefix on the interface it used

Ø  to request the DHCP-PD. Unfortunately the draft fails to clarify where such behavior is needed

Ø  and acceptable. Example of use cases would be a great improvement to provide such context.

Here is some proposed text:

   “This approach is applicable to a wide variety of use cases.  For example,
   it can be used to coordinate the Virtual Private Network (VPN) links of
   mobile devices (e.g., cellphones, tablets, laptop computers, etc.)
   that connect into a home enterprise network via public access
   networks.  The approach can also be applied to aviation applications
   for both manned and unmanned aircraft where the aircraft is treated
   as a mobile host. Various other use cases are also in scope.”

Ø  Another recommended improvement would be the inclusion of a diagram that should show

Ø  how the proposed behavior differs from the current specification of IPv6 Prefix Options for

Ø  DHCPv6 - RFC 3633 (https://tools.ietf.org/html/rfc3633#section-5.1)

I would be happy to include a diagram. Thank you for the suggestion.

Ø  The draft-templin-v6ops-pdhost-02 tries to sort an ambiguity of RFC 3633, that says

Ø  "the requesting router MUST NOT assign any delegated prefixes or subnets from the

Ø  delegated prefix(es) to the link through which it received the DHCP message from the

Ø  delegating router", but RFC 3633 doesn't specify if addresses from the prefix may be

Ø  used in the receiving interface. We are not sure if the current specification from

Ø  RFC 3633 allows or not the use of addresses from the received prefix delegation

Ø  on the interface that received the prefix delegation.

Should this draft update RFC3633 (if approved)?

Thanks - Fred

From: v6ops [mailto:[email-masked]] On Behalf Of Edwin Cordeiro
Sent: Monday, August 15, 2016 2:26 AM
To: IPv6 Ops WG <[email-masked]>
Subject: [v6ops] Review draft-templin-v6ops-pdhost-02

Reviewers: Ricardo Pelaez-Negro, Edwin Cordeiro, Fred Baker, Naveen K Lakshman (v6ops draft review team)

Review Date: 15/aug/2016

Summary: The draft provides guidelines for a host that receives a prefix through DHCPv6-PD and want to use addresses from this prefix on its interface, specifically in an AERO [RFC 6706] environment

Comments: The draft clearly specify how a host should behave when receiving a prefix delegation through DHCPv6-PD and want to use addresses from the received prefix on the interface it used to request the DHCP-PD. Unfortunately the draft fails to clarify where such behavior is needed and acceptable. Example of use cases would be a great improvement to provide such context.
Another recommended improvement would be the inclusion of a diagram that should show how the proposed behavior differs from the current specification of IPv6 Prefix Options for DHCPv6 - RFC 3633 (https://tools.ietf.org/html/rfc3633#section-5.1)
The draft-templin-v6ops-pdhost-02 tries to sort an ambiguity of RFC 3633, that says "the requesting router MUST NOT assign any delegated prefixes or subnets from the delegated prefix(es) to the link through which it received the DHCP message from the delegating router", but RFC 3633 doesn't specify if addresses from the prefix may be used in the receiving interface. We are not sure if the current specification from RFC 3633 allows or not the use of addresses from the received prefix delegation on the interface that received the prefix delegation.

Recommendation: With a better introduction to the need for this document, we recommend it to be adopted as working group document, if operators say "we plan to use this proposal"

BR,

Edwin Cordeiro

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 15 Aug 2016 20:52:51 +0000

> On Aug 15, 2016, at 10:49 AM, Templin, Fred L <[email-masked]> wrote:
> 

That question belongs in 6man with support from DHC, which together wrote RFC 3633. The first question I would ask, were I them, would be whether the "ambiguity" regarding the application of a prefix to the interface the prefix was received on holds water.

For example, if the prefix is allocated using DHCP-PD or some similar protocol, but the same prefix is allocated to every host on the LAN (for some appropriate definition of that term) and each host then develops some number of addresses on that interface in a manner reminiscent of SLAAC, what is the significant difference between that and the prefix being announced in an RA, whether multicast or multi-unicast as in an NBMA network? If different prefixes are allocated to the various hosts on that same LAN and the hosts create addresses from them in a manner similar to SLAAC, is the router expected to intuit the addresses and host route them, or does this presume an SDNish model in which the router is told about the prefix allocations in some out-of-band mechanism, and installs appropriate routing? At least one conceptual question is that if a host can develop or be configured with one address and routing be made to work, is there a real difference between that and the host developing many addresses one at a time? What is the conceptual difference between having one or more addresses from a prefix on an interface, and having that prefix on the interface?

But I'm looking for neither that answer nor discussion here. It's a change to a protocol developed in another working group, and protocol development is out of scope per the charter.

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 15 Aug 2016 21:44:55 +0000

Hi Fred,

?  That question belongs in 6man with support from DHC, which together wrote RFC 3633. The first

?  question I would ask, were I them, would be whether the "ambiguity" regarding the application of

?  a prefix to the interface the prefix was received on holds water.

I don't think we need to ask questions in other groups.

?  For example, if the prefix is allocated using DHCP-PD or some similar protocol, but the same prefix

?  is allocated to every host on the LAN

That would not be prefix delegation. Prefix delegation is when the prefix is given
to a single requesting node for that node's exclusive use, and the routing system
is updated to associate the prefix with that single requesting node. The same
prefix is not announced to every host on the LAN, which would be an example
of a shared prefix and is not the same thing as a prefix delegation.

?  (for some appropriate definition of that term) and each host

?  then develops some number of addresses on that interface in a manner reminiscent of SLAAC,

The host can develop addresses to assign to the interface in any manner it chooses
(e.g., manual configuration). This document does not specific any new address
configuration methods.

?  what is the significant difference between that and the prefix being announced in an RA, whether

?  multicast or multi-unicast as in an NBMA network?

The significant difference is that the prefix is delegated for the requesting node'
own exclusive use and is not delegated or advertised to any other node. That is
why the requesting node can avoid DAD and MLD on any addresses configured
from the prefix. If the same prefix were multicast to multiple nodes on the same
link then DAD and MLD would be required. This becomes very important when
the requesting node wishes to configure many addresses for itself out of the
delegated prefix where the amount of DAD/MLD could become substantial
if a shared prefix were used.

?  If different prefixes are allocated to the various hosts on that same LAN and the hosts create

?  addresses from them in a manner similar to SLAAC, is the router expected to intuit the

?  addresses and host route them, or does this presume an SDNish model in which the router

?  is told about the prefix allocations in some out-of-band mechanism, and installs appropriate

?  routing?

The delegating router simply injects the delegated prefix into the routing system
in some fashion, and does not have any requirement for tracking the addresses
the requesting node may assign from the delegated prefix.

?  At least one conceptual question is that if a host can develop or be configured with

?  one address and routing be made to work, is there a real difference between that and

?  the host developing many addresses one at a time? What is the conceptual difference

?  between having one or more addresses from a prefix on an interface, and having that

?  prefix on the interface?

The big difference is avoidance of DAD and MLD.

?  But I'm looking for neither that answer nor discussion here. It's a change

?  to a protocol developed in another working group, and protocol development

?  is out of scope per the charter.

There is no protocol change - this is operational guidance only.

Thanks - Fred

From: Fred Baker (fred) [mailto:[email-masked]]
Sent: Monday, August 15, 2016 1:53 PM
To: Templin, Fred L <[email-masked]>
Cc: Edwin Cordeiro <[email-masked]>; IPv6 Ops WG <[email-masked]>
Subject: Re: [v6ops] Review draft-templin-v6ops-pdhost-02

On Aug 15, 2016, at 10:49 AM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 15 Aug 2016 21:50:50 +0000

> On Aug 15, 2016, at 2:44 PM, Templin, Fred L <[email-masked]> wrote:
> 
> There is no protocol change – this is operational guidance only.

Then there is no question of updating a protocol specification, is there?

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 15 Aug 2016 21:54:40 +0000

Ø  Then there is no question of updating a protocol specification, is there?

Yes, that is correct.

Thanks - Fred

Sent: Monday, August 15, 2016 2:51 PM

On Aug 15, 2016, at 2:44 PM, Templin, Fred L <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Edwin Cordeiro <[email-masked]>
Date: Tue, 16 Aug 2016 09:59:48 +0200

Hi Fred,

Below additional comments to your replies:

> Ø  and want to use addresses from this prefix on its interface,
> specifically in an AERO [RFC 6706] environment
>
>
>
​So please add some details of possible examples to provide a better
context for the need of this document.​

Ø  Comments: The draft clearly specify how a host should behave when
> receiving a prefix delegation
>
​This example is helpful, but a better explanation of the use cases would
be better.​

​The other comments were addressed by Fred Baker and I have nothing to add.

Best Regards,
Edwin Cordeiro​

>
>
>
>
> *From:* v6ops [mailto:[email-masked]] *On Behalf Of *Edwin
> Cordeiro
> *Sent:* Monday, August 15, 2016 2:26 AM
> *To:* IPv6 Ops WG <[email-masked]>
> *Subject:* [v6ops] Review draft-templin-v6ops-pdhost-02
>
>
>
> Comments: The draft clearly specify how a host should behave when
> receiving a prefix delegation through DHCPv6-PD and want to use addresses
> from the received prefix on the interface it used to request the DHCP-PD.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 18 Aug 2016 21:23:18 +0000

Hello,

A new version of this draft is now available based on review comments received.
The comments have greatly improved the document, which now also includes
figures that clearly illustrate the concepts described:

https://www.ietf.org/id/draft-templin-v6ops-pdhost-04.txt

Please review and post comments.

Thanks – Fred
[email-masked]

From: Edwin Cordeiro [mailto:[email-masked]]
Sent: Tuesday, August 16, 2016 1:00 AM
To: Templin, Fred L <[email-masked]>
Cc: IPv6 Ops WG <[email-masked]>
Subject: Re: [v6ops] Review draft-templin-v6ops-pdhost-02

Hi Fred,

Below additional comments to your replies:

>  Summary: The draft provides guidelines for a host that receives a prefix through DHCPv6-PD

>  and want to use addresses from this prefix on its interface, specifically in an AERO [RFC 6706] environment

​So please add some details of possible examples to provide a better context for the need of this document.​

>  Comments: The draft clearly specify how a host should behave when receiving a prefix delegation

>  through DHCPv6-PD and want to use addresses from the received prefix on the interface it used

>  to request the DHCP-PD. Unfortunately the draft fails to clarify where such behavior is needed

>  and acceptable. Example of use cases would be a great improvement to provide such context.

​This example is helpful, but a better explanation of the use cases would be better.​

Best Regards,
Edwin Cordeiro​

From: v6ops [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Edwin Cordeiro
Sent: Monday, August 15, 2016 2:26 AM
To: IPv6 Ops WG <[email-masked]<mailto:[email-masked]>>
Subject: [v6ops] Review draft-templin-v6ops-pdhost-02

Review Date: 15/aug/2016

BR,

Edwin Cordeiro

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 19 Aug 2016 11:53:36 +0200 (CEST)

> https://www.ietf.org/id/draft-templin-v6ops-pdhost-04.txt

Re-reading as if I never read it before:

1. Intro

" Hosts
    'Hn' on a LAN interface subsequently receive addresses 'An' taken
    from 'P' via an address autoconfiguration service such as IPv6
    Stateless Address Autoconfiguration (SLAAC) [RFC4862]."

If A=1 is used, I'd avoid using the term "receive addresses". "allocate 
addresse(s) for themselves" or similar term is more appropriate to make 
sure the reader understands the distinction.

4.

"The node also configures a default
    route that points to a router on the WAN link."

This sentence can in context confuse readers to believe that this default 
route is installed because of receiving a delegated prefix, when in fact 
this is done because the node received an RA. Right?

5. MLD/DAD Implications

This is confusing. The node still has a LL which it needs to perform 
MLD/DAD for on the WAN interface, correct? Wouldn't it be better to just 
recommend not to put the delegated prefix addresses on the WAN interface 
at all, but exlusively use a virtual interface? On that virtual interface 
then MLD/DAD can be turned off. Otherwise the WAN interface needs to 
selectively support DAD/MLD for some addresses configured on it, and not 
for others.

6.

Is the third paragraph really necessary? It describes no new 
functionality, the text seems to describe normal IPv6 operations. Seems it 
would only confuse the reader?

7.

This paragraph would be simpler if we just avoid configuring the PD based 
addresses on the WAN interface.

Summary:

I am sympathetic to hosts requesting PD and then using it to assign itself 
addresses. I just think it would be cleaner if the weak host model was 
recommended and that the PD based addresses would only be configured on a 
virtual interface in case only the WAN interface exists.

Also, calling it "WAN" interface is a bit confusing. What is a "WAN" 
interface on a host? I have no better suggestion for what to call it, WAN 
is short and "sweet" and using other names might just cause more 
confusion. The draft outlines what it means by WAN interface (good that 
you added the drawings) so it should be ok.

The draft is DHCPv6 heavy and SLAAC light when it comes to text, it seems 
to talk more about DHCPv6 functions and glosses over things that are 
configured because of RAs etc. For someone not familiar with IPv6, they 
might draw the wrong conclusions on how IPv6 works regarding RA/DHCP 
interaction and what causes what. Perhaps there should be some more 
pointers to this, and if the text is DHCP verbose, then I think it needs 
to be equally verbose on SLAAC/RA.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 23 Aug 2016 22:14:44 +0000

Hi Mikael,

Thank you for taking the time to review the document. Please see below
for follow-ups:

> -----Original Message-----
> From: Mikael Abrahamsson [mailto:[email-masked]]
> Sent: Friday, August 19, 2016 2:54 AM

How does this sound as a rewrite:

  "Hosts 'Hn' subsequently obtain one or more addresses 'An' for themselves
    via an address autoconfiguration service such as IPv6 Stateless Address
    Autoconfiguration (SLAAC) [RFC4862]."

> this is done because the node received an RA. Right?

Default routes can be configured via manual config and/or from whatever
form of autoconfiguration is appropriate for the link - of which RA is just
one example. But, maybe it would be best to simply remove this sentence
and remain silent on the subject of default routes?

> MLD/DAD for on the WAN interface, correct?

No, it is the same for LL's if DupAddrDetectTransmits is 0 - no DAD/MLD.

> Wouldn't it be better to just

The document is referring to the case where no DAD/MLD is needed for any
addresses assigned to the interface -including LL, GUA, etc.

> would only confuse the reader?

I don't mind removing the paragraph. But, in that case, I would still want
to cite I-D.templin-aerolink as an example link where this is useful.

> virtual interface in case only the WAN interface exists.

Some hosts may need to see ip_forwarding set to '1' if the addresses
are assigned to a virtual interface (e.g., a loopback) instead of the
WAN interface. Also, the MTU of the virtual interface would need
to be somehow matched to the MTU of the WAN interface in order
for TCP to correctly set its initial MSS, and that may be cumbersome
in some cases.

So, in my experience it is cleaner to assign the addresses to the WAN
interface. I am currently doing this on Androids using AERO, and the
applications seem to like it.

> you added the drawings) so it should be ok.

OK.

> to be equally verbose on SLAAC/RA.

DHCPv6 PD is cited only as an example in the first paragraph of Section 1.
Any other prefix delegation method is also in-scope. Other methods
include manual configuration, and any other prefix delegation method
that may one day be specified.

If you have specific examples of where the text seems to be inferring
DHCPv6 PD, I would be happy to make the text more generic so that
it is clear that DHCPv6 PD is only an example.

Thanks - Fred
[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 25 Aug 2016 15:40:08 +0000

Hi,

> for TCP to correctly set its initial MSS, and that may be cumbersome

I tested, and it works fine if the addresses are assigned to a loopback
(weak ES), and there is no need  to set ip_forwarding. Also, applications
see the WAN interface as the outgoing interface so I do not believe
there are any MTU issues.

What I observed is that an IPv6 address assigned to the WAN interface
is preferred if there is also an IPv6 address assigned to the loopback
interface. When there is no IPv6 address on the WAN interface, then
the loopback IPv6 address is used.

So, either or both address assignment methods will work. But, I do
not think we need to say which is preferred.

Thanks - Fred

> From: v6ops [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Tuesday, August 23, 2016 3:15 PM
> To: Mikael Abrahamsson <[email-masked]>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 25 Aug 2016 16:13:01 +0000

> there are any MTU issues.

FYI, testing was on Ubuntu linux. I have not tested on other systems.

Thanks - Fred

> Sent: Thursday, August 25, 2016 8:40 AM

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 25 Aug 2016 23:15:00 +0000

Hi - I tested on Android and found the following:

> Sent: Thursday, August 25, 2016 9:13 AM

Assignment of IPv6 addresses to loopback  interfaces is not allowed on
non-rooted Android devices. However, IPv6 addresses can be assigned
to VPN interfaces where the VPN interface is seen as the "WAN" interface.
So, for Android at least, assignment to the WAN interface seems to be
the only option.

Thanks - Fred