Re: [radext] [dhcwg] PPP, DHCPv6 and Prefix Delegation

[Roberta Maglione <[e-mail]>]

Please see comments inline [RM].
Regards,
Roberta

On Fri, Nov 15, 2013 at 10:11 AM, Michael Richardson
<[e-mail]>wrote:

>
> Thank you for the write up.
> It's clear that there is a gap, which TR-187 has filled.
>      http://www.broadband-forum.org/technical/download/TR-187_Issue-2.pdf
>
> RFC4241 is Informational... why didn't TR-187 come to the IETF to
> standardize
> 4241?

[RM] Well, basically there were no new protocol extensions to be
standardized in order to cover this scenario;  the missing piece was a
document where to glue together all the different pieces and specify
requirements for CPE and BNG, that's why we (speaking as one of the
co-editors of TR-187) did this work at the BBF/


> (Will TR-187 get re-issued with the reference to access-16 changed to
> RFC6911?)
>
[RM] Well I don't yet, maybe, I need to speak with the other co-editors
none of us is actively involved in BBF anymore.


> ===
> I was wondering this week whether or not the WAN link needed other than
> link-local addresses, and it seems to me that this depends very much on
> whether or not the CPE is going to do all of 6204 or not.
>
[RM] This is really a Service Provider's preference: there are operators
that prefer numbered model (for management/security purposes) and others
that are fine with just the link-local and the loopback for management. We
had a long discussion in BBF about this point and both models appeared to
be valid.

>
> If link-local is enough, then there is no reason to do RS/RA over the WAN
> link at all: stateless DHCPv6 to do PD is enough.
>
> How can the BNG/BNAS know what will happen?   Is it reasonable to assume
> that the
> if the device does a RS that it expects the ISP to number the WAN link
> with a
> global address?
>

> The documents all seem to suggest that the ISP is going to make a
> provisioning decision a-priori about this.  And this seems to imply that
> all customers will have to be provisioned.... while IPv6 space is very
> large,
> bigger allocations cost ISPs more money, and so this still seems silly.
>
[RM] Why do you think it is silly? The ISPs have to make a-priori decision
about the provisioning model in order to provision the customers with the
right service profile.
This is not different with what it happens today for IPv4: let's say you
are a customer that subscribes both Internet and IPTV service, while I'm a
customer that only subscribes the internet service: my "user profile" on
RADIUS server will be different from yours.


> While the customer can be provisioned, the end user may well swap CPEs in
> and
> out, and may connect desktop computers directly to the DSL connection at
> times, so making the ISP and the end user agree here seems like a way to
> guarantee truck rolls)
>
> RFC6204 does not (as far as I can see) suggest that (un)numbering the WAN
> link is something the CPE can/should do.  RFC6204 says:
>      W-3:  Absent other routing information, the IPv6 CE router MUST use
>            Router Discovery as specified in [RFC4861] to discover a
>
> yet, RFC4241 omits a RS/RA phase in section 2.2, which specifically goes
>         from IPV6CP (link-address negotiation) to prefix delegation
>
>   2.2. IP Layer
>     After IPV6CP negotiation, the CPE initiates a prefix delegation
>     request.
>
> The diagram in RFC4241, figure 2 also clearly leaves out RS/RA.
> (I remind that 4241 is Informational, not standards track)
>
> If it does PD, then the CPE device can clearly use an address from the
> delegated prefix to originate traffic to the Internet. 4241 suggests
> assigning the "0" subnet network to the router's loopback.
>
> (I note that this could make the CPE's firewall more complex, as one can
>  assume that all PD/56 traffic is to be protected equally.)
>
> Further, if the WAN link is numbered as a /64 from within the prefix that
> (will be) delegated, that also would seem to make the CPE's firewall even
> more complex, so I'd rather number it outside the PD if it needs to be
> numbered at all.
>
[RM] I'm not familiar with security, I cannot comment on firewall, but I
can add some more details on the prefix to be used for the WAN link.
Actually using a /64 taken from the prefix delegated via DHCP-PD to number
the WAN link at the time we wrote the first version of TR-187 was not
allowed by RFC3633 because the WAN is the link from where the prefix was
received.
More recently RFC 6603 about Prefix exclude was published so today you
could theoretically do that if you use prefix exclude option, but I'm not
sure how much this model has been adopted. It is referenced in
 draft-ietf-v6ops-6204bis WPD-8.

>
> Meanwhile, TR-187 says that Route Advertisements are generated by the BNG.
> (section 5.2
>
> and says:
>     Whenever the Framed-IPv6-Prefix attribute is returned from RADIUS, the
>     BNG includes this prefix as On-Link and Autonomous in the Router
>     Advertisement Prefix Information Option. If this attribute is omitted,
>     the BNG will not send a Prefix Information Option. DHCPv6 is used to
> delegate prefixes.
>
> so this is exactly inline with what I had concluded: number the link if
> provisioned to do so, leave it unnumbered otherwise.
>
> Has this worked well in the field?
>
> section 5.3.1 suggests that the delegated prefix be returned during the
> initial communication with the radius server.  This is great for
> pre-provisioned systems, but seems to premeditate the size of prefixes that
> customers will get, regardless of what they put into their DHCPv6 PD
> request.
>
[RM] back to my previous comment: provision the customer/service profile in
the RADIUS server is a common practice in Service Provider's environment.


> It also implies that every customer, even those not yet IPv6 ready, are
> going
> to get IPv6 prefixes delegated to them, as the various IPv6 radius
> attributes
> are returned during PPP LCP phase, and before one has any idea that the
> customer
> is v6 capable.  It also prevents the CPE from turning on IPv6 later on
> without cycling the PPP connection.
>
> I think it would be better to omit that on the first connection, and permit
> the allocation to be driven by the actual DHCPv6.  RFC6911 outlines the
> attributes to be used, but it isn't clear to me that they have to be done
> at
> PPP LCP time.
>
> It seems that TR-187, in requirement R-22, (section 9), is suggesting that
> /128 addresses be given out via stateful DHCPv6.  But R-29 says /64 for
> SLAAC.
>
[RM] TR-187 allows for both options either DHCPv6 or SLAAC can be used to
number the WAN link: there are Service Providers that would like to use
DHCPv6 other that prefer SLAAC.

Infect R-22 says "[....]   when using DHCPv6 for address assignment" and
R-29 says " When SLAAC is used to number the WAN link".

You use either R-22 (if you do DHCPv6) or R-29 (if you do SLAAC) or none
for unnumbered.

Thanks

Roberta



>
>
> Roberta Maglione <[e-mail]> wrote:
>     > Basically all the parameters required to configure the RG can be sent
>     > by the RADIUS Server to the BNG (RADIUS client) in the Access-Accept
>     > during the authentication phase and then the BNG (acting as DHCPv6
>     > Server) can use them to number the Wan link and delegate an IPv6
> prefix
>     > to the home network.
>
> Yes,  the delegated prefix could be in the initial Access-Accept, and this
> is
> easy to do if the prefixes are all statically provisioned.  There are
> radius
> servers that can do dynamic allocation, but the bigger issue I'm concerned
> about is that the allocation may not be able to reflect what the CPE will
> actually ask for.
>
>     > Please take a look at TR-187 issue2 from BBF
>
>     > http://www.broadband-forum.org/technical/download/TR-187_Issue-2.pdf
>
> Thank you this document is useful.  I'd like to ask that some homenet
> document cite it.
>
>     mcr>  and RFC 4241 for  more details on the architectural model.
>
>     mcr>     Or, if the radius server had returned some kind of session ID
> to
>     mcr> the ppp, it could communicate that to a co-located DHCPv6 server
> (or
>     mcr> relay) to include in the request.
>
> I have been reminded of the radius State attribute which is commonly used.
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        | network
> architect  [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails
>    [
>
>
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>
>
>