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

Athanasios Douitsis <aduitsis@gmail.com> Tue, 19 November 2013 19:27 UTC

Return-Path: <aduitsis@gmail.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33EC31AE1DA; Tue, 19 Nov 2013 11:27:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.515
X-Spam-Level:
X-Spam-Status: No, score=-0.515 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FRT_ADULT2=1.474, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FRT_ADULT2=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OL64IY-Cixmu; Tue, 19 Nov 2013 11:27:41 -0800 (PST)
Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE281AE1A5; Tue, 19 Nov 2013 11:27:41 -0800 (PST)
Received: by mail-ie0-f174.google.com with SMTP id at1so5919508iec.19 for <multiple recipients>; Tue, 19 Nov 2013 11:27:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=890ghZuacTh8h77g8jxjjhd5mxs/2Qk0rKCB6+T5fHY=; b=hKNkQBqN/Pl2UtV7IwpPcinK6t7qcL6PsoZagQxvrFpRps9NRGToMRCINX2GjHTZEe Ytwn3iSlvI5j94iuNAFT4+zMHbxJZGgKiVyb8rZBnDSoOCGMMIDAgGCUlezcz++4tJAb 4CQc8UI+/MgkYNTAQSWOwQv9vLNucRenkN9V3pXCuS03kNtft0u+RDnx7/kCqv3tGdrn yhz2EgXHCTz5uthgo+6ShqvO9w9HMpXvWy/bHt0IXlLwHgjsiET7cLVPmM9oil121Rr8 ZuNHj+y2WyhMC7Zgs1zg6DrzrFzQBJRDYm36Rmlj2N5S+dnLVYHfKDr+P9aMpIGGek7C RX2A==
MIME-Version: 1.0
X-Received: by 10.50.6.99 with SMTP id z3mr20318195igz.27.1384889255329; Tue, 19 Nov 2013 11:27:35 -0800 (PST)
Received: by 10.64.227.168 with HTTP; Tue, 19 Nov 2013 11:27:35 -0800 (PST)
In-Reply-To: <57C3345230A4F94C9B2F5CFA05D7F2BD1D4EDB99@xmb-rcd-x01.cisco.com>
References: <11836.1384276281@sandelman.ca> <CAKOT5Ko2OO=U_0jADb6R88JiFh59BLDSe4P0haqgaBr2M7HobA@mail.gmail.com> <3673.1384528283@sandelman.ca> <CAKOT5Kpp0dCqbZyFzwtjTh9UJ5hGHUMN0ZGQHUL35+mkO9VRrA@mail.gmail.com> <CABT9mj-rw5bsVa7UAiraxu-U2t1QGqPronYj3Fx6ZxoPWo0Zow@mail.gmail.com> <CABT9mj-sQbfiNyfUZDxVmCg7SYWaJXcp+pNbyUSj64iFSA5fuA@mail.gmail.com> <70913413-2B68-4703-84E3-F7CC47E1A0E2@cisco.com> <CABT9mj9Jg-5pM4JKKOOgqszarFj6eDHji_rHZkTw3Eknddaqdw@mail.gmail.com> <489D13FBFA9B3E41812EA89F188F018E1AD9CDF7@xmb-rcd-x04.cisco.com> <B10FDF95-9612-4DD7-8C3E-9361CCBCA4E3@gmail.com> <CABT9mj-p3tjamspMo-F5vJRSCAWEVkvBEogFjAFrr4jL3p9vpw@mail.gmail.com> <489D13FBFA9B3E41812EA89F188F018E1AD9D36C@xmb-rcd-x04.cisco.com> <CABT9mj8Gt==+m-JL2foTvZnU49EhSODN0595cb-P1jn9YQgE6Q@mail.gmail.com> <57C3345230A4F94C9B2F5CFA05D7F2BD1D4ED850@xmb-rcd-x01.cisco.com> <659AA1B8-BA47-420F-A452-24DB776B3061@gmail.com> <57C3345230A4F94C9B2F5CFA05D7F2BD1D4EDB99@xmb-rcd-x01.cisco.com>
Date: Tue, 19 Nov 2013 21:27:35 +0200
Message-ID: <CABT9mj-eZ2Xz24YXT7dBvY9jLwyZyuCCFzNoD4YqG7Vz37YuSw@mail.gmail.com>
From: Athanasios Douitsis <aduitsis@gmail.com>
To: "Roberta Maglione (robmgl)" <robmgl@cisco.com>
Content-Type: multipart/alternative; boundary="e89a8f3b9c231e7efa04eb8ca8a0"
Cc: "radext@ietf.org" <radext@ietf.org>, "Bernie Volz (volz)" <volz@cisco.com>, Michael Richardson <mcr+ietf@sandelman.ca>, Jouni Korhonen <jouni.nospam@gmail.com>, "dhcwg@ietf.org WG" <dhcwg@ietf.org>, "homenet@ietf.org" <homenet@ietf.org>
Subject: Re: [radext] [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Nov 2013 19:27:44 -0000

Hello,

Thanks for the comments!

Indeed in a scenario where all the requesting routers connecting to a
delegating router (BNG) would have PD_EXCLUDE capability, using the
Framed-IPv6-Prefix to infer what to put into the OPTION_PD_EXCLUDE field is
sufficient.

But if there is a mix of PD_EXCLUDE-capable and not capable requesting
clients, the situation becomes more complex. The fundamental problem is
that Prefix Delegation usually happens after the RADIUS exchange, so the
RADIUS server cannot really know whether the customer is exclude-capable or
not.

If, for example, the client is not exclude-capable, then having the RADIUS
return a Framed-IPv6-Prefix that is part of the (greater)
Delegated-IPv6-Prefix is problematic for obvious reasons. In fact, I, for
one, cannot wrap my head around a way to cover both cases (exclude-capable
and non-exclude-capable) using only the two existing RADIUS attributes
*and* at the same time maintain backwards compatibility with old
customers.

As suggested, one approach would be to define a new RADIUS attribute (say
IPv6-Excluded-Prefix) which would be used to enumerate the WAN (and be put
in the OPTION_PD_EXCLUDE of course) in case of an exclude-capable customer.
But this gets rather messy, in the sense that iff the customer is
exclude-capable and the IPv6-Excluded-Prefix is returned, then the
IPv6-Excluded-Prefix is used to enumerate the WAN, otherwise the normal
avenue (Framed-IPv6-Prefix or Framed-IPv6-Pool or Framed-IPv6-Address, etc)
is followed and the IPv6-Excluded-Prefix is ignored. And, admittedly,
having to always provide a Framed-IPv6-Prefix foreign to the
Delegated-IPv6-Prefix kind of defeats the whole purpose of RFC6603 in some
ways.

Any comments on that? How do you believe the case of mixed clients should
be handled without breaking existing conventions?

Kind regards,
Athanasios Douitsis






On Tue, Nov 19, 2013 at 7:47 PM, Roberta Maglione (robmgl) <robmgl@cisco.com
> wrote:

> >That would be a trivial check in the RADIUS client, right? If the
> Framed-IPv6-Prefix falls into the Delegated-IPv6->Prefix, then you do the
> exclude, otherwise not.
>
> Ok, you are right this is a way to do it.
>
> Thanks
> Roberta
>
> -----Original Message-----
> From: radext [mailto:radext-bounces@ietf.org] On Behalf Of Jouni Korhonen
> Sent: Tuesday, November 19, 2013 12:43 PM
> To: Roberta Maglione (robmgl)
> Cc: radext@ietf.org; Athanasios Douitsis; Bernie Volz (volz); Michael
> Richardson; dhcwg@ietf.org WG; homenet@ietf.org
> Subject: Re: [radext] [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation
>
>
> On Nov 19, 2013, at 7:10 PM, "Roberta Maglione (robmgl)" <robmgl@cisco.com>
> wrote:
>
> > Hello,
> > I see your point. In my opinion if you would like to have all the
> prefixes assigned by RADIUS server in order to be able to cover the
> scenario you described in a clean way you would need a new RADIUS attribute
> for PD_EXCLUDE.
>
> I am not sure I agree entirely.
>
>
> > The reason why I think a new radius would be required is because you
> need to differentiate between the scenario where Framed-IPv6-Prefix is used
> to number the Wan link with a separate prefix (not included in the PD -
> without the PD_EXCLUDE) and the scenario you described where the prefix for
> the WAN link is part of the PD and you need to copy it into the PD exclude
> option.
>
> That would be a trivial check in the RADIUS client, right? If the
> Framed-IPv6-Prefix falls into the Delegated-IPv6-Prefix, then you do the
> exclude, otherwise not.
>
>
> > Today the BNG (that in this case is acting both as RADIUS Client and
> Delegating Router) has no mean to know if the  Framed-IPv6-Prefix should be
> used for the  PD_EXCLUDE or not and in my opinion it would be better not
> overload the sematic of the Framed-IPv6-Prefix.
> > Any comment?
>
> I would do the check rather than define a new attribute.
>
> - Jouni
>
>
> > Thanks
> > Roberta
> >
> > From: Athanasios Douitsis [mailto:aduitsis@gmail.com]
> > Sent: Tuesday, November 19, 2013 11:50 AM
> > To: Bernie Volz (volz)
> > Cc: Jouni Korhonen; radext@ietf.org; homenet@ietf.org; Roberta Maglione
> (robmgl); dhcwg@ietf.org WG; Michael Richardson
> > Subject: Re: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation
> >
> >
> > On Tue, Nov 19, 2013 at 6:42 PM, Bernie Volz (volz) <volz@cisco.com>
> wrote:
> > This must be done by the delegation router (if you are talking about the
> DHCPv6 packet itself) - as it is the one that constructs the Advertise and
> Reply messages to the client.
> >
> > Pardon me, I meant to wonder who should make the assignment, not who
> should construct the packets.
> >
> > When you are using the Delegated-IPv6-Prefix AV pair, the delegating
> router obviously constructs the packets with the delegated prefix value,
> but the actual assignment has been done by the RADIUS server. By the same
> token, I wondered whether it makes sense to do the same for the
> OPTION_PD_EXCLUDE value.
> >
> > Kind regards,
> > --
> > Athanasios Douitsis
> >
> >
>
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext
>



-- 
Athanasios Douitsis