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

[Roberta Maglione <[e-mail]>]

Please see comments inline [RM]
Thanks
Roberta

On Fri, Nov 15, 2013 at 10:28 AM, Wuyts Carl <[e-mail]>wrote:

> All, some feedback from a CPE-vendor, feel free to ignore of course.
>
> 1. Wan links don't NEED global IP address.  This will depend on different
> factors and used protocols.  E.g. a PPP does not need a global IP for sure,
> however, what if you want to run remote management on it through IPv6 ?
>  It's very unlikely to be on the same link, hence link-local might not be
> sufficient.
>
[RM] agree. Remote management was one of the use cases brought up at the
BBF in order to support the numbered model. Somebody argued saying that you
could leave the WAN unnumbered and use the loopback with a prefix taking by
the delegated prefix, but some operators prefer to have a separate single
IPv6 prefix for managing all the RG's.


>
> 2. if the CPE sends an RS, the BNG doesn't have to translate this as
> "please number my link", strange assumption I'd say.
>
> 3. the statement   "After IPV6CP negotiation, the CPE initiates a prefix
> delegation request."  makes sense that DHCPv6 is indeed the local next step
> after PPP IPv6 is "up", however, potentially, manual config is possible, so
> to have this "automatically' in place might be the wrong conclusion
>
> 4. the statement " 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."  Agree that firewall config might be
> more difficult, but don't forget that it saves address space +, more
> important, injects less administration for the ISP to keep track of
> prefixes.
>
[RM] As I mentioned in my other email if you want to use an IPv6 prefix
from the delegate prefix you would need to use prefix exclude option RFC
6603. I agree with you that you would save address space but this model may
not be optimal for the operators that would like to have the management
interface of all the RG's in the same IPv6 prefix in order to
reduce/simplify the number of ACL's that they would need to add in the
network to restrict the access to the management systems.

Thanks
Roberta


> Regs
> Carl
>
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Michael Richardson
> Sent: vrijdag 15 november 2013 16:11
> To: Roberta Maglione
> Cc: [e-mail] WG; [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation
>
>
> 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?  (Will TR-187 get re-issued with the reference to
> access-16 changed to RFC6911?)
>
> ===
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
>
> 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
>
>
>