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

[Naveen Kottapalli <[e-mail]>]

Handling is different for that and work is in progress.

Yours,
Naveen.


On Mon, 26 Nov 2018 at 00:56, Brian E Carpenter <[e-mail]>
wrote:

> On 2018-11-26 05:44, Naveen Kottapalli wrote:
> > 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.
>
> How will all this work when the subscribers are homenets that need
> /56 or /48 prefixes?
>
>      Brian
> >
> > 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
> >> --------------------------------------------------------------------
> >>
> >
> >
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>