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

[Brian E Carpenter <[e-mail]>]

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
> --------------------------------------------------------------------
>