Re: [dhcwg] PPP, DHCPv6 and Prefix Delegation

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 15 November 2013 15:11 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 7EA1411E80F5; Fri, 15 Nov 2013 07:11:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6]
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 TsyxzONs9VrF; Fri, 15 Nov 2013 07:11:35 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id D230511E8147; Fri, 15 Nov 2013 07:11:27 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5727B20046; Fri, 15 Nov 2013 11:23:38 -0500 (EST)
Received: by sandelman.ca (Postfix, from userid 179) id C872763B88; Fri, 15 Nov 2013 10:11:23 -0500 (EST)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B7B1C63AEF; Fri, 15 Nov 2013 10:11:23 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Roberta Maglione <robmgl.ietf@gmail.com>
In-Reply-To: <CAKOT5Ko2OO=U_0jADb6R88JiFh59BLDSe4P0haqgaBr2M7HobA@mail.gmail.com>
References: <11836.1384276281@sandelman.ca> <CAKOT5Ko2OO=U_0jADb6R88JiFh59BLDSe4P0haqgaBr2M7HobA@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 10:11:23 -0500
Message-ID: <3673.1384528283@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 15:11:42 -0000

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


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