Re: [v6ops] Updating RFC 7084

[Alexandre Petrescu <[e-mail]>]

Ted,

The way you use 'CE' to denote any router at the customer edge of the
network might have a sense for you, but for me it is not common talk.  I
never seen this term 'CE' used like that.  I can even say it surely
collides with another 'CE' appearing on labels on all electronics
devices here in Europe.

That said, I still look for a common router devices (Acees Point or
similar, but not the ISP's router in-home) made for in-home network that
runs a DHCPv6-PD Client.

For example, I found this Meraki device from Cisco that what appears to
be a DHCPv6-PD software, which appears to be a Client.  But this Meraki
is not the common router device in-home; it is rather the ISP's router
in-home that is used to obtain a prefix from the ISP network.  Each 
Meraki model has a WAN port.  The common router device in-home, as 
opposed to ISP's router device, does not feature a WAN port.

The documentation of Meraki is there
https://documentation.meraki.com/?title=MX%2FOther_Topics%2FIPv6_Support_on_MX_Security_%26_SD-WAN_Platforms_%255BCore_Fundamentals%255D

In the terminology section it defines DHCPv6-PD to be:
> DHCPv6-PD - Dynamic Host Configuration Protocol for IPv6 Prefix 
> Delegation is used to assign network prefixes from an ISPs DHCPv6 
> server to customer’s edge routers.

Further, in the 'LAN' section it talks strangely about 'DHCPv6-PD' like
this:
> LAN - Dual-stack LAN operations complemented by WAN simplicity. 
> Currently, MX Security & SD-WAN Platforms support the following LAN 
> features:
> 
> Auto (DHCPv6-PD)
> 
> Manual Prefixes (Auto delegation)

It sounds as if it runs DHCPv6-PD server on the LAN interface.  However,
it might be that it actually just uses some prefix it obtained from the
ISP via the DHCPv6-PD protocol on the WAN interface, and put it on the
LAN without featuring a DHCPv6-PD Server on LAN.  That is my speculation.

These two uses of 'DHCPv6-PD' in that ISP's Router documetation is very
ambiguous.

Where that ISP's Router device to run a DHCPv6-PD Server on the LAN
interface, then yes, it would conform to this
draft-winters-v6ops-cpe-lan-pd.  But otherwise no.

Then, if that ISP's Router does indeed run a DHCPv6-PD Server on the LAN
interface, and the draft-winters-v6ops-cpe-lan-pd is right, then who
might take advantage of that DHCPv6-PD Server?  Who queries it?  If
nobody queries it then there is no need of the draft.

Alex

Le 18/11/2022 à 18:27, Ted Lemon a écrit :
> A CE router is a router that is at the customer edge of the network. 
> It might be managed by the ISP, but often isn’t. If you buy a WiFi 
> router from Amazon, you are buying a CE router. If it supports IPv6, 
> as most do, then it definitely will request at least a /64 from 
> whatever it’s connected to.
> 
> Op vr 18 nov. 2022 om 10:23 schreef Alexandre Petrescu 
> <[e-mail] <mailto:[e-mail]>>
> 
> Ted,
> 
> Le 18/11/2022 à 16:13, Ted Lemon a écrit :
>> Pretty much any CE router should ask for a /48,
> 
> My question is not about a CE (customer edge) router, presumably 
> connected on the DSL or optical line.
> 
> I am asking aboout a trivial off-the-shelf access point router, or 
> some other such router like a tv router, or a printer router, or any 
> box router?  This router would not be the CE, would not be managed by
> the ISP.
> 
> I am trying to understand whether any such off-the-shelf box made for
> home networks runs DHCPv6-PD clients at all.
> 
>> although I think a lot of them don't. I don't think that the 
>> behavior currently specified in RFC7084 is quite right. I think 
>> what we want is for the CE router to always ask for a /48.
> 
> I think it makes sense for the CE router managed by the ISP to ask 
> for a /48 from the ISP network, either with its own DHCPv6-PD client 
> or with some other protocol means.
> 
>> If it gets anything narrower than a /64, it sets up a DHCPv6 PD 
>> server to sub-delegate. If it gets a /64, it sets up a relay agent
>>  and relays any downstream PD requests to the DHCP server from
>> which it got its /64. If a prefix is delegated through the relay,
>> it puts a route to that prefix in its routing table, using the IP
>> address of the DHCP client or relay from which it received the PD
>> request as its next-hop.
>> 
>> The DHCP server on the CE router only ever allocates /64s.
> 
> I think the DHCP server on the CE router should allocate any prefix 
> length on the LAN interface, not necessarily /64.
> 
> The CE router could get a /48 on its DSL line, then form a /56 and 
> allocate it to an in-home router on the LAN, which would further
> form a /57 and so on.  All with DHCPv6-PD.
> 
> In this
>> way, if the end user plugs a bunch of networks together, the edge 
>> router winds up being responsible for all sub-delegations.
> 
> Fair enough.
> 
>> 
>> Of course, there's probably a way for this to all go very very 
>> wrong if the end user creates a loop. I'm not sure how they'd do 
>> that, but it's probably possible.
> 
> True.  There are countless opportunities for this loop.  But these 
> opportunities are there anyways, regardless of the DHCPv6-PD 
> presence. With a NAT everywhere concept too it is possible to create 
> difficult loops, briges-vs-router impossible behaviours and so on, 
> especially when there are too numerous brands of devices in that
> home network.
> 
> Alex
> 
>> 
>> On Fri, Nov 18, 2022 at 10:01 AM Alexandre Petrescu 
>> <[e-mail]
> <mailto:[e-mail]> 
> <mailto:[e-mail] 
> <mailto:[e-mail]>>>
>> wrote:
>> 
>> 
>> 
>> Le 18/11/2022 à 15:47, Timothy Winters a écrit :
>>> Hello,
>>> 
>>> I've started a draft to update RFC 7084 to support prefix 
>>> delegation on the LAN interfaces.  The current state of IPv6 in 
>>> home networks is ISP are assigning prefixes of appropriate sizes
>>>  but they currently are under utilized due to the lack of prefix
>>>  delegation on LAN interfaces.
>>> 
>>> This draft is an attempt to add that support to the draft.
>>> 
>>> https://datatracker.ietf.org/doc/draft-winters-v6ops-cpe-lan-pd/
> <https://datatracker.ietf.org/doc/draft-winters-v6ops-cpe-lan-pd/>
>> <https://datatracker.ietf.org/doc/draft-winters-v6ops-cpe-lan-pd/
> <https://datatracker.ietf.org/doc/draft-winters-v6ops-cpe-lan-pd/>>
>>> 
> <https://datatracker.ietf.org/doc/draft-winters-v6ops-cpe-lan-pd/ 
> <https://datatracker.ietf.org/doc/draft-winters-v6ops-cpe-lan-pd/>
>> <https://datatracker.ietf.org/doc/draft-winters-v6ops-cpe-lan-pd/
> <https://datatracker.ietf.org/doc/draft-winters-v6ops-cpe-lan-pd/>>>
>>> 
>>> This is only an update to 7084 at the moment, there has been some
>>> discussion on the snac working group about leveraging this work
>>> as well.
>>> 
>>> One item being discussed is this currently doesn't solve 
>>> multi-homed networks.
>>> 
>>> I welcome any feedback about the proposal.
>> 
>> A general comment: my freebox would indeed take advantage of this 
>> proposal.  Currently the freebox relies on a grandma personnage to
>>  manually configure, and 'delegate' /64s to routers on LAN, out of
>> a /56 obtained on its DSL line.  She needs to add lines like this:
>> 
>> IPaddress-of-in-home-router  prefix interface
>> 
>> Were the freebox to implement a DHCPv6-PD server software, that 
>> work would be much easier, it would be automated.
>> 
>> But, is there a wifi in-home access point, or some other such kind
>>  of in-home router, that would run a DHCPv6-PD Client to request
>> the prefixes from a freebox?
>> 
>> Alex
>> 
>>> 
>>> ~Tim
>>> 
>>> _______________________________________________ v6ops mailing 
>>> list [e-mail] <mailto:[e-mail]> 
>>> <mailto:[e-mail]
> <mailto:[e-mail]>>
>> https://www.ietf.org/mailman/listinfo/v6ops
> <https://www.ietf.org/mailman/listinfo/v6ops>
>> <https://www.ietf.org/mailman/listinfo/v6ops
> <https://www.ietf.org/mailman/listinfo/v6ops>>
>> 
>> _______________________________________________ v6ops mailing list
>>  [e-mail] <mailto:[e-mail]> <mailto:[e-mail]
> <mailto:[e-mail]>>
>> https://www.ietf.org/mailman/listinfo/v6ops
> <https://www.ietf.org/mailman/listinfo/v6ops>
>> <https://www.ietf.org/mailman/listinfo/v6ops
> <https://www.ietf.org/mailman/listinfo/v6ops>>
>> 
>