Re: [v6ops] Updating RFC 7084

[Lorenzo Colitti <[e-mail]>]

As for multihoming, how would a DHCPv6 PD client get one PD per PVD? I'd
guess that most PD clients only support one server response. In general I'm
very confused about how DHCPv6 deals with multiple servers. RFC 8415
section 18.2.10 seems to support it, but it also seems to assume that all
servers are run by the same entity, because it says things like "Advertise
messages with the highest server preference value SHOULD be preferred over
all other Advertise messages", which sort of only makes sense if the
preference values are comparable (i.e., set by the same operator).

On Fri, Nov 18, 2022 at 11:57 PM Ted Lemon <[e-mail]> wrote:

> I'll paraphrase my comment on SNAC about this, because we had a good
> discussion there and I think this is actually more of a v6ops thing than a
> SNAC thing (there's debate on the SNAC mailing list about whether we'd want
> to do multi-homing even if the infrastructure supports it).
>
> DHCPv6 PD assumes that the network is managed by a single entity, and so
> if the network is multihomed, you can communicate with a single DHCPv6
> server and get all the information you need. There are a lot of reasons why
> this is no longer correct. The first is that DHCPv6 doesn't (and can't)
> support Provisioning Domains (PvDs). The second is that a very likely
> scenario for a multi-homed home network (if any such scenario is at all
> likely!) is that you have two CE routers connected to the same link, each
> of which is advertising an RA on the link. Hosts on the link see both RAs
> and are therefore multihomed.
>
> RFC7084 doesn't talk about the PvD RA option for the simple reason that
> the document that describes it was written long after 7084. Now that we
> have such an option, it seems like an excellent way to indicate that the
> network is multi-homed: each CE router can advertise a different PvD. How
> they are defined is something we'd have to figure out, but in principle
> this seems like a reasonable approach.
>
> Why do we care? Because probably a DHCPv6 PD /client/ should be trying to
> get one PD per PvD, not one PD total. A DHCPv6 PD client that doesn't do
> this is only ever going to get a PD from one of the two CE routers, and
> which one it gets isn't going to be deterministic. So this is a really
> clear limitation for multi-homed networks in this scenario. RFC7084-bis
> could clarify how this works, and I think it should. It's possible that
> we'd also need a document in the DHC working group talking specifically
> about the DHCPv6 PD behavior in the presence of multiple PvD RAs.
>
> On Fri, Nov 18, 2022 at 9:47 AM Timothy Winters <[e-mail]> wrote:
>
>> 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/
>>
>> 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.
>>
>> ~Tim
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>