Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft?

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 28 Nov 2017 20:37:22 +0000

See below for an updated version of this draft. This version addresses comments
received on the list regarding more clearly identifying classes of devices that can
be considered as ordinary routers.

Can we have this version as a wg item?

Thanks - Fred

-----Original Message-----
From: I-D-Announce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, November 28, 2017 12:27 PM
To: [email-masked]
Subject: I-D Action: draft-templin-v6ops-pdhost-16.txt

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

        Title           : IPv6 Prefix Delegation Models
        Author          : Fred L. Templin
	Filename        : draft-templin-v6ops-pdhost-16.txt
	Pages           : 12
	Date            : 2017-11-28

Abstract:
   IPv6 prefixes are typically delegated to requesting routers which
   then use them to number their downstream-attached links and networks.
   This document considers prefix delegation models according to whether
   the requesting router acts as a router on behalf of any downstream
   networks, as host on behalf of its local applications or as both.

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-16
https://datatracker.ietf.org/doc/html/draft-templin-v6ops-pdhost-16

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

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, 28 Nov 2017 13:40:59 -0800

> On Nov 28, 2017, at 12:37 PM, Templin, Fred L <[email-masked]> wrote:
> 

I have not gone through the entire list of comments to see if they have been addressed, but I see one quickly that has not. In figure 1, and each comparable figure, an assumption is made that the delegation is made by a specific router, referred to as the "delegating router", as opposed to "a system in the upstream network". The latter is the common case, implemented using DHCP's relay mechanism. From my perspective, if we are describing an architecture for a commonly-implemented service, it should at least describe current common implementations of the service.

I would encourage comment on the draft. Lorenzo specifically wanted material added to it to fully describe that architecture, and I'm not sure what else others had in mind. Let's get those comments on the table, and then we can decide when and whether to ask for adoption.

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 28 Nov 2017 22:02:23 +0000

Hi Fred,

> From: v6ops [mailto:[email-masked]] On Behalf Of Fred Baker
> Sent: Tuesday, November 28, 2017 1:41 PM
> To: [email-masked]
> Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft?
> 
> 
> 
> I have not gone through the entire list of comments to see if they have been addressed, but I see one quickly that has not. In figure 1,
> and each comparable figure, an assumption is made that the delegation is made by a specific router, referred to as the "delegating
> router", as opposed to "a system in the upstream network". The latter is the common case, implemented using DHCP's relay
> mechanism. From my perspective, if we are describing an architecture for a commonly-implemented service, it should at least
> describe current common implementations of the service.

I didn't add anything about this, because I thought I had already addressed your
question (you didn't respond). What you are asking is already covered in RFC3633,
and the figures in this document are derived from Section 5.1 of RFC3633. The
relay function is also addressed in RFC3633, Section 14.

Proposed resolution is to add the following sentence in the introduction:

  "Delegating/Requesting router relationships and the role of relay agents are
   discussed in [RFC6333] and apply also to this document."

Thanks - Fred

> I would encourage comment on the draft. Lorenzo specifically wanted material added to it to fully describe that architecture, and I'm
> not sure what else others had in mind. Let's get those comments on the table, and then we can decide when and whether to ask for
> adoption.
>

---

From: Paul Marks <[email-masked]>
Date: Tue, 28 Nov 2017 17:31:54 -0800

> be considered as ordinary routers.

Have you considered clarifying whether addresses at the top and bottom
of the delegated prefix (RFC 2373, RFC 2526) should be reserved under
this model?

When delegating to a host, I often wonder whether it's technically
incorrect to use prefix::0 as a normal address.  Does anyone know for
sure?

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 29 Nov 2017 15:48:59 +0000

Hi Paul,

Thanks for the reminder about this interesting question. See below:

> From: Paul Marks [mailto:[email-masked]]
> Sent: Tuesday, November 28, 2017 5:32 PM
> To: Templin, Fred L <[email-masked]>
> Cc: [email-masked]

I think in the router model, subnetting the delegated prefix would be
exactly the same as for any router. So, subnet router anycast for
example would have the same significance as in any routing hierarchy.

> incorrect to use prefix::0 as a normal address.  Does anyone know for

In the host model, I would like to say that address autoconfiguration is per
standard IPv6 procedures and leave that as out of scope for this document.
But, perhaps I could also add a reference to RFC4291(bis) and say that address
autoconfiguration must be consistent with the IPv6 addressing architecture.

About prefix::0, I think we would have to determine whether local
applications, middleboxes and/or correspondents would view that as a
special address and do something different with it than for an ordinary
GUA. But, I think that is out of scope for this document.
 
What do you think?

Thanks - Fred

---

From: james woodyatt <[email-masked]>
Date: Wed, 29 Nov 2017 10:44:49 -0800

> incorrect to use prefix::0 as a normal address.  Does anyone know for

RFC4291 pretty clearly specifies that [$prefix::] is one of the Subnet Router anycast addresses in the set of all subnets where n >= len($prefix), where the IID on the link type is (n - 128), and where the subnet prefix is [$prefix::/n].

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: Paul Marks <[email-masked]>
Date: Wed, 29 Nov 2017 15:01:49 -0800

On Wed, Nov 29, 2017 at 10:44 AM, james woodyatt <[email-masked]> wrote:

> RFC4291 pretty clearly specifies that [$prefix::] is one of the Subnet
> Router anycast addresses in the set of all subnets where n >= len($prefix),
> where the IID on the link type is (n - 128), and where the subnet prefix is
> [$prefix::/n].
>
>
RFC4291 says "a subnet prefix is associated with one link", but a pdhost
prefix is assigned to a host, which doesn't really behave like a link
(there's no neighbor discovery, for example.)

So, is a pdhost prefix actually a "subnet prefix" (with reserved
addresses), or something distinct?

I would advocate for permitting the host to do whatever it wants with the
(128-n) bits.  That could include "treat it like a regular subnet prefix"
or "build a service where every hash(content) gets an IP address."

---

From: Fred Baker <[email-masked]>
Date: Wed, 29 Nov 2017 15:32:24 -0800

> On Nov 29, 2017, at 3:01 PM, Paul Marks <[email-masked]> wrote:
> 
> RFC4291 says "a subnet prefix is associated with one link", but a pdhost prefix is assigned to a host, which doesn't really behave like a link (there's no neighbor discovery, for example.)
> 
> So, is a pdhost prefix actually a "subnet prefix" (with reserved addresses), or something distinct?

I would argue that it is a prefix, in the sense that a prefix advertised in BGP is a prefix.

> I would advocate for permitting the host to do whatever it wants with the (128-n) bits.  That could include "treat it like a regular subnet prefix" or "build a service where every hash(content) gets an IP address."

I'm not going to argue against that. That said, "every hash gets an address" works for a 64 bit IID if the hash can be expressed in 64 bits. It might argue in a direction you didn't intend. And you really don't want to make 128-n work badly for SLAAC, if fielded systems use SLACC (I'm told a number of them do).

I tend to think of the IA_PD prefix as a bundle of /64 prefixes.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 30 Nov 2017 00:16:49 +0000

I agree with Fred. The delegated prefix shows up in the routing system the
same as for any prefix, and the host needs to be the steward of the prefix
in the same sense as an ordinary router would. From the outside world,
the behavior of a host with a delegated prefix should be indiscernible from
that of an ordinary router, i.e., even though it acts as a host internally.

This brings up an interesting question, however - should the host respond
to packets addressed to the subnet router anycast address?

Thanks - Fred

> Sent: Wednesday, November 29, 2017 3:32 PM
> To: Paul Marks <[email-masked]>
> Cc: james woodyatt <[email-masked]>; [email-masked]
> > RFC4291 says "a subnet prefix is associated with one link", but a pdhost prefix is assigned to a host, which doesn't really behave like a
> link (there's no neighbor discovery, for example.)
> >
> > I would advocate for permitting the host to do whatever it wants with the (128-n) bits.  That could include "treat it like a regular
> subnet prefix" or "build a service where every hash(content) gets an IP address."
> 
> I'm not going to argue against that. That said, "every hash gets an address" works for a 64 bit IID if the hash can be expressed in 64 bits.
> It might argue in a direction you didn't intend. And you really don't want to make 128-n work badly for SLAAC, if fielded systems use
> SLACC (I'm told a number of them do).
>

---

From: james woodyatt <[email-masked]>
Date: Wed, 29 Nov 2017 16:19:50 -0800

> So, is a pdhost prefix actually a "subnet prefix" (with reserved addresses), or something distinct?

No, it is merely a routing prefix. Its length is not restricted to that defined for subnets of the link type.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 30 Nov 2017 00:22:16 +0000

Agree.

From: v6ops [mailto:[email-masked]] On Behalf Of james woodyatt
Sent: Wednesday, November 29, 2017 4:20 PM
To: Paul Marks <[email-masked]>
Cc: [email-masked]
Subject: Re: [v6ops] draft-templin-v6ops-pdhost a working group draft?

On Nov 29, 2017, at 15:01, Paul Marks <[email-masked]<mailto:[email-masked]>> wrote:

--james woodyatt <[email-masked]<mailto:[email-masked]>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 30 Nov 2017 01:45:24 +0100

> Can we have this version as a wg item?

I support adoption.

Alex