Re: [dhcwg] PPP, DHCPv6 and Prefix Delegation

[Michael Richardson <[e-mail]>]

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

The issue is whether the Broadband forum does not have the same trade-agreement
status that the IETF has an SDO.  This matters to many utilities that are
constrained by trade agreements to procure on via "performance
specifications".

The other issue is whether everyone knows to look towards the Broadband forum
to find the document.  I am very glad to find it :-)

    > 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> [RM] Why do you think it is silly? The ISPs have to make a-priori decision
    rm> about the provisioning model in order to provision the customers with the right
    rm> service profile.
    rm> This is not different with what it happens today for IPv4: let's say you are a
    rm> customer that subscribes both Internet and IPTV service, while I'm a customer
    rm> that only subscribes the internet service: my "user profile" on RADIUS server
    rm> will be different from yours.

The ISP is forced to provision IPv6 to *all* customers in an area, regardless
of what the customer actually asks for, or whether they are ready to do
IPv6.

In IPv4 speak, this is like provisioning IPv4 space (and a /29 at that) to
every person in your service area, on the chance that they might use it.

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

Thanks also for this.
TR187 does not mention 6603...

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