Subject: Re: [v6ops] draft-templin-v6ops-pdhost discussion post-IETF 101

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 29 Apr 2018 09:25:46 +0200

Hi,

Le 29/04/2018 à 06:41, Fred Baker a écrit :
> At IETF 101, Fred Templin presented draft-templin-v6ops-pdhost. The draft is at https://tools.ietf.org/html/draft-templin-v6ops-pdhost, and his presentation deck is at https://datatracker.ietf.org/meeting/101/materials/slides-101-v6ops-ipv6-prefix-delegation-models-00.
> 
> I would like to invite discussion.
> 
> In the deck, he asks three questions:
> 1. Do we want to remain prefix delegation service agnostic, or focus on one specific service (e.g., DHCPv6-PD)?

No, we dont want to remain prefix delegation service agnostic.  An IoT 
router connected on cellular network needs more than one /64 that the 
typical RA gives.

> 2. What do we call end systems that receive a prefix delegation? Host? Router? Node?

A Router.

> 3. Does the answer to 2. depend on the weak-host, strong-host distinction?

I am not clear with respect to weak-host / strong-host distinction.  In 
linux one makes a host into a router by using a flag in the proc 
forwarding file.

There is also a flag making a router to accept RAs.  Because normally, 
only the Hosts accept RAs, not Routers.

So there are these two flags for Host / Router distinction, but I am not 
sure there is a flag to make a weak-host or a strong-host.

Alex

> 
> You are welcome, of course, to also raise any other questions or concerns.
> 
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Fred Baker <[email-masked]>
Date: Sun, 29 Apr 2018 17:18:05 -0700

No hats.

On Apr 29, 2018, at 12:25 AM, Alexandre Petrescu <[email-masked]> wrote:
> No, we dont want to remain prefix delegation service agnostic.  An IoT router connected on cellular network needs more than one /64 that the typical RA gives.

I have a different perspective. An RA tells its receiver that "on this interface" it should use a stated prefix. A router, almost by definition, has more than one interface; even a one-armed router knows to accept a packet on some virtual interface and forward it to another. An IoT device presumably receives either a configuration command (could be YANG/Netconf) specifying the addresses used on its various interfaces, or it receives an RA on at least one of them. Calling it an "IoT Router" specifies its functionality; it will forward a message received on one interface to another. I would expect a device that has a LAN interface (such as 802.11 or 802.15.4) to receive its LAN prefix on that interface, and if it also has a cellular interface, to receive a prefix or address on that one.

In saying that, I have betrayed that I also am not tied to DHCP-PD. I see no reason to arbitrarily preclude the use of other network management tools such as YANG/Netconf, nor for that matter to preclude some form of manual configuration (although I would necessarily recommend it, either). I'm quite happy to specify the use of DHCP-PD for networks that choose to use it, but I think saying that it is the ONLY way the job can be done is too prescriptive.