Subject: [v6ops] FW: I-D Action: draft-templin-v6ops-pdhost-06.txt

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 5 Sep 2017 21:27:08 +0000

Hi, here is a draft that is very closely related to RFC7934 and 'unique-ipv6-prefix-per-host'.
It described the options available for a node that receives a unique prefix delegation from
the network in terms of routing and multi-addressing considerations. It is of direct interest
to this community.

I have given my time and energies to contribute to the aforementioned v6ops docs and
would appreciate input from the working group on my document. Please see below for
abstract and URLs.

Thanks - Fred

-----Original Message-----
From: I-D-Announce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, September 05, 2017 2:16 PM
To: [email-masked]
Subject: I-D Action: draft-templin-v6ops-pdhost-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : IPv6 Prefix Delegation for Hosts
        Author          : Fred L. Templin
	Filename        : draft-templin-v6ops-pdhost-06.txt
	Pages           : 10
	Date            : 2017-09-05

Abstract:
   IPv6 prefixes are typically delegated to requesting routers which
   then use them to number their downstream-attached links and networks.
   This document considers both this traditional case, and the case when
   the "requesting router" is actually a simple host which receives a
   delegated prefix that it can use for its own internal multi-
   addressing purposes.  This latter method can be employed in a wide
   variety of use cases to allow ample address availability without
   impacting link performance.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-templin-v6ops-pdhost/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-templin-v6ops-pdhost-06
https://datatracker.ietf.org/doc/html/draft-templin-v6ops-pdhost-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-templin-v6ops-pdhost-06

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Fred Baker <[email-masked]>
Date: Tue, 5 Sep 2017 16:03:18 -0700

As requested, I'll give you my thoughts. Hats off.

Your comments seem to be focused on draft-aerolink, and specifically the model that a host uses on its WAN interface an address derived from its LAN interface (obtained via IA_PD) in a specific environment. You appear to very much want that to be part of the standard model.

The standard model of a LAN (L2) is that it has an associated subnet (L3), so that a system's address on the LAN is an address in the indicated subnet. As much as anything, this is so that IP can find a next-hop, do something similar to ARP/ND, and find the L2 encoding that will get it to that device. You're not happy, apparently, with the use of a link-local address on the LAN to replace that subnet, and I gather want the router to maintain not only the IP(v4/v6) address of the neighboring device, but its L2 parameters, wherever the Next Hop information is maintained.

I won't tell you you're wrong, but I'll tell you that it's an unusual design that requires a lot more discussion before we can reasonably expect vendors and network administrators to use it. If one wants to find it in Ethernet/Wifi/Cable Modem/DSL/FTTH/etc environments, it's not a universally-accepted viewpoint and calls for explicit discussion.

> On Sep 5, 2017, at 2:27 PM, Templin, Fred L <[email-masked]> wrote:
> 
> would appreciate input from the working group on my document.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 5 Sep 2017 23:10:25 +0000

Hi Fred,

No, this is not specifically about aerolink anymore. This is about any end system
that requests and gets an IPv6 prefix delegation in the spirit of RFC7934. It would
be worth a reread if you have not already done so - it is only 10 pages (less if you
ignore the boilerplate).

Thanks - Fred

> From: Fred Baker [mailto:[email-masked]]
> Sent: Tuesday, September 05, 2017 4:03 PM
> To: Templin, Fred L <[email-masked]>
> Cc: v6ops list <[email-masked]>
> Subject: Re: [v6ops] I-D Action: draft-templin-v6ops-pdhost-06.txt
> 
> Your comments seem to be focused on draft-aerolink, and specifically the model that a host uses on its WAN interface an address
> derived from its LAN interface (obtained via IA_PD) in a specific environment. You appear to very much want that to be part of the
> standard model.
> 
> The standard model of a LAN (L2) is that it has an associated subnet (L3), so that a system's address on the LAN is an address in the
> indicated subnet. As much as anything, this is so that IP can find a next-hop, do something similar to ARP/ND, and find the L2 encoding
> that will get it to that device. You're not happy, apparently, with the use of a link-local address on the LAN to replace that subnet, and I
> gather want the router to maintain not only the IP(v4/v6) address of the neighboring device, but its L2 parameters, wherever the
> Next Hop information is maintained.
> 
> I won't tell you you're wrong, but I'll tell you that it's an unusual design that requires a lot more discussion before we can reasonably
> expect vendors and network administrators to use it. If one wants to find it in Ethernet/Wifi/Cable Modem/DSL/FTTH/etc
> environments, it's not a universally-accepted viewpoint and calls for explicit discussion.
>

---

From: Ole Troan <[email-masked]>
Date: Wed, 6 Sep 2017 09:21:11 +0200

Hi Fred,

Thank for writing this up.

Is the only difference from doing 3633 directly, that you allow addresses from P on the interface connecting R and D?
Then the rest of the text is there to deal with that special case.

A simpler solution both to specify and to implement would just be to go with 3633 and state that addresses from P must be on a separate interface.

For the special case, you don't say anything about address resolution.
I don't see the value in supporting redirects. You already have to inject this prefix into the routing system.
(setting isRouter to True).

Replace talk of WAN link / LAN link. This usage of PD differs from 3633, in that it would typically be done within a single AS right?

Cheers,
Ole

> On 5 Sep 2017, at 23:27, Templin, Fred L <[email-masked]> wrote:
> 
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 6 Sep 2017 14:53:47 +0000

Hi Ole,

> From: Ole Troan [mailto:[email-masked]]
> Sent: Wednesday, September 06, 2017 12:21 AM

Thanks for your consideration.

> Then the rest of the text is there to deal with that special case.

This is doing RFC3633 directly, but enumerates the possibilities of what a requesting
node can do with the delegated prefix it receives.  And, it is about end systems and
not "traditional" routers as the requesting node.

> A simpler solution both to specify and to implement would just be to go with 3633 and state that addresses from P must be on a

This document is intended to be an informational/BCP and not a specification.
RFC3633 is the specification for the primary example prefix delegation service,
and the purpose of this document is only to enumerate the possibilities. 

> (setting isRouter to True).

I am considering the case where there may be large links with many thousands
or more of these kinds of end systems where it would be impractical to run a
routing protocol between all of them. So, only a few nodes on the link have
full topology information and these end systems need to discover routes
via a service like Redirect.

> Replace talk of WAN link / LAN link. This usage of PD differs from 3633, in that it would typically be done within a single AS right?

Yes, good point. I have not been in love with the WAN/LAN terminology, and
I see that RFC3633 calls these upstream/downstream interfaces. I will go with
that terminology in the next version.

Thanks - Fred