Re: [v6ops] New Version Notification for draft-naveen-slaac-prefix-management-00.txt

[Naveen Kottapalli <[e-mail]>]

Just adding my 2 cents.

Even in our gateway we have both SLAAC and DHCPv6.  For better routing of
subscriber traffic, though these are two different protocols we had to
assign a single prefix for each device.  In case of SLAAC we let the device
leverage the complete 128 bit address generation and in DHCPv6 case, our
box generates the 128 bit address using the same prefix, map against DUID
and sends back to the devices.  In the last 5-6 years of production till
now we have not seen any device requesting more than 1 IA_NA and even our
gateway does not support more than 1 DHCPv6 address; whereas all the
devices which got the SLAAC prefix used at most 16 addresses.

Yours,
Naveen.


On Sun, 25 Nov 2018 at 13:16, Mark Smith <[e-mail]> wrote:

> On Sun, 25 Nov 2018 at 17:16, Mikael Abrahamsson <[e-mail]> wrote:
> >
> > On Sat, 24 Nov 2018, Templin (US), Fred L wrote:
> >
> > > Do you think we should bring back RAAN?
> >
> > Yes, but also note that the relay behavior is my least concern with the
> > DHCP+RA combination. The ships in the night problem between leasetimers
> > (DHCP) and lifetimes (RA) is a much bigger concern for me.
> >
>
> (I haven't followed this thread, apologies if it has been covered.)
>
> In this scenario, I assume the DHCPv6 server is selecting the prefix
> to delegate, and the BRAS is acting as a DHCPv6 relay, which is why
> the BRAS has to glean the delegated prefix to then be able to announce
> it into the routing domain? Are the delegated prefixes dynamic or
> static, and if they're static (or at least stable across
> disconnect/connect), is it correct that the CPE's DUID is being used
> to re-issue the same delegated prefix?
>
> The reason I ask is that the IPv6 residential broadband deployment I
> worked on achieved this without gleaning via two methods:
>
> - for static delegated prefixes, the prefix is supplied as part of the
> RADIUS authentication response, which the BRAS DHCPv6 server then uses
> for DHCPv6-PD, and the BRAS can then announce into the routing domain
>
> - for dynamic delegated prefixes, the RADIUS server provided a pool
> name to allocate from, with each BRAS having a local pool with that
> name. At the time the pool name was a proprietary RADIUS attribute,
> however there is now an IETF attribute for the pool name specified in
> RFCRFC6911.
>
>
> An alternative idea, although probably more medium term, would be to
> have the CPE's receive the prefix via DHCPv6-PD, and then the CPE
> advertises the prefix itself, using automatically established eBGP
> sessions via a well known Link-Local anycast address.
>
> "IPv6 Formal Anycast Addresses and Functional Anycast Addresses"
> https://tools.ietf.org/html/draft-smith-6man-form-func-anycast-addresses-00
>
> "5.7.3.  Automatic eBGP Session Establishment"
>
> https://tools.ietf.org/html/draft-smith-6man-form-func-anycast-addresses-00#section-5.7.3
>
>
> Regards,
> Mark.
>
>
> > --
> > Mikael Abrahamsson    email: [e-mail]
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>