Re: [v6ops] Thoughts on draft-ietf-v6ops-dhcp-pd-per-device

[Lorenzo Colitti <[e-mail]>]

On Mon, Jul 31, 2023 at 9:38 AM Nick Buraglio <[e-mail]>
wrote:

> >> It can, and that's how I had originally built it - pretty much exactly
> how an ONT or DOCSIS system works in common designs. The difference that I
> wanted to work around was that I didn't want to necessarily require a
> secondary /64 for the "host" vs the "guests" - I wanted to use the same /64
> for both to minimize complexity for troubleshooting and operational
> reasons. For those reasons I would personally prefer for the guest to
> number itself from the /64, which adds a bit more work up front but
> simplifies the overall support model.
> >
> > I couldn’t find the text in the IPv6 CE router document, but I think we
> put in a provision for running “unnumbered” northbound, and then taking a
> subnet out of the delegated prefix to put on a loopback interface.
> > That behaviour could be triggered by the node not receiving an IA_NA in
> the DHCP request and an empty PIO in the RA.
>

I think you're referring to this?

=====
   WAA-7:   If the IPv6 CE router does not acquire a global IPv6
            address(es) from either SLAAC or DHCPv6, then it MUST create
            a global IPv6 address(es) from its delegated prefix(es) and
            configure those on one of its internal virtual network
            interfaces, unless configured to require a global IPv6
            address on the WAN interface.
=====



> > It’s going to be a little tricky with this approach to share a link with
> other hosts.
> > But I think numbering the northbound interface or not that should be a
> choice by the network operator. Not by the implementation.
>
> I definitely agree that it should be up to the operator, but I also
> believe there should be guidance. This is the tricky part and if left
> unsaid there will be a wide variety of implementations that may or may not
> necessarily make sense, which will impede deployment.
> We should probably talk through how the route is installed as well and
> decide if that guidance needs to be in the document as well.
>

We do plan to leave this up to the operator. draft-collink-6man-pio-pflag
<https://datatracker.ietf.org/doc/draft-collink-6man-pio-pflag/> specifies
a PIO flag that tells the device whether to run SLAAC on the uplink or not.
If the device supports DHCPv6 IA_NA, the IA_NA would also be usable for
off-link communication. We were thinking that when the device and network
are using the deployment model described in this draft, and doesn't get any
IPv6 addresses via SLAAC or DHCPv6, it would do something like RFC 7084
WAA-7. We didn't say that in this draft because it's an operational device
and can't specify host behaviour. But perhaps we could put text to that
effect draft-collink-6man-pio-pflag
<https://datatracker.ietf.org/doc/draft-collink-6man-pio-pflag/> ?