Re: [dhcwg] PPP, DHCPv6 and Prefix Delegation

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 15 November 2013 19:54 UTC

Return-Path: <mcr@sandelman.ca>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46FDB11E8136; Fri, 15 Nov 2013 11:54:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.394
X-Spam-Level:
X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=0.205, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlsaAPchC7zZ; Fri, 15 Nov 2013 11:54:45 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 3841511E820F; Fri, 15 Nov 2013 11:54:44 -0800 (PST)
Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7493120087; Fri, 15 Nov 2013 16:06:55 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id 61E6863B88; Fri, 15 Nov 2013 14:54:41 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4F9DE63AEF; Fri, 15 Nov 2013 14:54:41 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Roberta Maglione <robmgl.ietf@gmail.com>
In-Reply-To: <CAKOT5Kpp0dCqbZyFzwtjTh9UJ5hGHUMN0ZGQHUL35+mkO9VRrA@mail.gmail.com>
References: <11836.1384276281@sandelman.ca> <CAKOT5Ko2OO=U_0jADb6R88JiFh59BLDSe4P0haqgaBr2M7HobA@mail.gmail.com> <3673.1384528283@sandelman.ca> <CAKOT5Kpp0dCqbZyFzwtjTh9UJ5hGHUMN0ZGQHUL35+mkO9VRrA@mail.gmail.com>
X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
Date: Fri, 15 Nov 2013 14:54:41 -0500
Message-ID: <319.1384545281@sandelman.ca>
Sender: mcr@sandelman.ca
Cc: "dhcwg@ietf.org WG" <dhcwg@ietf.org>, homenet@ietf.org, robmgl@cisco.com, radext@ietf.org
Subject: Re: [dhcwg] PPP, DHCPv6 and Prefix Delegation
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 15 Nov 2013 19:54:49 -0000

Roberta Maglione <robmgl.ietf@gmail.com> 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  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works