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

[Wuyts Carl <[e-mail]>]

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.

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.

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