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

[Naveen Kottapalli <[e-mail]>]

Yours,
Naveen.


On Wed, 28 Nov 2018 at 19:00, Alexandre Petrescu <
[e-mail]> wrote:

>
>
> Le 25/11/2018 à 17:44, Naveen Kottapalli a écrit :
> > 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
>
> Funny.  You mean one home requests just one IA_NA?
> Naveen] That is what we have seen in the last 5-6 years.
>
> Where I live, an ADSL operator gives a /56 to home (with an IPv4 tool).
> Then, there is GUI for grandma where she can select which /64 goes to
> which LL address inside home.
>
> > 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.
>
> Dont put the fault on the end users.  End users do want to grow their
> edge networks, because they have more and more devices.  Listen to them
> to see what they need.
>
Naveen] I agree to what is said here.  But strangely none of the big cable
operators who are using the product live requested for support of more than
1 IA_NA or IA_TA.

>
> That (at most 16 addresses) is so because RFC4291 "IPv6 Addressing
> Architecture" has a huge problem that limits the growth of the network
> at the edge (in-house network).
>
> That huge problem is the length of the Interface ID.  RFC4291 is read by
> most Consumers to mean that the IID length is 64.  That is also read by
> most Providers to mean that within one 64 there are plenty 2^64
> addresses.  Yet only one subnet can make this work, not two.  As
> paradoxical as it might seem, one cant have two subnets in house if all
> the operator gives is but one /64.
>
> On another hand, if RFC4291 puts the IID variable length, and operator
> changes mind from fixed 64 prefixlen to a variable length too, then we
> can expect end users requesting much more than 16 addresses from one
> in-house network.
>
Naveen] Yes.  Since the current standards limit the end devices to use /64
only, it's working like that happily :)

>
> That's where Prefix Delegation operation is of high importance.
> Naveen] Agree.
> Alex
>
> >
> > Yours,
> > Naveen.
> >
> >
> > On Sun, 25 Nov 2018 at 13:16, Mark Smith <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >     On Sun, 25 Nov 2018 at 17:16, Mikael Abrahamsson <[e-mail]
> >     <mailto:[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]
> >     <mailto:[e-mail]..se>
> >      >
> >      >
> --------------------------------------------------------------------
> >      > IETF IPv6 working group mailing list
> >      > [e-mail] <mailto:[e-mail]>
> >      > Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6
> >      >
> --------------------------------------------------------------------
> >
> >     --------------------------------------------------------------------
> >     IETF IPv6 working group mailing list
> >     [e-mail] <mailto:[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
> --------------------------------------------------------------------
>