Subject: [v6ops] draft-templin-v6ops-pdhost (RE: Review draft-templin-v6ops-pdhost-02)

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 14 Apr 2017 21:40:47 +0000

Hi, I would like to get the ball rolling again on this discussion from back in August 2016.
This is concerning 'draft-templin-v6ops-pdhost', which I have recently brought back
from the "expired" state:

https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/

See below for the discussion context. It includes proposed resolutions to comments
that have not been incorporated into the document yet pending confirmations. I
believe this document provides timely information given the current trend of the
v6ops discussions. Please send comments to the list.

Thanks - Fred

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Tuesday, August 23, 2016 3:15 PM
> To: Mikael Abrahamsson <[email-masked]>
> Cc: IPv6 Ops WG <[email-masked]>
> Subject: Re: [v6ops] Review draft-templin-v6ops-pdhost-02
> 
> 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
> > To: Templin, Fred L <[email-masked]>
> > Cc: IPv6 Ops WG <[email-masked]>
> > Subject: Re: [v6ops] Review draft-templin-v6ops-pdhost-02
> >
> > On Thu, 18 Aug 2016, Templin, Fred L wrote:
> >
> > > 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
> >
> > 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.
> 
> 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]."
> 
> > 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?
> 
> 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?
> 
> > 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?
> 
> No, it is the same for LL's if DupAddrDetectTransmits is 0 - no DAD/MLD.
> 
> > 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.
> 
> The document is referring to the case where no DAD/MLD is needed for any
> addresses assigned to the interface -including LL, GUA, etc.
> 
> > 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?
> 
> 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.
> 
> > 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.
> 
> 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.
> 
> > 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.
> 
> 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.
> 
> 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]
> 
> > --
> > Mikael Abrahamsson    email: [email-masked]
> 
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops