From trac+radext@trac.tools.ietf.org Fri Nov 1 16:00:58 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD64511E80E9 for ; Fri, 1 Nov 2013 16:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.12 X-Spam-Level: X-Spam-Status: No, score=-102.12 tagged_above=-999 required=5 tests=[AWL=0.479, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 fOMBHiIl0gUV for ; Fri, 1 Nov 2013 16:00:58 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 5160511E814C for ; Fri, 1 Nov 2013 16:00:50 -0700 (PDT) Received: from localhost ([127.0.0.1]:54173 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VcNhj-0001RO-M8; Sat, 02 Nov 2013 00:00:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-ieee802ext@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Fri, 01 Nov 2013 23:00:35 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/radext/trac/ticket/170#comment:2 Message-ID: <081.6d562311729abb4a4c5229c704e67a7b@trac.tools.ietf.org> References: <066.8c6dadfe7b14348ea276155a3c7ba51e@trac.tools.ietf.org> X-Trac-Ticket-ID: 170 In-Reply-To: <066.8c6dadfe7b14348ea276155a3c7ba51e@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-ieee802ext@tools.ietf.org, bernard_aboba@hotmail.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bernard_aboba@hotmail.com, j@w1.fi, jsalowey@cisco.com, mark@azu.ca, paul_congdon@hp.com Resent-Message-Id: <20131101230050.5160511E814C@ietfa.amsl.com> Resent-Date: Fri, 1 Nov 2013 16:00:50 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [radext] #170: Allowed-Called-Station-Id usage scenarios X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 23:00:59 -0000 #170: Allowed-Called-Station-Id usage scenarios Changes (by bernard_aboba@hotmail.com): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- bernard_aboba@hotmail.com | ieee802ext@tools.ietf.org Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: ieee802ext | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Fri Nov 1 16:01:25 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C19FC11E8110 for ; Fri, 1 Nov 2013 16:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.157 X-Spam-Level: X-Spam-Status: No, score=-102.157 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 m1LxJrqpGOoi for ; Fri, 1 Nov 2013 16:01:25 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 0B18D11E817E for ; Fri, 1 Nov 2013 16:01:02 -0700 (PDT) Received: from localhost ([127.0.0.1]:54205 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VcNi3-0001be-LD; Sat, 02 Nov 2013 00:00:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-ieee802ext@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Fri, 01 Nov 2013 23:00:55 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/171#comment:1 Message-ID: <081.15afe91164175a3fd9716e0acc038504@trac.tools.ietf.org> References: <066.c317995d834641dbb305f75b27c8f880@trac.tools.ietf.org> X-Trac-Ticket-ID: 171 In-Reply-To: <066.c317995d834641dbb305f75b27c8f880@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-ieee802ext@tools.ietf.org, bernard_aboba@hotmail.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bernard_aboba@hotmail.com, j@w1.fi, jsalowey@cisco.com, mark@azu.ca, paul_congdon@hp.com Resent-Message-Id: <20131101230102.0B18D11E817E@ietfa.amsl.com> Resent-Date: Fri, 1 Nov 2013 16:01:02 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [radext] #171: Updates: 3580 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 23:01:25 -0000 #171: Updates: 3580 Changes (by bernard_aboba@hotmail.com): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- bernard_aboba@hotmail.com | ieee802ext@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: ieee802ext | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From mauricio.sanchez@hp.com Mon Nov 4 10:42:23 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA79D11E81BC for ; Mon, 4 Nov 2013 10:42:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.251 X-Spam-Level: X-Spam-Status: No, score=-107.251 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_NAIL=2.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 SmOQLTL81hY4 for ; Mon, 4 Nov 2013 10:42:17 -0800 (PST) Received: from g5t0007.atlanta.hp.com (g5t0007.atlanta.hp.com [15.192.0.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5535511E815F for ; Mon, 4 Nov 2013 10:42:17 -0800 (PST) Received: from G6W4001.americas.hpqcorp.net (g6w4001.atlanta.hp.com [16.205.80.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g5t0007.atlanta.hp.com (Postfix) with ESMTPS id E47A614003 for ; Mon, 4 Nov 2013 18:42:16 +0000 (UTC) Received: from G6W3999.americas.hpqcorp.net (16.205.80.214) by G6W4001.americas.hpqcorp.net (16.205.80.210) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 4 Nov 2013 18:41:18 +0000 Received: from G6W2505.americas.hpqcorp.net ([169.254.12.30]) by G6W3999.americas.hpqcorp.net ([16.205.80.214]) with mapi id 14.03.0123.003; Mon, 4 Nov 2013 18:41:18 +0000 From: "Sanchez, Mauricio" To: "radext@ietf.org" Thread-Topic: IETF 88: Final Agenda Thread-Index: AQHO2Y1zk4KzTdYszUW7dUce7RiIUw== Date: Mon, 4 Nov 2013 18:41:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [15.193.49.30] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3466406475_16629820" MIME-Version: 1.0 Subject: [radext] IETF 88: Final Agenda X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 18:42:23 -0000 --B_3466406475_16629820 Content-type: multipart/alternative; boundary="B_3466406475_16604568" --B_3466406475_16604568 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit At IETF 88 RADEXT has 90 minutes allocated (Monday 11/4 1:00PM-2:30PM). Below is the final agenda consisting of items the chairs would believe would be useful to discuss. We can bash agenda, if need be, when we meet at 1pm this afternoon. -Jouni & Mauricio ----------------------- RADEXT WG IETF 88 Agenda Chairs: Jouni Korhonen Mauricio Sanchez Jabber room: radext at jabber.ietf.org (Please join) Monday, Nov 4, 2013 1:00 - 2:30PM Plaza A 1:00 - 1:10 PM, Preliminaries (10 minutes) ------------------------------------------ Audio/Video & Remote Presentation Debugging Note Well Note Takers Jabber scribe Agenda bash Document Status Working group draft discussion (45 minutes) ------------------------------------------- 1:10 - 1:20PM DTLS as a Transport Layer for RADIUS, Alan DeKok (10 minutes) http://tools.ietf.org/id/draft-ietf-radext-dtls 1:20 - 1:25PM The Network Access Identifier, Alan DeKok (5 minutes) http://tools.ietf.org/html/draft-ietf-radext-nai 1:25 - 1:30PM RADIUS dynamic discovery, Stefan Winter (5 minutes) http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery 1:30 - 1:40PM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-ieee802ext 1:40 - 1:55PM Support of fragmentation of RADIUS packets, Diego Lopez (15 minutes) http://tools.ietf.org/html/draft-ietf-radext-radius-fragmentation Chartered individual draft discussion (15 minutes) -------------------------------------------------- 1:55 - 2:10PM Larger Packets for Remote RADIUS over TCP, Sam Hartman (15 minutes) http://tools.ietf.org/html/draft-hartman-radext-bigger-packets Wrap-up (10 minutes) -------------------- 2:10 - 2:20 PM Next Steps: WG Chairs & ADs (5 minutes) WG Goals/Milestones status, next steps --B_3466406475_16604568 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable 
At IETF 88 RADEXT has 90 minutes allocated (Monday =
11/4 1:00PM-2:30PM). Below is the final agenda consisting of items the chair=
s would believe would be useful to discuss.  We can bash agenda, if nee=
d be, when we meet at 1pm this afternoon. 

-Jouni & =
Mauricio
-----------------------

RADEXT WG IETF 88 Agenda  

Chairs:
Jouni Korhonen <jouni.korhonen at broadcom.com>
Mauricio Sanchez <mauricio.sanchez at hp.com>

Jabber room: radext at jabber.ietf.org (Please join)
Monday, Nov 4, 2013
1:00 - 2:30PM
Plaza A

1:00 - 1:10 PM, Preliminaries (10 minutes)
------------------------------------------
Audio/Video & Remote Presentation Debugging
Note Well
Note Takers
Jabber scribe
Agenda bash
Document Status

Working group draft discussion (45 minutes)
-------------------------------------------
1:10 - 1:20PM DTLS as a Transport Layer for RADIUS, Alan DeKok (10 minutes)=

http://tools.ietf.org/id/draft-ietf-radext-dtls

1:20 - 1:25PM The Network Access Identifier, Alan DeKok (5 minutes)
http://tools.ietf.org/html/draft-ietf-radext-nai

1:25 - 1:30PM RADIUS dynamic discovery, Stefan Winter (5 minutes)
http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery

1:30 - 1:40PM RADIUS Attributes for IEEE 802 Networks, Bernard Aboba (10 mi=
nutes)
http://tools.ietf.org/html/draft-ietf-radext-ieee802ext

1:40 - 1:55PM Support of fragmentation of RADIUS packets, Diego Lopez (15 m=
inutes)
http://tools.ietf.org/html/draft-ietf-radext-radius-fragmentation

Chartered individual draft discussion (15 minutes)
--------------------------------------------------
1:55 - 2:10PM Larger Packets for Remote RADIUS over TCP, Sam  Hartman (15 m=
inutes)
http://tools.ietf.org/html/draft-hartman-radext-bigger-packets

Wrap-up (10 minutes)
--------------------
2:10 - 2:20 PM Next Steps: WG Chairs & ADs (5 minutes) 
WG Goals/Milestones status, next steps
--B_3466406475_16604568-- --B_3466406475_16629820 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVXwYJKoZIhvcNAQcCoIIVUDCCFUwCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJ/MIIH+TCCBuGgAwIBAgIQW4k5wUL7YloEpOVNCxcNjjANBgkqhkiG9w0BAQUFADCB 9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55MR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMsQ2xhc3MgMiBN YW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAvBgNVBAMTKENvbGxhYm9y YXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzIwHhcNMTIwOTI2MDAwMDAwWhcNMTQw OTI2MjM1OTU5WjCBnjEgMB4GA1UEChQXSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkxJjAkBgNV BAsUHUVtcGxveW1lbnQgU3RhdHVzIC0gRW1wbG95ZWVzMQ8wDQYDVQQLEwZTL01JTUUxGTAX BgNVBAMTEE1hdXJpY2lvIFNhbmNoZXoxJjAkBgkqhkiG9w0BCQEWF21hdXJpY2lvLnNhbmNo ZXpAaHAuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAloXM4DJlquSNxT+X mgHkZBI15A2U8R9K0nRaXPMi7fxOzKJBFyLo3FIYQqhrbSaFFliRgRqx9AFqICnM063baYtG DT7ySQ2u9Ewm54kNxAJBR/+EJVoR+/MEq5u/N9FDd3wB5PnFUdfnJ56jsZNhAhUcILwoWxcv fp3hCI7r92O/y2Qmz0PrVf5d+0y0OiJqH7/Pf/uy8D0IivgEUnyKC+VO9MwUwXWzxA1rF1+z +czuQnuWO8nKUHl3EySJL97mM9fm8MCYQrTIBKKf0XpIpzQ+5QQorSHdJKoWVcMMWLtaJY9J A5DWMjKJA0cjD6cSEV8iwN+V58lnKXFGcRyETwIDAQABo4ID1jCCA9IwOwYDVR0RBDQwMoEX bWF1cmljaW8uc2FuY2hlekBocC5jb22BF21hdXJpY2lvX3NhbmNoZXpAaHAuY29tMAwGA1Ud EwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMFkGA1UdHwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNp dGVjcmwudmVyaXNpZ24uY29tL0hld2xldHRQYWNrYXJkQ29tcGFueVNNSU1FRzIvTGF0ZXN0 Q1JMLmNybDAfBgNVHSMEGDAWgBQifdOkq1esVn+pf0FEGpW8W/ir7jAdBgNVHQ4EFgQUYP/x peEEwA0JEKvMwMyDDurpqCowggEyBggrBgEFBQcBAQSCASQwggEgMCcGCCsGAQUFBzABhhto dHRwOi8vaHAtb2NzcC52ZXJpc2lnbi5jb20wgfQGCCsGAQUFBzACpIHnMIHkMTEwLwYDVQQD EyhDb2xsYWJvcmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyMTAwLgYDVQQLEydD bGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExOjA4BgNVBAsTMVRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhKGMpMDkxHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21w YW55MIIBPQYDVR0gBIIBNDCCATAwggEsBgtghkgBhvhFAQcXAjCCARswKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwge4GCCsGAQUFBwICMIHhMB4WF0hld2xl dHQtUGFja2FyZCBDb21wYW55MAMCAQIagb5BdXRob3JpdHkgdG8gYmluZCBIUCBkb2VzIG5v dCBjb3JyZXNwb25kIHdpdGggdXNlIG9yIHBvc3Nlc3Npb24gb2YgdGhpcyBjZXJ0aWZpY2F0 ZS4gSXNzdWVkIHRvIGZhY2lsaXRhdGUgY29tbXVuaWNhdGlvbiB3aXRoIEhQLiBWZXJpU2ln bidzIENQUyBpbmNvcnAuIEJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWdu MBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMEMEsGCSqGSIb3DQEJDwQ+MDwwDgYIKoZIhvcNAwIC AgCAMA4GCCqGSIb3DQMCAgIAQDAOBggqhkiG9w0DBAICAIAwCgYIKoZIhvcNAwcwDQYJKoZI hvcNAQEFBQADggEBAHWuCgf6c4Dj8NT1yYJpcuw18irgCh6aSdvVPwUroQwgZYcsCG9OqsVf /2H6zrefDswtfKHDK6jhy2MmL+Ohhdkzl+i9vXJw1ZtnoiRQdhjQs2sAqwI8N/aQ56hogrU9 754lDYZzesp6OabKBj9+t+XVX/lBovsme59hUlwmgOuG4AVfLf0N2CftTwdD5kDCx2aAnlG0 FdYOC/Cdf/tk4c89GogQPwQpNNjw+M6cJX9OWhUGVQ2jI/PuJvlPlP+oyXzAtS3sEejaxBPI h5nQCwseT7DQm2rbCSa1dc0h8ScezllGSZHca/ySZbJcf8vSRbk3tBsPKHbqNZqzEqfERVQw ggZhMIIFSaADAgECAhA7VxO2sCE1+15GdcpsssThMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYD VQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy dXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1 dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFBy aW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0wOTA5MDIwMDAwMDBaFw0x OTA5MDEyMzU5NTlaMIH3MQswCQYDVQQGEwJVUzEgMB4GA1UEChMXSGV3bGV0dC1QYWNrYXJk IENvbXBhbnkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRl cm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MTUwMwYD VQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTExMC8G A1UEAxMoQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBHMjCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAKdha2jarqqFZAxLy1DLMOhzIY6J/sotb/5GowNu 4yK3coUTI+IPjwb3gUx67QO8Pe0cdVCjz+grzmgBOcVLaFvWo2GbTuZHYlBcs1h7G1IEoysv sjTuEKB3hM2kIvyVlDmHr/wFeWGCaBAyMrKLBBC0tfzOuIhNlLc6/i8YloXWqkkROI4oG5uA 8uGsi86gL+X+6CC6yTWekoai4hhgqT/u63pU8kYBV5hF/0ijf2t/ScGaCkjVHSJGMq+8JjSP fs8pYXgyYIbpPpGQwA9zV7+BBlTFHzoOVBHYQCdC8ONA+Kaimtno9R9FIqStRBHUU5veEc3x PM/Lwz/PnXIDqgsCAwEAAaOCAhIwggIOMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkw ZzBlBgtghkgBhvhFAQcXAjBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j b20vY3BzMCoGCCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi1nMy5jcmwwDgYD VR0PAQH/BAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIw NDgtMTQyMB0GA1UdDgQWBBQifdOkq1esVn+pf0FEGpW8W/ir7jCB8AYDVR0jBIHoMIHloYHQ pIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IQYXDLSYxf mEUp57Cm2VBbejANBgkqhkiG9w0BAQUFAAOCAQEAdoqZeNFwhaMs169I9T6WV8Ogu0yXxIYR BUkixQrPwW9OtXymgDUb8uKPHDhicfM8vgAlSh6hEMmWO017rCZoo57pWaN4xkebP44wlsqo 1ig5VcfN7cnrspDklTA+tP3v8afJxuE2bChgVCeet6BxOr2rvNB1ItdT87KcWxV1COpJqzQu U8N8BhR7oPEUiCRtXpFrfmTrYewl1xm1bZk3cAp9CKjDYClVJEwZIgD67DezmWQK+VBk+ofE VAv9CNB/TFwrUpV7inKrSbf7FqkIIbwzvIR1If11NWxDmtioyQsoFnO5/5wLQTSsO17YBYLo boLVLG3RgY7bX5288HU2WDCCBBkwggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEB BQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw05OTEw MDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8KDcLVLNtn uS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8QzicT ngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDL HMQjPR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23S rGY/lozghNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOC AQEANCYVPMCNTUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDz mN+k5qQx39McC0bcciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfO RF3UG5CYDR5ClLEALATQdKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6 uuNkSLB/+zYl2pXQ8SQUF90YgGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I5 4bFD4CjPt+dabBNrSbP/4xh8iYszXawz16f52jpVyVgQ+arvWrbPS0vfKjGCAqQwggKgAgEB MIIBDDCB9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAvBgNVBAMTKENv bGxhYm9yYXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzICEFuJOcFC+2JaBKTlTQsX DY4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgaDtox7Z6VFO8fRDMVyYThDqp oVsYKQaOP3poDUrIRIswGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTMxMTA0MTg0MTE1WjANBgkqhkiG9w0BAQEFAASCAQBUdXo+JIF6irIXB7X/pkx1psMt hjM6r3CWHfbTgickf1jU/oe7tl0m+lY1sjp/JPBTf/8cZ8ufM2Ui6NEAKGDgCPqZabp71kHq flvXiGf7q4ItuRCRrAqVdG97s/k4N1JxYvt48aJ6+bdYSfPyC/wWJClhirA9XzEcf+KiyWZU Z7+4YsFnityIwX+IyNGN795E9hpR/INozmHpNyvlN9LdGFRs85XRA0ROJaYDZWjt6EkZ9yqw 7XGegJ6W+OuTb3r1p+PtUAX8sMjYrURCdq2dMU7hcBAIeeuDNszTOKQx8XFqS2OD7mdaaloj U9ecPxw50RuaqxoJFZJHxpEn51Lt --B_3466406475_16629820-- From hartmans@painless-security.com Mon Nov 4 13:16:48 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C92ED21E8098 for ; Mon, 4 Nov 2013 13:16:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 kcfZcdRoVwhj for ; Mon, 4 Nov 2013 13:16:42 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 4479021F9EC8 for ; Mon, 4 Nov 2013 13:16:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 164012052B for ; Mon, 4 Nov 2013 16:14:08 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCJb7JroNmr0 for ; Mon, 4 Nov 2013 16:14:07 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (dhcp-9c4b.meeting.ietf.org [31.133.156.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS for ; Mon, 4 Nov 2013 16:14:07 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 98DDE87F99; Mon, 4 Nov 2013 16:16:31 -0500 (EST) From: Sam Hartman To: radext@ietf.org Cc: Date: Mon, 04 Nov 2013 16:16:31 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [radext] Recommending ipdir review for draft-ietf-radext-radius-fragmentation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 21:16:48 -0000 I think our group would be served by getting IP directorate review of the RADIUS fragmentation draft sooner rather than later. My reasoning is that they will end up reviewing it anyway because it involves fragmentation at multiple layers. They will probably have questions and it would be good to get those resolved now. I think the draft is far enough along to make that review helpful. I'm not sure how to request a review, but will look into it if people agree that's useful. From trac+radext@trac.tools.ietf.org Mon Nov 4 13:28:36 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4B121F9F80 for ; Mon, 4 Nov 2013 13:28:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.038 X-Spam-Level: X-Spam-Status: No, score=-101.038 tagged_above=-999 required=5 tests=[AWL=-0.739, BAYES_00=-2.599, MANGLED_NAIL=2.3, USER_IN_WHITELIST=-100] 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 CDflhntbuemq for ; Mon, 4 Nov 2013 13:28:36 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 5288D21F9F8E for ; Mon, 4 Nov 2013 13:28:32 -0800 (PST) Received: from localhost ([127.0.0.1]:44172 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VdRh8-00084e-Gt; Mon, 04 Nov 2013 22:28:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-nai@tools.ietf.org, aland@deployingradius.com X-Trac-Project: radext Date: Mon, 04 Nov 2013 21:28:22 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/172 Message-ID: <066.1dd2c72add09d45cd42a88636fe81ada@trac.tools.ietf.org> X-Trac-Ticket-ID: 172 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-nai@tools.ietf.org, aland@deployingradius.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: aland@freeradius.org Resent-Message-Id: <20131104212833.5288D21F9F8E@ietfa.amsl.com> Resent-Date: Mon, 4 Nov 2013 13:28:32 -0800 (PST) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: [radext] #172: i18n review for closure of NFC form X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 21:28:37 -0000 #172: i18n review for closure of NFC form Q: can the proxy normalize utf-8 to NFC? If so, under what circumstances? If not, what circumstances? The current assumption is: - if supplicant and proxy are same unicode version, YES, the proxy can always create NFC - if supplicant is NEWER unicode version than proxy, then MAYBE sometimes the proxy can create NFC. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- aland@deployingradius.com | nai@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: nai | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Mon Nov 4 17:49:14 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B63711E81D3 for ; Mon, 4 Nov 2013 17:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.989 X-Spam-Level: X-Spam-Status: No, score=-100.989 tagged_above=-999 required=5 tests=[AWL=-0.690, BAYES_00=-2.599, MANGLED_NAIL=2.3, USER_IN_WHITELIST=-100] 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 3TKwNHLahr8L for ; Mon, 4 Nov 2013 17:49:13 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 76D9411E81C6 for ; Mon, 4 Nov 2013 17:49:07 -0800 (PST) Received: from localhost ([127.0.0.1]:42661 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VdVlM-0002f1-7r; Tue, 05 Nov 2013 02:49:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-nai@tools.ietf.org, aland@deployingradius.com X-Trac-Project: radext Date: Tue, 05 Nov 2013 01:49:00 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/172#comment:1 Message-ID: <081.23255d82b62c617f9938e8656f158c56@trac.tools.ietf.org> References: <066.1dd2c72add09d45cd42a88636fe81ada@trac.tools.ietf.org> X-Trac-Ticket-ID: 172 In-Reply-To: <066.1dd2c72add09d45cd42a88636fe81ada@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-nai@tools.ietf.org, aland@deployingradius.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: aland@freeradius.org Resent-Message-Id: <20131105014907.76D9411E81C6@ietfa.amsl.com> Resent-Date: Mon, 4 Nov 2013 17:49:07 -0800 (PST) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [radext] #172: i18n review for closure of NFC form X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 01:49:14 -0000 #172: i18n review for closure of NFC form Comment (by aland@deployingradius.com): Sam and I talked with Pete Resnick this afternoon. The summary is this: - the end user machine (e.g. supplicant) SHOULD normalize the realm for the NAI. Only it has the information necessary to determine the users intent - intermediate proxies *may* be able to normalize the realm. The IDNA mappings document describes some of these normalizations. However, this normalization is not always possible. - if the realm cannot be normalized, there's nothing the proxy can do. It has an identifier which is an opaque blob, and which may not match any realm it knows about. - we should reference also the precis documents which talk about these issues. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- aland@deployingradius.com | nai@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: nai | Version: Severity: - | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From mauricio.sanchez@hp.com Tue Nov 5 08:46:18 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D4A11E82F5 for ; Tue, 5 Nov 2013 08:46:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.135 X-Spam-Level: X-Spam-Status: No, score=-107.135 tagged_above=-999 required=5 tests=[AWL=-0.233, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_DIET=2.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 K+BTutfmCrML for ; Tue, 5 Nov 2013 08:46:11 -0800 (PST) Received: from g6t0186.atlanta.hp.com (g6t0186.atlanta.hp.com [15.193.32.63]) by ietfa.amsl.com (Postfix) with ESMTP id 7222C11E8301 for ; Tue, 5 Nov 2013 08:44:45 -0800 (PST) Received: from G6W4001.americas.hpqcorp.net (g6w4001.atlanta.hp.com [16.205.80.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t0186.atlanta.hp.com (Postfix) with ESMTPS id 0A3872C00A for ; Tue, 5 Nov 2013 16:44:45 +0000 (UTC) Received: from G6W3999.americas.hpqcorp.net (16.205.80.214) by G6W4001.americas.hpqcorp.net (16.205.80.210) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 5 Nov 2013 16:43:53 +0000 Received: from G6W2505.americas.hpqcorp.net ([169.254.12.30]) by G6W3999.americas.hpqcorp.net ([16.205.80.214]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 16:43:53 +0000 From: "Sanchez, Mauricio" To: "radext@ietf.org" Thread-Topic: IETF 88: Preliminary Meeting Notes Thread-Index: AQHO2kY1a4GP1gEqh0atnRYI7GSkig== Date: Tue, 5 Nov 2013 16:43:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [15.193.49.14] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3466485826_18642607" MIME-Version: 1.0 Subject: [radext] IETF 88: Preliminary Meeting Notes X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 16:46:19 -0000 --B_3466485826_18642607 Content-type: multipart/alternative; boundary="B_3466485826_18643430" --B_3466485826_18643430 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Below are preliminary meeting notes for your review. Thanks go to Dorothy for note taking. =20 Please post to mailing list any corrections/feedback. Thanks, Jouni and Mauricio=20 -------------------------- RADEXT IETF 88 Vancouver, Canada Monday, November 5, 2013 Meeting started 1:01PM and adjourned 2:10PM Chairs: Jouni Korhonen Mauricio Sanchez AD: Benoit Claise 1.Preliminaries a. Blue sheet reminder b. Jabber scribe: Alan DeKok c. Minute taker: Dorothy Stanley d. Status: i. No RFCs Published, in editor queue. ii. IEEE 802 attributes =AD version -09 published 2013-10-20, one of 24 issue= s still open. iii. NAI-based peer discovery =AD version -08 published 2013-10-16, no open issues. iv. Network Access Identifier =AD version -04 published =AD still one issue, raised by Sam Hartman should be closed before the end of the week. v. Support of fragmentation of RADIUS packets =AD version -01 published, will be discussed today. vi. Larger Packets for RADIUS over TCP =AD Version -00 published 2013-10, to be discussed. vii. Have 2 documents that are outside the current charter: Data type in RADIUS and RADIUS extensions for key management in WLAN network. viii. Chair reviewed WG goals and milestones; way beyond deadlines; however= , have momentum on progressing documents. ***************************************************************************= * ***** 2. Alan DeKok =AD DTLS draft, see http://tools.ietf.org/id/draft-ietf-radext-dtls and http://www.ietf.org/proceedings/88/slides/slides-88-radext-2.ppt a. Secdir and opsdir reviews completed. b. No more open issues. c. Submit for publication? d. Comment: Transport director review still coming. e. Radsec proxy and Jradius work. 3. Alan DeKok =AD NAI based peer discovery, see http://tools.ietf.org/html/draft-ietf-radext-nai and http://www.ietf.org/proceedings/88/slides/slides-88-radext-4.ppt a. Main sticking point =AD normalization done at edge or core. b. Realm part is a DNS name; if register, then valid. c. RFC 4282 not implemented. d. Let DNS people handle internationalization. e. Have happy users at the edge. Get on the network; computer puts blob int= o EAP. UTF-8? Can RADIUS server determine the domain name from the UTF-8 blob= . This is the open issue. f. Given an end user machine and a proxy, if at same Unicode version =AD can normalization be done? g. Can=B9t upgrade a billion edge devices. h. Comment - even if not at same unicode version, will match for many values. i. Little feedback from il8n folks to date; goal to close on this by end of this week. j. Comment =AD what is the problem with RFC4282? k. Bans unassigned unicode code points. If proxy receives an unassigned cod= e point, then drop. Does not support upgrading proxies. l. http://tools.ietf.org/html/draft-ietf-radext-nai ***************************************************************************= * ***** 4. Bernard Aboba =AD IEEE 802 extensions draft, see http://tools.ietf.org/html/draft-ietf-radext-ieee802ext and http://www.ietf.org/proceedings/88/slides/slides-88-radext-3.ppt a. WGLC has concluded. b. One remaining issue =AD how to use RADIUS with wired extensions defined in IEEE 802.1X-2010 Review of TLV types, 0-127 possible TLVs. c. Proposal is to create an EAPoL-Announcement attribute which can be present in all RADIUS message and include the TLVs. d. Define how to deal with multiple announcements attributes in a packet. Allows TLVs longer than 253 octets to be transported by RADIUS. e. Proposal is in the draft. Confirm on the list, and with Joe Salowey that he is ok with the proposed solution. f. Question on the concatenation. Is there a spec that we can reference? g. http://tools.ietf.org/html/draft-ietf-radext-ieee802ext ***************************************************************************= * ***** 5. Diego Lopez =AD RADIUS Fragmentation, see http://tools.ietf.org/html/draft-ietf-radext-radius-fragmentation and http://www.ietf.org/proceedings/88/slides/slides-88-radext-6.pdf a. Reviewed status: accepted as a WG document 2013-08-26. Solution focused on transport of large amounts of auth info. b. Changes made to text to address issues. i. Added text clarifying that proxies are assumed to base their routing decisions on the value of the User-name attribute. ii. New text regarding how proxies implement RFC6929 =AD SHOULD forward packages even if invalid attributes are found. iii. Included an example for SAML =AD roundtrips required. c. Review of remaining issues i. Proxy-State-Length attribute ii. Detailed description of CoA handling. d. Chair: how many people have read the -01 version? Small number of hands. e. Alan: This is a hack to get data through existing systems; don=B9t depend on it. f. Sam: Believe the draft is ready for AD review and transport area review; recommend sending to those directorates for review sooner rather than later= . g. Get AD review when we do WGLC on -02. ***************************************************************************= * ***** 6. Stefan not available: defer.1:25 - 1:30PM RADIUS dynamic discovery, Stefan Winter (5 minutes) http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery ***************************************************************************= * ***** 7. Sam Hartman - Larger Packets for Remote RADIUS over TCP, see http://tools.ietf.org/html/draft-hartman-radext-bigger-packets and http://www.ietf.org/proceedings/88/slides/slides-88-radext-5.pdf a. Review of goals: carry packets with more than 4096 octets of attributes b. Applications carrying RADIUS over TLS; when security available, then can carry more info. c. Review of open issue: Capability negotiation requested. i. Unclear that this is needed. No way to tell if server supports large packets. ii. Really capability discovery. iii. But is capability discovery really needed. iv. Mitigated by experimental status of TCP transport, with no reasonable fallback. v. Problem with multiple outstanding requests. vi. Negotiation is strongly desired. d. Review of open issue: Error Response. i. Use error codes or access-reject ii. Need feedback. e. Question: Are there other circumstances when there are many packets in flight and one causes connection to be dropped? i. If send malformed packet, issue introduced. Only case known. f. Fix issues, post updated draft; raise any objections now. g. Question: Why doesn=B9t new infrastructure require larger packets? i. Interest in implementing for RADIUS. ii. Discussion on supporting RADIUS larger packets closed with approved re-charter. iii. Let market decide. Some implementers and applications not interested i= n moving to DIAMETER. 8. Wrap-up, next steps a. Plan to have further discussion re: guidance on RADIUS and DIAMETER. b. Benoit Claise: Call for action i. There has been a request for a AAA tutorial to capture institutional knowledge. ii. Please direct your interest in guidance on RADIUS and DIAMETER to the AAA tutorial. c. Alan DeKok =AD CoA and proxy d. Alan DeKok - Data Types draft e. Re-charter (or not) f. How many people have read Sam=B9s draft? About 4. Revision to be published soon, get more eyes on the revision. ***************************************************************************= * ***** 9. Meeting adjourned 1410. --B_3466485826_18643430 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Below are preliminary meeting= notes for your review.   Thanks go to Dorothy for note taking.  <= /div>

Please post to mailing list any corrections/feedbac= k.  

Thanks,
Jouni and Mauricio = ;

--------------------------
RADEXT
=
IETF 88
Vancouver, Canada

Monday, No= vember 5, 2013
Meeting started 1:01PM and adjourned 2:10PM

Chairs:
Jouni Korhonen <jouni.korhonen at bro= adcom.com>
Mauricio Sanchez <mauricio.sanchez at hp.com><= /div>

AD:
Benoit Claise <bclaise at cisco.co= m> 

1.Preliminaries
a. Blue sheet reminder
<= div>b. Jabber sc= ribe: Alan DeKok
c. Minute taker: Dorothy Stanley
d. Status:
i. No RFCs Published, in editor q= ueue.
ii. IEEE 802 attributes – version -09 published 2013-10-20, one of 24 = issues still open.
iii. NAI-based peer discovery – version -08 published 201= 3-10-16, no open issues.
iv. Network Access Identifier – version -04 publish= ed – still one issue, raised by Sam Hartman should be closed before th= e end of the week.
v. Support of fragmentation of RADIUS packets – version -= 01 published, will be discussed today.
vi. Larger Packets for RADIUS over TCP R= 11; Version -00 published 2013-10, to be discussed.
vii. Have 2 documents that are= outside the current charter: Data type in RADIUS and RADIUS extensions for = key management in WLAN network.
viii. Chair reviewed WG goals and milestones; way = beyond deadlines; however, have momentum on progressing documents. 

******************************************************= ***************************
2. Alan DeKok – DTLS draft, see http://tools.iet= f.org/id/draft-ietf-radext-dtls and http://www.ietf.org/proceedings/88/slide= s/slides-88-radext-2.ppt 
a. Secdir and opsdir reviews completed.
b= . No more open i= ssues.
c. Submit for publication?
d. Comment: Transport director review still coming.
e. Radse= c proxy and Jradius work.
3. Alan DeKok – NAI based peer discovery, see http= ://tools.ietf.org/html/draft-ietf-radext-nai and http://www.ietf.org/proceed= ings/88/slides/slides-88-radext-4.ppt 
a. Main sticking point – normali= zation done at edge or core.
b. Realm part is a DNS name; if register, then valid.=
c. RF= C 4282 not implemented.
d. Let DNS people handle internationalization.
e= . Have happy use= rs at the edge. Get on the network; computer puts blob into EAP. UTF-8? Can = RADIUS server determine the domain name from the UTF-8 blob. This is the ope= n issue.
f. <= /span>Given an end user machine and a proxy, if at same Unicode version R= 11; can normalization be done?
g. Can’t upgrade a billion edge devices.
h. Comment= - even if not at same unicode version, will match for many values.
i. Little feed= back from il8n folks to date; goal to close on this by end of this week.
j. Commen= t – what is the problem with RFC4282? 
k. Bans unassigned unicode code = points. If proxy receives an unassigned code point, then drop. Does not supp= ort upgrading proxies.
l. http://tools.ietf.org/html/draft-ietf-radext-nai 

****************************************************= *****************************
4. Bernard Aboba – IEEE 802 extensions draft, = see http://tools.ietf.org/html/draft-ietf-radext-ieee802ext and http://www.i= etf.org/proceedings/88/slides/slides-88-radext-3.ppt 
a. WGLC has concluded.<= /div>
b. One= remaining issue – how to use RADIUS with wired extensions defined in = IEEE 802.1X-2010 Review of TLV types, 0-127 possible TLVs.
c. Proposal is to creat= e an EAPoL-Announcement attribute which can be present in all RADIUS message= and include the TLVs.
d. Define how to deal with multiple announcements attribute= s in a packet. Allows TLVs longer than 253 octets to be transported by RADIU= S.
e. = Proposal is in the draft. Confirm on the list, and with Joe Salowey that he = is ok with the proposed solution.
f. Question on the concatenation. Is there a spe= c that we can reference?
g. http://tools.ietf.org/html/draft-ietf-radext-ieee802ex= t 

*******************************************= **************************************
5. Diego Lopez – RADIUS Fragmentation= , see http://tools.ietf.org/html/draft-ietf-radext-radius-fragmentation and = http://www.ietf.org/proceedings/88/slides/slides-88-radext-6.pdf 
=
a. Reviewed= status: accepted as a WG document 2013-08-26. Solution focused on transport= of large amounts of auth info. 
b. Changes made to text to address issues.
i. Adde= d text clarifying that proxies are assumed to base their routing decisions o= n the value of the User-name attribute.
ii. New text regarding how proxies impleme= nt RFC6929 – SHOULD forward packages even if invalid attributes are fo= und.
iii. Included an example for SAML – roundtrips required.
c. Review of remaini= ng issues
i. = Proxy-State-Length attribute
ii. Detailed description of CoA handling.
d. Chair: = how many people have read the -01 version? Small number of hands.
= e. Alan: This is= a hack to get data through existing systems; don’t depend on it.
f. Sam: Be= lieve the draft is ready for AD review and transport area review; recommend = sending to those directorates for review sooner rather than later.
g. Get AD revie= w when we do WGLC on -02.

*************************= ********************************************************
6. Stefan not available: = defer.1:25 - 1:30PM RADIUS dynamic discovery, Stefan Winter (5 minutes) http= ://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery

********************************************************************= *************
7. Sam Hartman - Larger Packets for Remote RADIUS over TCP, see http= ://tools.ietf.org/html/draft-hartman-radext-bigger-packets and http://www.ie= tf.org/proceedings/88/slides/slides-88-radext-5.pdf 
a. Review of goals: carr= y packets with more than 4096 octets of attributes
b. Applications carrying RADIUS= over TLS; when security available, then can carry more info.
c. Review of open is= sue: Capability negotiation requested.
i. Unclear that this is needed. No way to t= ell if server supports large packets.
ii. Really capability discovery.
i= ii. But is capab= ility discovery really needed.
iv. Mitigated by experimental status of TCP transpo= rt, with no reasonable fallback.
v. Problem with multiple outstanding requests.
vi. Nego= tiation is strongly desired.
d. Review of open issue: Error Response.
i.= Use error codes= or access-reject
ii. Need feedback.
e. Question: Are there other circumstances when the= re are many packets in flight and one causes connection to be dropped?
=
i. If send = malformed packet, issue introduced. Only case known.
f. Fix issues, post updated d= raft; raise any objections now.
g. Question: Why doesn’t new infrastructure = require larger packets? 
i. Interest in implementing for RADIUS.
ii= . Discussion on = supporting RADIUS larger packets closed with approved re-charter.
= iii. Let market = decide. Some implementers and applications not interested in moving to DIAME= TER.
8. Wrap-up, next steps
a. Plan to have further discussion re: guidance on RADIUS an= d DIAMETER.
b. Benoit Claise: Call for action
i. There has been a request for a AAA tuto= rial to capture institutional knowledge.
ii. Please direct your interest in guidan= ce on RADIUS and DIAMETER to the AAA tutorial.
c. Alan DeKok – CoA and proxy=
d. Al= an DeKok - Data Types draft
e. Re-charter (or not)
f. How many people have read Sam̵= 7;s draft? About 4. Revision to be published soon, get more eyes on the revi= sion.

*********************************************= ************************************
9. Meeting adjourned 1410.


--B_3466485826_18643430-- --B_3466485826_18642607 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVXwYJKoZIhvcNAQcCoIIVUDCCFUwCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJ/MIIH+TCCBuGgAwIBAgIQW4k5wUL7YloEpOVNCxcNjjANBgkqhkiG9w0BAQUFADCB 9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55MR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMsQ2xhc3MgMiBN YW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAvBgNVBAMTKENvbGxhYm9y YXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzIwHhcNMTIwOTI2MDAwMDAwWhcNMTQw OTI2MjM1OTU5WjCBnjEgMB4GA1UEChQXSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkxJjAkBgNV BAsUHUVtcGxveW1lbnQgU3RhdHVzIC0gRW1wbG95ZWVzMQ8wDQYDVQQLEwZTL01JTUUxGTAX BgNVBAMTEE1hdXJpY2lvIFNhbmNoZXoxJjAkBgkqhkiG9w0BCQEWF21hdXJpY2lvLnNhbmNo ZXpAaHAuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAloXM4DJlquSNxT+X mgHkZBI15A2U8R9K0nRaXPMi7fxOzKJBFyLo3FIYQqhrbSaFFliRgRqx9AFqICnM063baYtG DT7ySQ2u9Ewm54kNxAJBR/+EJVoR+/MEq5u/N9FDd3wB5PnFUdfnJ56jsZNhAhUcILwoWxcv fp3hCI7r92O/y2Qmz0PrVf5d+0y0OiJqH7/Pf/uy8D0IivgEUnyKC+VO9MwUwXWzxA1rF1+z +czuQnuWO8nKUHl3EySJL97mM9fm8MCYQrTIBKKf0XpIpzQ+5QQorSHdJKoWVcMMWLtaJY9J A5DWMjKJA0cjD6cSEV8iwN+V58lnKXFGcRyETwIDAQABo4ID1jCCA9IwOwYDVR0RBDQwMoEX bWF1cmljaW8uc2FuY2hlekBocC5jb22BF21hdXJpY2lvX3NhbmNoZXpAaHAuY29tMAwGA1Ud EwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMFkGA1UdHwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNp dGVjcmwudmVyaXNpZ24uY29tL0hld2xldHRQYWNrYXJkQ29tcGFueVNNSU1FRzIvTGF0ZXN0 Q1JMLmNybDAfBgNVHSMEGDAWgBQifdOkq1esVn+pf0FEGpW8W/ir7jAdBgNVHQ4EFgQUYP/x peEEwA0JEKvMwMyDDurpqCowggEyBggrBgEFBQcBAQSCASQwggEgMCcGCCsGAQUFBzABhhto dHRwOi8vaHAtb2NzcC52ZXJpc2lnbi5jb20wgfQGCCsGAQUFBzACpIHnMIHkMTEwLwYDVQQD EyhDb2xsYWJvcmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyMTAwLgYDVQQLEydD bGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExOjA4BgNVBAsTMVRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhKGMpMDkxHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21w YW55MIIBPQYDVR0gBIIBNDCCATAwggEsBgtghkgBhvhFAQcXAjCCARswKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwge4GCCsGAQUFBwICMIHhMB4WF0hld2xl dHQtUGFja2FyZCBDb21wYW55MAMCAQIagb5BdXRob3JpdHkgdG8gYmluZCBIUCBkb2VzIG5v dCBjb3JyZXNwb25kIHdpdGggdXNlIG9yIHBvc3Nlc3Npb24gb2YgdGhpcyBjZXJ0aWZpY2F0 ZS4gSXNzdWVkIHRvIGZhY2lsaXRhdGUgY29tbXVuaWNhdGlvbiB3aXRoIEhQLiBWZXJpU2ln bidzIENQUyBpbmNvcnAuIEJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWdu MBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMEMEsGCSqGSIb3DQEJDwQ+MDwwDgYIKoZIhvcNAwIC AgCAMA4GCCqGSIb3DQMCAgIAQDAOBggqhkiG9w0DBAICAIAwCgYIKoZIhvcNAwcwDQYJKoZI hvcNAQEFBQADggEBAHWuCgf6c4Dj8NT1yYJpcuw18irgCh6aSdvVPwUroQwgZYcsCG9OqsVf /2H6zrefDswtfKHDK6jhy2MmL+Ohhdkzl+i9vXJw1ZtnoiRQdhjQs2sAqwI8N/aQ56hogrU9 754lDYZzesp6OabKBj9+t+XVX/lBovsme59hUlwmgOuG4AVfLf0N2CftTwdD5kDCx2aAnlG0 FdYOC/Cdf/tk4c89GogQPwQpNNjw+M6cJX9OWhUGVQ2jI/PuJvlPlP+oyXzAtS3sEejaxBPI h5nQCwseT7DQm2rbCSa1dc0h8ScezllGSZHca/ySZbJcf8vSRbk3tBsPKHbqNZqzEqfERVQw ggZhMIIFSaADAgECAhA7VxO2sCE1+15GdcpsssThMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYD VQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy dXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1 dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFBy aW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0wOTA5MDIwMDAwMDBaFw0x OTA5MDEyMzU5NTlaMIH3MQswCQYDVQQGEwJVUzEgMB4GA1UEChMXSGV3bGV0dC1QYWNrYXJk IENvbXBhbnkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRl cm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MTUwMwYD VQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTExMC8G A1UEAxMoQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBHMjCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAKdha2jarqqFZAxLy1DLMOhzIY6J/sotb/5GowNu 4yK3coUTI+IPjwb3gUx67QO8Pe0cdVCjz+grzmgBOcVLaFvWo2GbTuZHYlBcs1h7G1IEoysv sjTuEKB3hM2kIvyVlDmHr/wFeWGCaBAyMrKLBBC0tfzOuIhNlLc6/i8YloXWqkkROI4oG5uA 8uGsi86gL+X+6CC6yTWekoai4hhgqT/u63pU8kYBV5hF/0ijf2t/ScGaCkjVHSJGMq+8JjSP fs8pYXgyYIbpPpGQwA9zV7+BBlTFHzoOVBHYQCdC8ONA+Kaimtno9R9FIqStRBHUU5veEc3x PM/Lwz/PnXIDqgsCAwEAAaOCAhIwggIOMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkw ZzBlBgtghkgBhvhFAQcXAjBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j b20vY3BzMCoGCCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi1nMy5jcmwwDgYD VR0PAQH/BAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIw NDgtMTQyMB0GA1UdDgQWBBQifdOkq1esVn+pf0FEGpW8W/ir7jCB8AYDVR0jBIHoMIHloYHQ pIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IQYXDLSYxf mEUp57Cm2VBbejANBgkqhkiG9w0BAQUFAAOCAQEAdoqZeNFwhaMs169I9T6WV8Ogu0yXxIYR BUkixQrPwW9OtXymgDUb8uKPHDhicfM8vgAlSh6hEMmWO017rCZoo57pWaN4xkebP44wlsqo 1ig5VcfN7cnrspDklTA+tP3v8afJxuE2bChgVCeet6BxOr2rvNB1ItdT87KcWxV1COpJqzQu U8N8BhR7oPEUiCRtXpFrfmTrYewl1xm1bZk3cAp9CKjDYClVJEwZIgD67DezmWQK+VBk+ofE VAv9CNB/TFwrUpV7inKrSbf7FqkIIbwzvIR1If11NWxDmtioyQsoFnO5/5wLQTSsO17YBYLo boLVLG3RgY7bX5288HU2WDCCBBkwggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEB BQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw05OTEw MDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8KDcLVLNtn uS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8QzicT ngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDL HMQjPR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23S rGY/lozghNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOC AQEANCYVPMCNTUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDz mN+k5qQx39McC0bcciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfO RF3UG5CYDR5ClLEALATQdKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6 uuNkSLB/+zYl2pXQ8SQUF90YgGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I5 4bFD4CjPt+dabBNrSbP/4xh8iYszXawz16f52jpVyVgQ+arvWrbPS0vfKjGCAqQwggKgAgEB MIIBDDCB9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAvBgNVBAMTKENv bGxhYm9yYXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzICEFuJOcFC+2JaBKTlTQsX DY4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgOUYZdR6MHvSRF0iwq59g4S6e hQ+D27dTwt0pXwHT7FgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTMxMTA1MTY0MzQ2WjANBgkqhkiG9w0BAQEFAASCAQCFH4Bi5QlE+Ppf1W/eMjTsMg/M NypvFaAlx3FSxJL4+V/ADDI6ST14Xfx0sWAZ5ZzsPWzDslryvdQiWZn5PUeJjDeO1IdwPFX6 E6pkVZNaF1MYpbhh4Fg4ayaKHygNljh/Jx1t6mgAZL0mvipQ0JSSicLigeVk9AS15Bz7UJA/ XonqTKCYcAnr5TxMhnd1/3LfnfeDEQYPd3T/EpeLPQp+9gfHAwBFsZZjrbAf9yOpOfJm2FMU Vxb7/+yHW1H/3P8e/TVqEt5pCBVw70s20fFVr+56X2QBI9ysu2fsMiR0F5810oR2EAglj5Zf pQ4S/ZUfIEWoehfvg6p57clVRSpv --B_3466485826_18642607-- From internet-drafts@ietf.org Wed Nov 6 16:32:36 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF79111E81C5; Wed, 6 Nov 2013 16:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] 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 KzrvjNPlznSF; Wed, 6 Nov 2013 16:32:36 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A43D11E815E; Wed, 6 Nov 2013 16:32:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131107003236.21016.43517.idtracker@ietfa.amsl.com> Date: Wed, 06 Nov 2013 16:32:36 -0800 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-nai-05.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 00:32:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of the IE= TF. Title : The Network Access Identifier Author(s) : Alan DeKok Filename : draft-ietf-radext-nai-05.txt Pages : 24 Date : 2013-11-06 Abstract: In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each others users. This document defines the syntax for the Network Access Identifier (NAI), the user identity submitted by the client prior to accessing network resources. This document is a revised version of RFC 4282 [RFC4282], which addresses issues with international character sets, as well as a number of other corrections to the previous document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-nai There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-nai-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-nai-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From aland@deployingradius.com Wed Nov 6 16:34:09 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A4221F9D4C for ; Wed, 6 Nov 2013 16:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.964 X-Spam-Level: X-Spam-Status: No, score=-101.964 tagged_above=-999 required=5 tests=[AWL=0.635, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 WKMAlasb2AEa for ; Wed, 6 Nov 2013 16:34:02 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFAD11E815E for ; Wed, 6 Nov 2013 16:34:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id F092822401B6 for ; Thu, 7 Nov 2013 01:33:05 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luC4Fh-kE9RH for ; Thu, 7 Nov 2013 01:33:05 +0100 (CET) Received: from dhcp-b4f6.meeting.ietf.org (dhcp-b4f6.meeting.ietf.org [31.133.180.246]) by power.freeradius.org (Postfix) with ESMTPSA id 786A222400F7 for ; Thu, 7 Nov 2013 01:33:05 +0100 (CET) Message-ID: <527ADFC5.4020700@deployingradius.com> Date: Wed, 06 Nov 2013 16:33:09 -0800 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "radext@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [radext] NAI draft X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 00:34:09 -0000 I've submitted the latest rev of the NAI draft, which closes the last remaining issue. Alan DeKok. From trac+radext@trac.tools.ietf.org Wed Nov 6 16:34:42 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F9311E8179 for ; Wed, 6 Nov 2013 16:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.946 X-Spam-Level: X-Spam-Status: No, score=-100.946 tagged_above=-999 required=5 tests=[AWL=-0.647, BAYES_00=-2.599, MANGLED_NAIL=2.3, USER_IN_WHITELIST=-100] 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 uEUU4nVDJJxH for ; Wed, 6 Nov 2013 16:34:41 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9B311E815E for ; Wed, 6 Nov 2013 16:34:32 -0800 (PST) Received: from localhost ([127.0.0.1]:42160 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1VeDYK-0004Yv-I9; Thu, 07 Nov 2013 01:34:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-nai@tools.ietf.org, aland@deployingradius.com X-Trac-Project: radext Date: Thu, 07 Nov 2013 00:34:28 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/172#comment:2 Message-ID: <081.39c2be9754f0c943cf163ce0634dac36@trac.tools.ietf.org> References: <066.1dd2c72add09d45cd42a88636fe81ada@trac.tools.ietf.org> X-Trac-Ticket-ID: 172 In-Reply-To: <066.1dd2c72add09d45cd42a88636fe81ada@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-nai@tools.ietf.org, aland@deployingradius.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: aland@freeradius.org Resent-Message-Id: <20131107003432.5E9B311E815E@ietfa.amsl.com> Resent-Date: Wed, 6 Nov 2013 16:34:32 -0800 (PST) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [radext] #172: i18n review for closure of NFC form X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 00:34:42 -0000 #172: i18n review for closure of NFC form Changes (by aland@deployingradius.com): * status: new => closed * resolution: => fixed Comment: Fixed by updated text in -05. On further examination, the precis documents don't seem to help here. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- aland@deployingradius.com | nai@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: nai | Version: Severity: - | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From jsalowey@cisco.com Thu Nov 7 16:21:52 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A635011E8162 for ; Thu, 7 Nov 2013 16:21:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.574 X-Spam-Level: X-Spam-Status: No, score=-110.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 2YYnoQD4XAIT for ; Thu, 7 Nov 2013 16:21:47 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 5E52721E8169 for ; Thu, 7 Nov 2013 16:21:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3523; q=dns/txt; s=iport; t=1383870105; x=1385079705; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=N9K9QXdsjMWQeegVlno7McRQ1IvP1JTWpoE9kQDBHsU=; b=IQU9VHHLkmaN6G9FG9tpHOxCeYmAJ4LJ+MK5C0MiCuIQHXfeXQrhq7xz 4o8fjF86CBR6wscnJDPkefr291iVLEBzRAA2aLPy+XhYN6bF/RSDV4R/c MUN4ty9UXNvv9Z7kRsWv92kU2odm0VoKGa+m3RHG+LtD2sjkNX6DvOvpp s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAJMtfFKtJV2c/2dsb2JhbABagwc4U6w6klaBKBZ0giYBAQQ6PxACAQg2EDIlAgQOBYdvAw8NvTuMZ4FDfDMHgyCBEAOWIoFqgS+JI4IAA4U1gyaCKg X-IronPort-AV: E=Sophos;i="4.93,655,1378857600"; d="scan'208";a="282182527" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 08 Nov 2013 00:21:45 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rA80LiCV029106 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Nov 2013 00:21:44 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 18:21:44 -0600 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: [radext] #153: Section 2.8 Access-Info Thread-Index: AQHO3BiAHo+me4ltlUKeaZ7NeyjODw== Date: Fri, 8 Nov 2013 00:21:43 +0000 Message-ID: <2721A7E9-A3EA-48B1-A04A-439A9795BC65@cisco.com> References: <066.e99973544c7878635851fd28a6cf5689@trac.tools.ietf.org> <081.5af36284efbab97c92cf7df8fa0dde3f@trac.tools.ietf.org> In-Reply-To: <081.5af36284efbab97c92cf7df8fa0dde3f@trac.tools.ietf.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.85.165.166] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [radext] #153: Section 2.8 Access-Info X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 00:21:52 -0000 The resolution to this issue looks good.=20 Cheers, Joe On Oct 20, 2013, at 4:50 PM, radext issue tracker wrote: > #153: Section 2.8 Access-Info >=20 >=20 > Comment (by bernard_aboba@hotmail.com): >=20 > Updated text: >=20 > 2.8. EAPoL-Announcement >=20 > Description >=20 > The EAPoL-Announcement Attribute contains EAPoL-Announcement Type > Length Value Tuples (TLVs) defined within Table 11-8 of > IEEE-802.1X [IEEE-802.1X]. >=20 > Zero or more EAPoL-Announcement attributes are permitted within an > Access-Request, Access-Accept, Access-Challenge, Access-Reject, > Accounting-Request, CoA-Request or Disconnect-Request packet. >=20 > When included within an Access-Request packet, EAPoL-Announcement > attributes contain EAPoL-Announcement TLVs that the user sent in > an EAPoL-Announcement. When included within an Access-Accept, > Access-Challenge, Access-Reject, CoA-Request or Disconnect-Request > packet, EAPoL-Announcement attributes contain EAPoL-Announcement > TLVs that the NAS is to send to the user in a unicast EAPoL- > Announcement. When sent within an Accounting-Request packet, > EAPoL-Announcment attributes contain EAPoL-Announcement TLVs that > the NAS has most recently sent to the user in a unicast EAPoL- > Announcement. >=20 > A summary of the EAPoL-Announcement Attribute format is shown > below. The fields are transmitted from left to right. >=20 > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | String... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >=20 > Code >=20 > TBD7 >=20 > Length >=20 >> =3D3 >=20 > String >=20 > The String field is one or more octets, containing EAPoL- > Announcement TLVs in the format defined in Figure 11-8 of Section > 11.12 of [IEEE-802.1X]. Any EAPoL-Announcement TLV Type MAY be > included within an EAPoL-Announcement Attribute, including > Organizationally Specific TLVs. If multiple EAPoL-Announcement > attributes are present in a packet, their String fields MUST be > concatenated before being parsed for EAPoL-Announcement TLVs; this > allows EAPoL-Announcement TLVs longer than 253 octets to be > transported by RADIUS. Similarly, EAPoL-Announcement TLVs larger > than 253 octets MUST be fragmented between multiple EAPoL- > Announcement attributes. >=20 > --=20 > -------------------------------------+-----------------------------------= -- > Reporter: | Owner: draft-ietf-radext- > bernard_aboba@hotmail.com | ieee802ext@tools.ietf.org > Type: defect | Status: reopened > Priority: critical | Milestone: milestone1 > Component: ieee802ext | Version: 1.0 > Severity: In WG Last Call | Resolution: > Keywords: | > -------------------------------------+-----------------------------------= -- >=20 > Ticket URL: > radext >=20 From trac+radext@trac.tools.ietf.org Fri Nov 8 10:29:02 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A98911E81A2 for ; Fri, 8 Nov 2013 10:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.058 X-Spam-Level: X-Spam-Status: No, score=-102.058 tagged_above=-999 required=5 tests=[AWL=0.541, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 9ynV8cdKlHoP for ; Fri, 8 Nov 2013 10:29:01 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 663CE11E8108 for ; Fri, 8 Nov 2013 10:29:01 -0800 (PST) Received: from localhost ([127.0.0.1]:33120 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Veqnd-0005wR-D9; Fri, 08 Nov 2013 19:28:53 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-ieee802ext@tools.ietf.org, bernard_aboba@hotmail.com, jsalowey@cisco.com X-Trac-Project: radext Date: Fri, 08 Nov 2013 18:28:53 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/153#comment:8 Message-ID: <081.21b8343f28c8be4f5c9ee31a7333134a@trac.tools.ietf.org> References: <066.e99973544c7878635851fd28a6cf5689@trac.tools.ietf.org> X-Trac-Ticket-ID: 153 In-Reply-To: <066.e99973544c7878635851fd28a6cf5689@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-ieee802ext@tools.ietf.org, bernard_aboba@hotmail.com, jsalowey@cisco.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bernard_aboba@hotmail.com, j@w1.fi, jsalowey@cisco.com, mark@azu.ca, paul_congdon@hp.com Resent-Message-Id: <20131108182901.663CE11E8108@ietfa.amsl.com> Resent-Date: Fri, 8 Nov 2013 10:29:01 -0800 (PST) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [radext] #153: Section 2.8 Access-Info X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 18:29:02 -0000 #153: Section 2.8 Access-Info Changes (by bernard_aboba@hotmail.com): * status: reopened => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- bernard_aboba@hotmail.com | ieee802ext@tools.ietf.org Type: defect | Status: closed Priority: critical | Milestone: milestone1 Component: ieee802ext | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From stefan.winter@restena.lu Mon Nov 11 02:11:55 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA7D21E8091 for ; Mon, 11 Nov 2013 02:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, WEIRD_PORT=0.001] 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 GUCwWnM8tXIO for ; Mon, 11 Nov 2013 02:11:54 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB8921E81CD for ; Mon, 11 Nov 2013 02:11:37 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 31A1410580 for ; Mon, 11 Nov 2013 11:11:36 +0100 (CET) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 22BFC1057E for ; Mon, 11 Nov 2013 11:11:34 +0100 (CET) Message-ID: <5280AD55.7080908@restena.lu> Date: Mon, 11 Nov 2013 11:11:33 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "radext@ietf.org" X-Enigmail-Version: 1.6 OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pqrta30tovq6vgRePJtg70IWgL2sd993q" X-Virus-Scanned: ClamAV Subject: [radext] dynamic-discovery I-D - next steps X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 10:11:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pqrta30tovq6vgRePJtg70IWgL2sd993q Content-Type: multipart/mixed; boundary="------------030605000802020803080602" This is a multi-part message in MIME format. --------------030605000802020803080602 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, apologies for missing my talking slot. The draft didn't warrant a big slot anyway, because there's not really much to talk about at this stage. I only had two slides: 1) recently submitted draft addresses all issues from tracker and ML, including those from the very extensive review by Jim Schaad. I believe this makes the draft ready for advancement. I would like to request another WGLC. 2) just a double-check if we're still happy with the category of the draft: dynamic-discovery for RADIUS is very detailed, discusses many corner cases and possible caveats, gives guidance on how exactly to do S-NAPTR and it's in use in the public internet. And yet its EXP. Looking at dime, the DNS discovery document and base RFC offer a lot less detail, but made it to standards track. Just wondering - is EXP still a target that "feels right"? Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------030605000802020803080602 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2.0.19 (GNU/Linux) mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------030605000802020803080602-- --pqrta30tovq6vgRePJtg70IWgL2sd993q Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJSgK1WAAoJEMDeajWKOdxmhB8P/1bch1oI+w9iiO7UYHZuKx+N bmWs/GtVMEu9BVQbZdjmTJ9mf1SW/Y+tvlumxsiC/amZfiKpTnmIdQ6KJorO2yGJ s+Ffw02OCRgGDKNE2NQIibi1155WiPBT5O8qAmLuGMkGmQXwPEQ/FfYQJWzpmLAQ fRThrAzNAih/cIGoNjoa6VI5Gy7MNB5C3A65hX+UJaijpIiEPCbwazDWyNUSMosn 5JQbg27O0uOHEDYMMxOFBu3/DR3YdII/HLztUh9hBkmvgmgP5bP5qgXeKiCsLL2S /XQ8duQbMAvrhx413B3Rw/P2433Y+sPiQEj4qey8kroVUu6r3bmYhEsTaL2cPdXo WF5WumiHVsXiff12o9niBSkLQrEmxRTkqsWhjBT5xPGdCz7HiuXeJBljMkw3Agix NGu7sfo5fLliBeISeZA+EltRriqnTyhKaSQ/MqAXJlZmLs9aedV3UWPMp/d0p4my sxTI+XmSzQUwIsNyMJeLpJQyk0Ed/cCamIHlKhYwMseVrsODdTi3JbNsgNFpNEvm B376sXAEsTBKcCoqLPgI9GyzLhEu0vJWBoeIs4dZydR9fck6dC62DlLv2qkPatPV WDUDVc4N89nhKj+nsX3OYUHrrttOezFe58a1OLe21qHtNtx8BoP3Tq1MJnjPaFdu YFe49uDXeFdvTLekeEpO =3306 -----END PGP SIGNATURE----- --pqrta30tovq6vgRePJtg70IWgL2sd993q-- From mcr@sandelman.ca Tue Nov 12 10:31:26 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5B411E811B; Tue, 12 Nov 2013 10:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.302, 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 N7ruCiDhFoxl; Tue, 12 Nov 2013 10:31:18 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCFE11E810B; Tue, 12 Nov 2013 10:31:18 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 20CE5202EE; Tue, 12 Nov 2013 14:43:21 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 7489363B89; Tue, 12 Nov 2013 13:31:11 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 640A263848; Tue, 12 Nov 2013 13:31:11 -0500 (EST) From: Michael Richardson To: Ted Lemon In-Reply-To: <72351307-6AFD-4209-B04B-8025B544FC9A@fugue.com> References: <11836.1384276281@sandelman.ca> <72351307-6AFD-4209-B04B-8025B544FC9A@fugue.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 Sender: mcr@sandelman.ca Cc: "dhcwg@ietf.org WG" , "homenet@ietf.org Group" , "" Subject: Re: [radext] [homenet] PPP, DHCPv6 and Prefix Delegation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 18:31:26 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Ted Lemon wrote: Ted> Historically this has been proposed to be done with a stateful BRAS Ted> that retains authentication information from the PPP client/RADIUS Ted> server authentication process, and provides that to the DHCP server Ted> using a relay option. The DHCP server can then go to the RADIUS Ted> server to get prefix information if appropriate (although I would Ted> argue that this is unnecessary and probably harmful, since it Ted> requires static provisioning for all customers).=20 Some radius servers have the ability to allocate from a pool and the keep that lease for a period of time. Ted> Have you looked at RFC 4014 and RFC 7037? Thank you for the reference, which I missed in scanning relevant WG documen= ts. Reading. Ted> really be a problem. If the RADIUS server were doing dynamic Ted> allocation, it would potentially be a problem since resources that Ted> are committed during the solicit/advertise phase ought to be freed Ted> if no request/reply phase follows. I don't know enough about Ted> RADIUS to know if this ever happens, but it's my understanding that Ted> it does not.=20 It can occur. Ted> Of course, the larger question here is, why the heck would you want Ted> to use PPPoE with all the MTU woes it brings into the picture? I Ted> know the answers that are usually given, but I think this is Ted> something that ought to be treated as a less-preferred approach to Ted> delivering IPv6 service.=20 This is not a greenfield deployment. The existing service(s) is IPv4 PPPoE. To be clear: this is an existing product being updated to support IPv6 because the customers asked for it. (Truly!) PPPoE is also significantly easier for third party operators to work with in many jurisdictions. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUoJz7IqHRg3pndX9AQIQFgP/VzaNgmxblhmVNUCdWJJ3gx8SsB8HmxU8 DJdFzZH4GNDcJcKb1Z7+d7syDl/+uRojegW0d4+HDHpUpMuqKMBwtZbHv3QX5g9/ T+lNfC1XMJEK2eiDlBvC/g6OyV1wLJsdAMrOc4apm6hPCP7+59XrejJh6CMuTwRH nL1tHuzL/fA= =6dLl -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Tue Nov 12 09:11:55 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E7BA21E8091; Tue, 12 Nov 2013 09:11:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 21d-ef-9CuwS; Tue, 12 Nov 2013 09:11:55 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 67E5B21E82B8; Tue, 12 Nov 2013 09:11:29 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A4F40202EB; Tue, 12 Nov 2013 13:23:30 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 1DCBD63B89; Tue, 12 Nov 2013 12:11:21 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0E96963AEF; Tue, 12 Nov 2013 12:11:21 -0500 (EST) From: Michael Richardson To: dhcwg@ietf.org, homenet@ietf.org, radext@ietf.org X-Attribution: mcr 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 Sender: mcr@sandelman.ca X-Mailman-Approved-At: Tue, 12 Nov 2013 11:27:05 -0800 Subject: [radext] PPP, DHCPv6 and Prefix Delegation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 17:11:55 -0000 <#secure method=pgpmime mode=sign> (Please excuse my slight spray, but I'm unclear where the gap is. Also I've just subscribed to radext. Haven't done any radius stuff in a decade. It might also be that my question has been addressed by convention by some operator forum) BACKGROUND: I'm working on adding IPv6 to a PPPoE LAC, and specifically thinking about IPv6 Prefix Delegation. I'm working backwards from RFC6204 and the homenet architecture document to derive requirements for the ISP end. (If my document would be useful at the IETF, let me know. Really, there is little additional that homenet requires from ISPs other than 6204 and at least a /56... at least until we get to DNS delegations issues, which I plan to implement) ARCHITECTURE: The intended architecture is ppp speaks to radius server to authenticate the customer at LCP time, then RA and DHCPv6 daemon(s) are told about new interface; specifically about the customer associated with that virtual interface. I would prefer that the DHCPv6 speaks to the radius server as well to obtain IPv6 prefix information using RFC4818. (In IPv4 space the product has 6 different ways to maintain pools) ISSUES: The issue/question that I'm having is that it seems to me that the PD transaction must occur after the user is authenticated. That is, it does not occur during the initial Access-Request. It can't occur until the IPV6CP has brought the link up, and the customer has requested some address space. So, when the subsequent DHCPv6 with the PD request arrives (with the prefix-size and value hint), the DHCPv6 server will perform a second radius request. But how will this second request be linked to the first one? If the DUID had been communicated during the PPP LCP setup, then that could have been included in the initial Access-Request, and the second DHCPv6 could reference it. Or, if the radius server had returned some kind of session ID to the ppp, it could communicate that to a co-located DHCPv6 server (or relay) to include in the request. Fundamentally, I think it's pretty important when we get to DNS forward/reverse delegations that we are able to tie them to a specific customer account. My fallback at this point is that I will simply populate the Radius NAS-port consistently (likely from the ppp interfaces' ifindex). Perhaps I've missed some PPPoE specific mechanism for this. OTHER NOTES: =========== Also, I found the diagram in RFC4818 of concern. It suggests that the Radius server will be committing to providing the address space at the point of Solicit, rather than at the point of Request. Why isn't the diagram in section 1 like this: Requesting Router Delegating Router RADIUS Server | | | |-Solicit------------>| | |<--Advertise(Prefix)-| | |-Request(Prefix)---->| | | |-Request------------------------>| | |<--Accept(Delegated-IPv6-Prefix)-| |<--Reply(Prefix)-----| | | | | I guess that delegating router needs to know if there is address space that it can delegate, and if there wasn't it wouldn't Advertise. I just think that this should have been a three phase protocol. -- Michael Richardson , Sandelman Software Works From mellon@fugue.com Tue Nov 12 09:38:46 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDFC311E8142; Tue, 12 Nov 2013 09:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 ZdbJq7YIzpqc; Tue, 12 Nov 2013 09:38:19 -0800 (PST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id DE97311E8138; Tue, 12 Nov 2013 09:38:18 -0800 (PST) Received: from [IPv6:2001:470:88a3::b4f4:5f0a:2fa8:4a70] (unknown [IPv6:2001:470:88a3:0:b4f4:5f0a:2fa8:4a70]) by toccata.fugue.com (Postfix) with ESMTPSA id 87D932381D72; Tue, 12 Nov 2013 12:38:15 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ted Lemon In-Reply-To: <11836.1384276281@sandelman.ca> Date: Tue, 12 Nov 2013 12:38:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <72351307-6AFD-4209-B04B-8025B544FC9A@fugue.com> References: <11836.1384276281@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1822) X-Mailman-Approved-At: Tue, 12 Nov 2013 11:28:33 -0800 Cc: "dhcwg@ietf.org WG" , "homenet@ietf.org Group" , "" Subject: Re: [radext] [homenet] PPP, DHCPv6 and Prefix Delegation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 17:39:57 -0000 Historically this has been proposed to be done with a stateful BRAS that = retains authentication information from the PPP client/RADIUS server = authentication process, and provides that to the DHCP server using a = relay option. The DHCP server can then go to the RADIUS server to get = prefix information if appropriate (although I would argue that this is = unnecessary and probably harmful, since it requires static provisioning = for all customers). Have you looked at RFC 4014 and RFC 7037? The reason for the state diagram in 4818 looking as it does is that the = DHCP server has to know how it's going to respond to a request from the = client before it sends its advertise message. Since the prefix is = statically configured on the RADIUS server, this shouldn't really be a = problem. If the RADIUS server were doing dynamic allocation, it would = potentially be a problem since resources that are committed during the = solicit/advertise phase ought to be freed if no request/reply phase = follows. I don't know enough about RADIUS to know if this ever = happens, but it's my understanding that it does not. Of course, the larger question here is, why the heck would you want to = use PPPoE with all the MTU woes it brings into the picture? I know the = answers that are usually given, but I think this is something that ought = to be treated as a less-preferred approach to delivering IPv6 service. From robmgl.ietf@gmail.com Thu Nov 14 19:08:59 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE2011E8170; Thu, 14 Nov 2013 19:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, NO_RELAYS=-0.001] 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 R0mEnNhPB0H9; Thu, 14 Nov 2013 19:08:58 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) by ietfa.amsl.com (Postfix) with ESMTP id 303EB11E817D; Thu, 14 Nov 2013 19:08:53 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id u14so2287479lbd.11 for ; Thu, 14 Nov 2013 19:08:47 -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=gAYXFOca0YtuMly2lsXpLEi0ia+9+e3XQuMJ05HfdqI=; b=rjuA4b4SCOtls1afB0qA27cvuuAf7ZrsL+ShiMGvW0Gg30KkOVaj+F87ZPuABHfLe7 ZuwoFFCvYZ8HgaDkKfirzJMvxdrYvHxy8/3KUUh6HRXDxQ89QBJRvHFLVxwd2fvW6hTK ER+KEA4OeQmBmshRk2A28CEU3xvq556oyQeAqQHIid0L8E+mO+Pp35qmx4KQtAIoKopH 8zJk02Ia3xz2TqNwK12tESmTnaCBuPVRXtyhgY6We87chWT3MI/sFgFZJHE1+JxHVj6M UTRs716pN8/OEvGUt2fjHElJVil2xkhY+9dPUEDi2/ZC1wdiazaThlgEs0FHHILAqDo6 8pog== MIME-Version: 1.0 X-Received: by 10.152.216.167 with SMTP id or7mr2699289lac.10.1384484927596; Thu, 14 Nov 2013 19:08:47 -0800 (PST) Received: by 10.112.159.3 with HTTP; Thu, 14 Nov 2013 19:08:47 -0800 (PST) In-Reply-To: <11836.1384276281@sandelman.ca> References: <11836.1384276281@sandelman.ca> Date: Thu, 14 Nov 2013 22:08:47 -0500 Message-ID: From: Roberta Maglione To: Michael Richardson Content-Type: multipart/alternative; boundary=001a1135e3184e6b1904eb2e8465 X-Mailman-Approved-At: Thu, 14 Nov 2013 23:21:16 -0800 Cc: "dhcwg@ietf.org WG" , homenet@ietf.org, robmgl@cisco.com, radext@ietf.org Subject: Re: [radext] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 03:08:59 -0000 --001a1135e3184e6b1904eb2e8465 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello Michael, in DSL/Broadband environment usually the BNAS/BNG acts both as RADIUS Client and as DHCPv6 Server. In case of an IPv6 PPP session (or a PPP dual stack IPv4/IPv6 session) the PPP session is established using LCP that is independent of the network layer protocol that needs to be carried over PPP. LCP allows for the transport of both IPv4 and IPv6 at the same time over the same PPP session. In IPv6, address assignment is performed at the network layer, in contrast to IPv4 where a number of functions are handled in the PPP layer. The only function handled in IPv6 Control Protocol (IPv6CP) is the negotiation of a unique interface identifier. The IPv6CP is only used to configure the link local address. The PPP link can be unnumbered (i.e. only using link =96 local addresses) o= r numbered by the BNG which can assignIPv6 addresses to the remote peer via SLAAC or DHCPv6. In addition to that DHCPv6-PD in order to get an IPv6 Prefix for the home network. Both the IPv6 prefix to be used for the DHCPv6-PD and the IPv6 prefix used to number the Wan link (if needed) via SLAAC or DHCPv6, can be extracted from a pool (locally configured on the BNG) and the pool name could be sent from the RADIUS Server using specific RADIUS attributes in the Access-Accept during the authentication phase. Please take a look at RFC 6911 for the details about the attributes for the pool names and architecture. 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= . Please take a look at TR-187 issue2 from BBF http://www.broadband-forum.org/technical/download/TR-187_Issue-2.pdf and RFC 4241 for more details on the architectural model. Hope this helps. Thanks Roberta On Tue, Nov 12, 2013 at 12:11 PM, Michael Richardson wrote: > > <#secure method=3Dpgpmime mode=3Dsign> > > (Please excuse my slight spray, but I'm unclear where the gap is. > Also I've just subscribed to radext. Haven't done any radius stuff in a > decade. It might also be that my question has been addressed by conventio= n > by > some operator forum) > > BACKGROUND: > I'm working on adding IPv6 to a PPPoE LAC, and specifically thinking abou= t > IPv6 Prefix Delegation. I'm working backwards from RFC6204 and the homen= et > architecture document to derive requirements for the ISP end. > (If my document would be useful at the IETF, let me know. Really, there > is little additional that homenet requires from ISPs other than 6204 and = at > least a /56... at least until we get to DNS delegations issues, which I > plan > to implement) > > > ARCHITECTURE: > The intended architecture is ppp speaks to radius server to authenticate > the > customer at LCP time, then RA and DHCPv6 daemon(s) are told about new > interface; specifically about the customer associated with that virtual > interface. I would prefer that the DHCPv6 speaks to the radius server > as well to obtain IPv6 prefix information using RFC4818. > (In IPv4 space the product has 6 different ways to maintain pools) > > ISSUES: > The issue/question that I'm having is that it seems to me that the PD > transaction must occur after the user is authenticated. That is, it does > not > occur during the initial Access-Request. It can't occur until the IPV6CP > has > brought the link up, and the customer has requested some address space. > > So, when the subsequent DHCPv6 with the PD request arrives (with the > prefix-size and value hint), the DHCPv6 server will perform a second > radius request. But how will this second request be linked to the first > one? > > If the DUID had been communicated during the PPP LCP setup, then that cou= ld > have been included in the initial Access-Request, and the second DHCPv6 > could > reference it. > > Or, if the radius server had returned some kind of session ID to the ppp, > it could communicate that to a co-located DHCPv6 server (or relay) to > include > in the request. > > Fundamentally, I think it's pretty important when we get to DNS > forward/reverse delegations that we are able to tie them to a specific > customer account. > > My fallback at this point is that I will simply populate the Radius > NAS-port > consistently (likely from the ppp interfaces' ifindex). Perhaps I've > missed > some PPPoE specific mechanism for this. > > > OTHER NOTES: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Also, I found the diagram in RFC4818 of concern. It suggests that the > Radius server will be committing to providing the address space at > the point of Solicit, rather than at the point of Request. > Why isn't the diagram in section 1 like this: > > Requesting Router Delegating Router RADIUS Server > | | | > |-Solicit------------>| | > |<--Advertise(Prefix)-| | > |-Request(Prefix)---->| | > | |-Request------------------------>| > | |<--Accept(Delegated-IPv6-Prefix)-| > |<--Reply(Prefix)-----| | > | | | > > I guess that delegating router needs to know if there is address space > that it can delegate, and if there wasn't it wouldn't Advertise. I just > think that this should have been a three phase protocol. > > > -- > Michael Richardson , Sandelman Software Works > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > --001a1135e3184e6b1904eb2e8465 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hello Michael,

in DSL/Broadband environment usually the BNAS/BNG ac= ts both as RADIUS Client and as DHCPv6 Server. In case of an IPv6 PPP session (or a= PPP dual stack IPv4/IPv6 session)=A0 the PPP session is established using LCP that is independent of the network layer protocol = that needs to be carried over PPP. LCP allows for the transport of both IPv4 and IPv6 at the same time over the same PPP session.

In IPv6, address assignment is perf= ormed at the network layer, in contrast to IPv4 where a number of functions are h= andled in the PPP layer. The only function handled in IPv6 Control Protocol (IPv6C= P) is the negotiation of a unique interface identifier. The IPv6CP is o= nly used to configure the link local address.

The PPP link can be unnumbered (i.e. only using link= =96 local addresses) or numbered by the BNG which can assignIPv6 addresses to the rem= ote peer via SLAAC or DHCPv6. In addition to that DHCPv6-PD in order to get an = IPv6 Prefix for the home network.

Both the IPv6 prefix to be used for the DHCPv6-PD an= d the IPv6 prefix =A0used to number the Wan link (if needed) via SLAAC or DHCPv6, can be extracted from a pool (locally configur= ed on the BNG) and the pool name could be sent from the RADIUS Server using speci= fic RADIUS attributes in the Access-Accept during the authentication phase. Ple= ase take a look at RFC 6911 for the details about the attributes for the pool n= ames and architecture.

Basically all the parameters required to configure t= he 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 pre= fix to the home network.

Please take a look at TR-187 issue2 from BBF

http://www.broadband-forum.org/technical/downl= oad/TR-187_Issue-2.pdf

=A0and RFC 4241 for= =A0 more details on the architectural model. =A0<= /p>

Hope this helps.

Thanks

Roberta



On Tue, Nov 1= 2, 2013 at 12:11 PM, Michael Richardson <mcr+ietf@sandelman.ca>= wrote:

<#secure method=3Dpgpmime mode=3Dsign>

(Please excuse my slight spray, but I'm unclear where the gap is.
Also I've just subscribed to radext. Haven't done any radius stuff = in a
decade. It might also be that my question has been addressed by convention = by
some operator forum)

BACKGROUND:
I'm working on adding IPv6 to a PPPoE LAC, and specifically thinking ab= out
IPv6 Prefix Delegation. =A0I'm working backwards from RFC6204 and the h= omenet
architecture document to derive requirements for the ISP end.
(If my document would be useful at the IETF, let me know. =A0Really, there<= br> is little additional that homenet requires from ISPs other than 6204 and at=
least a /56... at least until we get to DNS delegations issues, which I pla= n
to implement)


ARCHITECTURE:
The intended architecture is ppp speaks to radius server to authenticate th= e
customer at LCP time, =A0then RA and DHCPv6 daemon(s) are told about new interface; specifically about the customer associated with that virtual
interface. =A0 =A0I would prefer that the DHCPv6 speaks to the radius serve= r
as well to obtain IPv6 prefix information using RFC4818.
(In IPv4 space the product has 6 different ways to maintain pools)

ISSUES:
The issue/question that I'm having is that it seems to me that the PD transaction must occur after the user is authenticated. =A0That is, it does= not
occur during the initial Access-Request. =A0It can't occur until the IP= V6CP has
brought the link up, and the customer has requested some address space.

So, when the subsequent DHCPv6 with the PD request arrives (with the
prefix-size and value hint), the DHCPv6 server will perform a second
radius request. =A0But how will this second request be linked to the first = one?

If the DUID had been communicated during the PPP LCP setup, then that could=
have been included in the initial Access-Request, and the second DHCPv6 cou= ld
reference it.

Or, if the radius server had returned some kind of session ID to the ppp, it could communicate that to a co-located DHCPv6 server (or relay) to inclu= de
in the request.

Fundamentally, I think it's pretty important when we get to DNS
forward/reverse delegations that we are able to tie them to a specific
customer account.

My fallback at this point is that I will simply populate the Radius NAS-por= t
consistently (likely from the ppp interfaces' ifindex). =A0Perhaps I= 9;ve missed
some PPPoE specific mechanism for this.


OTHER NOTES:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Also, I found the diagram in RFC4818 of concern. =A0It suggests that the Radius server will be committing to providing the address space at
the point of Solicit, rather than at the point of Request.
Why isn't the diagram in section 1 like this:

Requesting Router =A0 Delegating Router =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= RADIUS Server
=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0|-Solicit------------>| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0|<--Advertise(Prefix)-| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0|-Request(Prefix)---->| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |-Request-----= ------------------->|
=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |<--Accept(= Delegated-IPv6-Prefix)-|
=A0 =A0 =A0 =A0 =A0|<--Reply(Prefix)-----| =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
=A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |

I guess that delegating router needs to know if there is address space
that it can delegate, and if there wasn't it wouldn't Advertise. = =A0I just
think that this should have been a three phase protocol.


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


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg

--001a1135e3184e6b1904eb2e8465-- From mcr@sandelman.ca Fri Nov 15 07:11:42 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@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 To: Roberta Maglione In-Reply-To: References: <11836.1384276281@sandelman.ca> 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 Sender: mcr@sandelman.ca Cc: "dhcwg@ietf.org WG" , homenet@ietf.org, robmgl@cisco.com, radext@ietf.org Subject: Re: [radext] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 15:11:42 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 standardi= ze 4241? (Will TR-187 get re-issued with the reference to access-16 changed t= o RFC6911?) =3D=3D=3D 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 th= at 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 larg= e, 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 a= nd 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 de= legate 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 reques= t. It also implies that every customer, even those not yet IPv6 ready, are goi= ng to get IPv6 prefixes delegated to them, as the various IPv6 radius attribut= es are returned during PPP LCP phase, and before one has any idea that the cus= tomer 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 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 pref= ix > 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> =C2=A0and RFC 4241 for=C2=A0 more details on the architectural mod= el. =C2=A0 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. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | network architect= [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUoY5m4qHRg3pndX9AQKMHAP/RUv5VbgY2mKJMAp2jngBBJMbSkWj5Fal cDZoV5v8jWlkXgftxYxCt/PQPNi1HQlYnpeejqYUHqZl8AHFr3Z76ZjG37aMrry+ QqGKZzp+CQOuAR2K9qfVhWXSWepnxuIlI/E7TyK3Fw7coN1y5k9yret8x+5Qhd9B uYwhsFET4cc= =mkSS -----END PGP SIGNATURE----- --=-=-=-- From hartmans@painless-security.com Fri Nov 15 07:43:24 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 185E311E81DD for ; Fri, 15 Nov 2013 07:43:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 uxrVBYLoAE6X for ; Fri, 15 Nov 2013 07:43:17 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 1077311E81AC for ; Fri, 15 Nov 2013 07:42:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id A48D420540; Fri, 15 Nov 2013 10:42:27 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k3uN1TwGjzXW; Fri, 15 Nov 2013 10:42:27 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (c-50-136-31-107.hsd1.ma.comcast.net [50.136.31.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Fri, 15 Nov 2013 10:42:27 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3FDC0819E7; Fri, 15 Nov 2013 10:42:37 -0500 (EST) From: Sam Hartman To: Alan DeKok References: <527ADFC5.4020700@deployingradius.com> Date: Fri, 15 Nov 2013 10:42:37 -0500 In-Reply-To: <527ADFC5.4020700@deployingradius.com> (Alan DeKok's message of "Wed, 06 Nov 2013 16:33:09 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "radext@ietf.org" Subject: Re: [radext] NAI draft X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 15:43:24 -0000 Alan, thanks for working through the i18n issues. I realize it was difficult, but I think worthwhile. From mcr@sandelman.ca Fri Nov 15 11:19:27 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72FF111E8164; Fri, 15 Nov 2013 11:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.410, 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 1NeHRnAZA4T4; Fri, 15 Nov 2013 11:19:27 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id EA7D711E815C; Fri, 15 Nov 2013 11:19:26 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6CDE420084; Fri, 15 Nov 2013 15:31:39 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 7490963B88; Fri, 15 Nov 2013 14:19:25 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 64B7563AEF; Fri, 15 Nov 2013 14:19:25 -0500 (EST) From: Michael Richardson To: Wuyts Carl In-Reply-To: <3135C2851EB6764BACEF35D8B495596806FB78DF8E@MOPESMBX01.eu.thmulti.com> References: <11836.1384276281@sandelman.ca> <3673.1384528283@sandelman.ca> <3135C2851EB6764BACEF35D8B495596806FB78DF8E@MOPESMBX01.eu.thmulti.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 Sender: mcr@sandelman.ca Cc: Roberta Maglione , "homenet@ietf.org" , "robmgl@cisco.com" , "radext@ietf.org" , "dhcwg@ietf.org WG" Subject: Re: [radext] [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 19:19:27 -0000 --=-=-= Wuyts Carl wrote: > 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. Yes, it all seems way more elegate to do it that way. If you, as a CPE vendor are happy with getting such a thing, then, if one has to number that WAN link, I'd prefer to do it this way. I think that this might be a new statement on the homenet side. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUoZzvYqHRg3pndX9AQLLSQP8CjQkTiyYTtY9ZVttUaGAMlqcRrM4d+KS +wNTeoxAMSNITmeuG+7/eOn5B4W/cfOJ8I0pJPkTBtBXwrMHAJ4k2uEev922bT+6 xyziLfdZ9KnsDVelU8wCvvoZEQBybgnVcyR/ocT/BCrwwDiDsDa+njR6/kt0tKC8 VM/JwinfuLU= =5SGp -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Fri Nov 15 11:54:49 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@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 To: Roberta Maglione In-Reply-To: References: <11836.1384276281@sandelman.ca> <3673.1384528283@sandelman.ca> 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 Sender: mcr@sandelman.ca Cc: "dhcwg@ietf.org WG" , homenet@ietf.org, robmgl@cisco.com, radext@ietf.org Subject: Re: [radext] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 19:54:49 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Roberta Maglione wrote: > Thank you for the write up. > It's clear that there is a gap, which TR-187 has filled. > =C2=A0 =C2=A0 =C2=A0http://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? =C2=A0 rm> [RM] Well, basically there were no new protocol extensions to be st= andardized rm> in order to cover this scenario;=C2=A0=C2=A0the missing piece=C2=A0= was a document=C2=A0where rm> to=C2=A0glue=C2=A0together all the different pieces and specify req= uirements for CPE and rm> BNG, that's why we (speaking as one of the co-editors of TR-187)=C2= =A0did this work rm> at the BBF/ The issue is whether the Broadband forum does not have the same trade-agree= ment 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 for= um 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 sill= y. rm> [RM] Why do you think=C2=A0it is silly?=C2=A0The ISPs have to make = a-priori decision rm> about the provisioning model in order to provision the customers wi= th the right rm> service=C2=A0profile. rm> This is not different=C2=A0with 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=C2=A0"user profile" o= n RADIUS server rm> will be different from yours. The ISP is forced to provision IPv6 to *all* customers in an area, regardle= ss 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, bu= t I > can=C2=A0add some=C2=A0more details on the prefix to be used for the = WAN link. > Actually using a /64 taken from the prefix delegated via DHCP-PD=C2= =A0to number the > WAN link at the time we wrote the first version of TR-187 was not all= owed by > RFC3633 because the WAN is the link from where the prefix was receive= d. =C2=A0 > More recently RFC 6603 about Prefix exclude was published so today yo= u could > theoretically do that if you use prefix exclude option, but I'm not s= ure how > much this model has been adopted. It is referenced in =C2=A0draft-iet= f-v6ops-6204bis > WPD-8. Thanks also for this. TR187 does not mention 6603... =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | network architect= [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUoZ8AYqHRg3pndX9AQJJGgP/cZEPJvrzw0hwkXtCd83H9028f5sFL/cj dQBX6zyULLB/g01MxVHkUePBDyxkjc9u2/wlHq7VEAkF/Cx0rqePQcvqQ8VAGY8b vbHmjGKG09dYZH2SN3sWlHVHvoleJcEzHbuPPFNJ8NLF+LYfiHZAuNdEZWWYMo+9 u8wQ32UyBzQ= =aMel -----END PGP SIGNATURE----- --=-=-=-- From robmgl.ietf@gmail.com Fri Nov 15 09:57:32 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77A411E810C; Fri, 15 Nov 2013 09:57:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, NO_RELAYS=-0.001] 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 2q1OJnfVhXSC; Fri, 15 Nov 2013 09:57:31 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) by ietfa.amsl.com (Postfix) with ESMTP id AAFC111E80F5; Fri, 15 Nov 2013 09:57:24 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id z5so3005606lbh.29 for ; Fri, 15 Nov 2013 09:57:23 -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=CE9DDCsVyuMZ8/41dVzLas7RhaG8+XQuu4OvY3eX2BQ=; b=FQaN2CL5XFcXUyjO20xbQ6ZmAtPp+M36vkmTXJX9Yz9AiKAwNAYQ1uzxdHdFSXHgcy Ssatz7dwjWVNPYoCJ7sXmos2j7RfoLr/HxO0qmyCKvz3xoZxjggWUi9xX+ahyYMido+v mH6pETozC9FXJMA4iAt73SVRiABMQLLlKGbU3KFbWOo5PWw0/8vC/Z0xnjaNeYN/KqXl rm/eQGSaqKv2TYpUkSYqeGtncKXeqz3lGDJXaL/AvX+9n7fG8a8S6Ny7UcasN6SNp3kF I/L6pgUkrrZWCAlXkc/gcXyNoLOdi/TMbDIeYe+EOiu/nkS1g7M1mUL8HLsEkUxvCGDm MbUw== MIME-Version: 1.0 X-Received: by 10.112.144.5 with SMTP id si5mr1919287lbb.33.1384538243582; Fri, 15 Nov 2013 09:57:23 -0800 (PST) Received: by 10.112.159.3 with HTTP; Fri, 15 Nov 2013 09:57:23 -0800 (PST) In-Reply-To: <3673.1384528283@sandelman.ca> References: <11836.1384276281@sandelman.ca> <3673.1384528283@sandelman.ca> Date: Fri, 15 Nov 2013 12:57:23 -0500 Message-ID: From: Roberta Maglione To: Michael Richardson Content-Type: multipart/alternative; boundary=047d7b34337c2fcd7404eb3aeeab X-Mailman-Approved-At: Mon, 18 Nov 2013 05:18:02 -0800 Cc: "dhcwg@ietf.org WG" , homenet@ietf.org, robmgl@cisco.com, radext@ietf.org Subject: Re: [radext] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 17:57:32 -0000 --047d7b34337c2fcd7404eb3aeeab Content-Type: text/plain; charset=ISO-8859-1 Please see comments inline [RM]. Regards, Roberta On Fri, Nov 15, 2013 at 10:11 AM, Michael Richardson 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] Well, basically there were no new protocol extensions to be standardized in order to cover this scenario; the missing piece was a document where to glue together all the different pieces and specify requirements for CPE and BNG, that's why we (speaking as one of the co-editors of TR-187) did this work at the BBF/ > (Will TR-187 get re-issued with the reference to access-16 changed to > RFC6911?) > [RM] Well I don't yet, maybe, I need to speak with the other co-editors none of us is actively involved in BBF anymore. > === > 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. > [RM] This is really a Service Provider's preference: there are operators that prefer numbered model (for management/security purposes) and others that are fine with just the link-local and the loopback for management. We had a long discussion in BBF about this point and both models appeared to be valid. > > 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. > [RM] Why do you think it is silly? The ISPs have to make a-priori decision about the provisioning model in order to provision the customers with the right service profile. This is not different with what it happens today for IPv4: let's say you are a customer that subscribes both Internet and IPTV service, while I'm a customer that only subscribes the internet service: my "user profile" on RADIUS server will be different from yours. > 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. > [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. > > 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. > [RM] back to my previous comment: provision the customer/service profile in the RADIUS server is a common practice in Service Provider's environment. > 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. > [RM] TR-187 allows for both options either DHCPv6 or SLAAC can be used to number the WAN link: there are Service Providers that would like to use DHCPv6 other that prefer SLAAC. Infect R-22 says "[....] when using DHCPv6 for address assignment" and R-29 says " When SLAAC is used to number the WAN link". You use either R-22 (if you do DHCPv6) or R-29 (if you do SLAAC) or none for unnumbered. Thanks Roberta > > > Roberta Maglione 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 , Sandelman Software Works > > > --047d7b34337c2fcd7404eb3aeeab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Please see comments inline [RM].
Regards,
Roberta

On Fri, Nov 15, 2013 a= t 10:11 AM, Michael Richardson <mcr+ietf@sandelman.ca> w= rote:

Thank you for the write up.
It's clear that there is a gap, which TR-187 has filled.
=A0 =A0 =A0http://www.broadband-forum.org/technical= /download/TR-187_Issue-2.pdf

RFC4241 is Informational... why didn't TR-187 come to the IETF to stand= ardize
4241? =A0
[RM] Well, basically there were no new protocol = extensions to be standardized in order to cover this scenario;=A0=A0the mis= sing piece=A0was a document=A0where to=A0glue=A0together all the different = pieces and specify requirements for CPE and BNG, that's why we (speakin= g as one of the co-editors of TR-187)=A0did this work at the BBF/=A0=A0
=A0
(Will TR-187 get re-issued with the referenc= e to access-16 changed to RFC6911?)
[RM]=A0Well I don't yet, maybe, I=A0need to speak wit= h the other co-editors none of us is=A0actively involved=A0in BBF anymore.<= /div>
=A0
=3D=3D=3D
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.
<= div>[RM] This is really a Service Provider's preference: there are oper= ators that prefer numbered model (for management/security purposes)=A0and o= thers that are fine with just the link-local and the loopback for managemen= t.=A0We had a long discussion in BBF=A0about this point and=A0both models a= ppeared to be valid.=A0

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? =A0 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. =A0And this seems to imply that<= br> all customers will have to be provisioned.... while IPv6 space is very larg= e,
bigger allocations cost ISPs more money, and so this still seems silly.
=
[RM] Why do you think=A0it is silly?=A0The ISPs have to m= ake a-priori decision about the provisioning model in order to provision th= e customers with the right service=A0profile.
This is not different=A0with what it happens today for IPv4: let's= say you are a customer that subscribes both Internet and IPTV service, whi= le I'm a customer that only subscribes the internet service: my=A0"= ;user profile" on RADIUS server will be different from yours.
=A0
While the customer can be provisioned, the end user may well swap CPEs in a= nd
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. =A0RFC6204 says:
=A0 =A0 =A0W-3: =A0Absent other routing information, the IPv6 CE router MUS= T use
=A0 =A0 =A0 =A0 =A0 =A0Router Discovery as specified in [RFC4861] to discov= er a

yet, RFC4241 omits a RS/RA phase in section 2.2, which specifically goes =A0 =A0 =A0 =A0 from IPV6CP (link-address negotiation) to prefix delegation=

=A0 2.2. IP Layer
=A0 =A0 After IPV6CP negotiation, the CPE initiates a prefix delegation
=A0 =A0 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 ca= n
=A0assume 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 ev= en
more complex, so I'd rather number it outside the PD if it needs to be<= br> numbered at all.
[RM] I'm not familiar with securi= ty, I cannot comment on firewall, but I can=A0add some=A0more details on th= e prefix to be used for the WAN link.
Actually using a /64 taken = from the prefix delegated via DHCP-PD=A0to 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. =A0
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 =A0draft= -ietf-v6ops-6204bis WPD-8.

Meanwhile, TR-187 says that Route Advertisements are generated by the BNG.<= br> (section 5.2

and says:
=A0 =A0 Whenever the Framed-IPv6-Prefix attribute is returned from RADIUS, = the
=A0 =A0 BNG includes this prefix as On-Link and Autonomous in the Router =A0 =A0 Advertisement Prefix Information Option. If this attribute is omitt= ed,
=A0 =A0 the BNG will not send a Prefix Information Option. DHCPv6 is used t= o 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. =A0This 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 reques= t.
[RM] back to my previous comment: provision the cus= tomer/service profile in the RADIUS server is a common practice in Service = Provider's environment.
=A0
It also implies that every customer, even those not yet IPv6 ready, are goi= ng
to get IPv6 prefixes delegated to them, as the various IPv6 radius attribut= es
are returned during PPP LCP phase, and before one has any idea that the cus= tomer
is v6 capable. =A0It 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. =A0RFC6911 outlines the attributes to be used, but it isn't clear to me that they have to be do= ne at
PPP LCP time.

It seems that TR-187, in requirement R-22, (section 9), is suggesting that<= br> /128 addresses be given out via stateful DHCPv6. =A0But R-29 says /64 for SLAAC.
[RM]=A0TR-187=A0allows=A0for both options eithe= r DHCPv6 or SLAAC=A0can be used to number the WAN link: there are Service P= roviders that=A0would like to use DHCPv6 other that prefer SLAAC.

Infect R-22 says "[....]= =A0 =A0when using DHCPv6 for address assignment" and R-29= says " When SLAAC is used to number = the WAN link".

You use either R-22 (if you do DHCPv6)=A0or R-29 (if you do SLAAC) or n= one for unnumbered.

Thanks

<= span style=3D"line-height:115%;font-family:"Arial","sans-ser= if";font-size:10pt">Roberta

=

=A0


Roberta Maglione <robmgl.ietf@g= mail.com> wrote:
=A0 =A0 > Basically all the parameters required to configure the RG can = be sent
=A0 =A0 > by the RADIUS Server to the BNG (RADIUS client) in the Access-= Accept
=A0 =A0 > during the authentication phase and then the BNG (acting as DH= CPv6
=A0 =A0 > Server) can use them to number the Wan link and delegate an IP= v6 prefix
=A0 =A0 > to the home network.

Yes, =A0the delegated prefix could be in the initial Access-Accept, a= nd this is
easy to do if the prefixes are all statically provisioned. =A0There are rad= ius
servers that can do dynamic allocation, but the bigger issue I'm concer= ned
about is that the allocation may not be able to reflect what the CPE will actually ask for.

=A0 =A0 > Please take a look at TR-187 issue2 from BBF

=A0 =A0 > http://www.broadband-forum.org/technic= al/download/TR-187_Issue-2.pdf

Thank you this document is useful. =A0I'd like to ask that some h= omenet
document cite it.

=A0 =A0 mcr> =A0and RFC 4241 for=A0 more details on the architectural mo= del. =A0

=A0 =A0 mcr> =A0 =A0 Or, if the radius server had returned some kind of = session ID to
=A0 =A0 mcr> the ppp, it could communicate that to a co-located DHCPv6 s= erver (or
=A0 =A0 mcr> relay) to include in the request.

I have been reminded of the radius State attribute which is commonly used.<= br>
--
] =A0 =A0 =A0 =A0 =A0 =A0 =A0 Never tell me the odds! =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 | ipv6 mesh networks [
] =A0 Michael Richardson, Sandelman Software Works =A0 =A0 =A0 =A0| network= architect =A0[
] =A0 =A0 mcr@sandelman.ca =A0http://www.sandelman.ca/<= /a> =A0 =A0 =A0 =A0| =A0 ruby on rails =A0 =A0[

--047d7b34337c2fcd7404eb3aeeab-- From Carl.Wuyts@technicolor.com Fri Nov 15 07:30:25 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F06911E81B1; Fri, 15 Nov 2013 07:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] 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 7hNvUYMM4QhL; Fri, 15 Nov 2013 07:30:20 -0800 (PST) Received: from na3sys009aog133.obsmtp.com (na3sys009aog133.obsmtp.com [74.125.149.82]) by ietfa.amsl.com (Postfix) with ESMTP id A74CF11E81B2; Fri, 15 Nov 2013 07:30:06 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob133.postini.com ([74.125.148.12]) with SMTP ID DSNKUoY9/iTKn3vxalN+O+wEVKaORqdxRHyp@postini.com; Fri, 15 Nov 2013 07:30:19 PST Received: from MOPESMAILHC01.eu.thmulti.com (141.11.100.25) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.298.1; Fri, 15 Nov 2013 16:28:48 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.71]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Fri, 15 Nov 2013 16:28:56 +0100 From: Wuyts Carl To: Michael Richardson , Roberta Maglione Date: Fri, 15 Nov 2013 16:28:53 +0100 Thread-Topic: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation Thread-Index: Ac7iFQzTedOEoqYST2yAG9Ojk0ek1QAATBcQ Message-ID: <3135C2851EB6764BACEF35D8B495596806FB78DF8E@MOPESMBX01.eu.thmulti.com> References: <11836.1384276281@sandelman.ca> <3673.1384528283@sandelman.ca> In-Reply-To: <3673.1384528283@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 18 Nov 2013 05:18:14 -0800 Cc: "dhcwg@ietf.org WG" , "homenet@ietf.org" , "robmgl@cisco.com" , "radext@ietf.org" Subject: Re: [radext] [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 15:30:25 -0000 QWxsLCBzb21lIGZlZWRiYWNrIGZyb20gYSBDUEUtdmVuZG9yLCBmZWVsIGZyZWUgdG8gaWdub3Jl IG9mIGNvdXJzZS4NCg0KMS4gV2FuIGxpbmtzIGRvbid0IE5FRUQgZ2xvYmFsIElQIGFkZHJlc3Mu ICBUaGlzIHdpbGwgZGVwZW5kIG9uIGRpZmZlcmVudCBmYWN0b3JzIGFuZCB1c2VkIHByb3RvY29s cy4gIEUuZy4gYSBQUFAgZG9lcyBub3QgbmVlZCBhIGdsb2JhbCBJUCBmb3Igc3VyZSwgaG93ZXZl ciwgd2hhdCBpZiB5b3Ugd2FudCB0byBydW4gcmVtb3RlIG1hbmFnZW1lbnQgb24gaXQgdGhyb3Vn aCBJUHY2ID8gIEl0J3MgdmVyeSB1bmxpa2VseSB0byBiZSBvbiB0aGUgc2FtZSBsaW5rLCBoZW5j ZSBsaW5rLWxvY2FsIG1pZ2h0IG5vdCBiZSBzdWZmaWNpZW50Lg0KDQoyLiBpZiB0aGUgQ1BFIHNl bmRzIGFuIFJTLCB0aGUgQk5HIGRvZXNuJ3QgaGF2ZSB0byB0cmFuc2xhdGUgdGhpcyBhcyAicGxl YXNlIG51bWJlciBteSBsaW5rIiwgc3RyYW5nZSBhc3N1bXB0aW9uIEknZCBzYXkuDQoNCjMuIHRo ZSBzdGF0ZW1lbnQgICAiQWZ0ZXIgSVBWNkNQIG5lZ290aWF0aW9uLCB0aGUgQ1BFIGluaXRpYXRl cyBhIHByZWZpeCBkZWxlZ2F0aW9uIHJlcXVlc3QuIiAgbWFrZXMgc2Vuc2UgdGhhdCBESENQdjYg aXMgaW5kZWVkIHRoZSBsb2NhbCBuZXh0IHN0ZXAgYWZ0ZXIgUFBQIElQdjYgaXMgInVwIiwgaG93 ZXZlciwgcG90ZW50aWFsbHksIG1hbnVhbCBjb25maWcgaXMgcG9zc2libGUsIHNvIHRvIGhhdmUg dGhpcyAiYXV0b21hdGljYWxseScgaW4gcGxhY2UgbWlnaHQgYmUgdGhlIHdyb25nIGNvbmNsdXNp b24NCg0KNC4gdGhlIHN0YXRlbWVudCAiIEZ1cnRoZXIsIGlmIHRoZSBXQU4gbGluayBpcyBudW1i ZXJlZCBhcyBhIC82NCBmcm9tIHdpdGhpbiB0aGUgcHJlZml4IHRoYXQgKHdpbGwgYmUpIGRlbGVn YXRlZCwgdGhhdCBhbHNvIHdvdWxkIHNlZW0gdG8gbWFrZSB0aGUgQ1BFJ3MgZmlyZXdhbGwgZXZl biBtb3JlIGNvbXBsZXgsIHNvIEknZCByYXRoZXIgbnVtYmVyIGl0IG91dHNpZGUgdGhlIFBEIGlm IGl0IG5lZWRzIHRvIGJlIG51bWJlcmVkIGF0IGFsbC4iICBBZ3JlZSB0aGF0IGZpcmV3YWxsIGNv bmZpZyBtaWdodCBiZSBtb3JlIGRpZmZpY3VsdCwgYnV0IGRvbid0IGZvcmdldCB0aGF0IGl0IHNh dmVzIGFkZHJlc3Mgc3BhY2UgKywgbW9yZSBpbXBvcnRhbnQsIGluamVjdHMgbGVzcyBhZG1pbmlz dHJhdGlvbiBmb3IgdGhlIElTUCB0byBrZWVwIHRyYWNrIG9mIHByZWZpeGVzLg0KDQpSZWdzDQpD YXJsDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGhvbWVuZXQtYm91bmNl c0BpZXRmLm9yZyBbbWFpbHRvOmhvbWVuZXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IE1pY2hhZWwgUmljaGFyZHNvbg0KU2VudDogdnJpamRhZyAxNSBub3ZlbWJlciAyMDEzIDE2OjEx DQpUbzogUm9iZXJ0YSBNYWdsaW9uZQ0KQ2M6IGRoY3dnQGlldGYub3JnIFdHOyBob21lbmV0QGll dGYub3JnOyByb2JtZ2xAY2lzY28uY29tOyByYWRleHRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb aG9tZW5ldF0gW2RoY3dnXSBQUFAsIERIQ1B2NiBhbmQgUHJlZml4IERlbGVnYXRpb24NCg0KDQpU aGFuayB5b3UgZm9yIHRoZSB3cml0ZSB1cC4NCkl0J3MgY2xlYXIgdGhhdCB0aGVyZSBpcyBhIGdh cCwgd2hpY2ggVFItMTg3IGhhcyBmaWxsZWQuDQogICAgIGh0dHA6Ly93d3cuYnJvYWRiYW5kLWZv cnVtLm9yZy90ZWNobmljYWwvZG93bmxvYWQvVFItMTg3X0lzc3VlLTIucGRmDQoNClJGQzQyNDEg aXMgSW5mb3JtYXRpb25hbC4uLiB3aHkgZGlkbid0IFRSLTE4NyBjb21lIHRvIHRoZSBJRVRGIHRv IHN0YW5kYXJkaXplIDQyNDE/ICAoV2lsbCBUUi0xODcgZ2V0IHJlLWlzc3VlZCB3aXRoIHRoZSBy ZWZlcmVuY2UgdG8gYWNjZXNzLTE2IGNoYW5nZWQgdG8gUkZDNjkxMT8pDQoNCj09PQ0KSSB3YXMg d29uZGVyaW5nIHRoaXMgd2VlayB3aGV0aGVyIG9yIG5vdCB0aGUgV0FOIGxpbmsgbmVlZGVkIG90 aGVyIHRoYW4gbGluay1sb2NhbCBhZGRyZXNzZXMsIGFuZCBpdCBzZWVtcyB0byBtZSB0aGF0IHRo aXMgZGVwZW5kcyB2ZXJ5IG11Y2ggb24gd2hldGhlciBvciBub3QgdGhlIENQRSBpcyBnb2luZyB0 byBkbyBhbGwgb2YgNjIwNCBvciBub3QuDQoNCklmIGxpbmstbG9jYWwgaXMgZW5vdWdoLCB0aGVu IHRoZXJlIGlzIG5vIHJlYXNvbiB0byBkbyBSUy9SQSBvdmVyIHRoZSBXQU4gbGluayBhdCBhbGw6 IHN0YXRlbGVzcyBESENQdjYgdG8gZG8gUEQgaXMgZW5vdWdoLg0KDQpIb3cgY2FuIHRoZSBCTkcv Qk5BUyBrbm93IHdoYXQgd2lsbCBoYXBwZW4/ICAgSXMgaXQgcmVhc29uYWJsZSB0byBhc3N1bWUg dGhhdCB0aGUNCmlmIHRoZSBkZXZpY2UgZG9lcyBhIFJTIHRoYXQgaXQgZXhwZWN0cyB0aGUgSVNQ IHRvIG51bWJlciB0aGUgV0FOIGxpbmsgd2l0aCBhIGdsb2JhbCBhZGRyZXNzPw0KDQpUaGUgZG9j dW1lbnRzIGFsbCBzZWVtIHRvIHN1Z2dlc3QgdGhhdCB0aGUgSVNQIGlzIGdvaW5nIHRvIG1ha2Ug YSBwcm92aXNpb25pbmcgZGVjaXNpb24gYS1wcmlvcmkgYWJvdXQgdGhpcy4gIEFuZCB0aGlzIHNl ZW1zIHRvIGltcGx5IHRoYXQgYWxsIGN1c3RvbWVycyB3aWxsIGhhdmUgdG8gYmUgcHJvdmlzaW9u ZWQuLi4uIHdoaWxlIElQdjYgc3BhY2UgaXMgdmVyeSBsYXJnZSwgYmlnZ2VyIGFsbG9jYXRpb25z IGNvc3QgSVNQcyBtb3JlIG1vbmV5LCBhbmQgc28gdGhpcyBzdGlsbCBzZWVtcyBzaWxseS4NCg0K V2hpbGUgdGhlIGN1c3RvbWVyIGNhbiBiZSBwcm92aXNpb25lZCwgdGhlIGVuZCB1c2VyIG1heSB3 ZWxsIHN3YXAgQ1BFcyBpbiBhbmQgb3V0LCBhbmQgbWF5IGNvbm5lY3QgZGVza3RvcCBjb21wdXRl cnMgZGlyZWN0bHkgdG8gdGhlIERTTCBjb25uZWN0aW9uIGF0IHRpbWVzLCBzbyBtYWtpbmcgdGhl IElTUCBhbmQgdGhlIGVuZCB1c2VyIGFncmVlIGhlcmUgc2VlbXMgbGlrZSBhIHdheSB0byBndWFy YW50ZWUgdHJ1Y2sgcm9sbHMpDQoNClJGQzYyMDQgZG9lcyBub3QgKGFzIGZhciBhcyBJIGNhbiBz ZWUpIHN1Z2dlc3QgdGhhdCAodW4pbnVtYmVyaW5nIHRoZSBXQU4gbGluayBpcyBzb21ldGhpbmcg dGhlIENQRSBjYW4vc2hvdWxkIGRvLiAgUkZDNjIwNCBzYXlzOg0KICAgICBXLTM6ICBBYnNlbnQg b3RoZXIgcm91dGluZyBpbmZvcm1hdGlvbiwgdGhlIElQdjYgQ0Ugcm91dGVyIE1VU1QgdXNlDQog ICAgICAgICAgIFJvdXRlciBEaXNjb3ZlcnkgYXMgc3BlY2lmaWVkIGluIFtSRkM0ODYxXSB0byBk aXNjb3ZlciBhDQoNCnlldCwgUkZDNDI0MSBvbWl0cyBhIFJTL1JBIHBoYXNlIGluIHNlY3Rpb24g Mi4yLCB3aGljaCBzcGVjaWZpY2FsbHkgZ29lcw0KICAgICAgICBmcm9tIElQVjZDUCAobGluay1h ZGRyZXNzIG5lZ290aWF0aW9uKSB0byBwcmVmaXggZGVsZWdhdGlvbg0KDQogIDIuMi4gSVAgTGF5 ZXINCiAgICBBZnRlciBJUFY2Q1AgbmVnb3RpYXRpb24sIHRoZSBDUEUgaW5pdGlhdGVzIGEgcHJl Zml4IGRlbGVnYXRpb24NCiAgICByZXF1ZXN0Lg0KDQpUaGUgZGlhZ3JhbSBpbiBSRkM0MjQxLCBm aWd1cmUgMiBhbHNvIGNsZWFybHkgbGVhdmVzIG91dCBSUy9SQS4NCihJIHJlbWluZCB0aGF0IDQy NDEgaXMgSW5mb3JtYXRpb25hbCwgbm90IHN0YW5kYXJkcyB0cmFjaykNCg0KSWYgaXQgZG9lcyBQ RCwgdGhlbiB0aGUgQ1BFIGRldmljZSBjYW4gY2xlYXJseSB1c2UgYW4gYWRkcmVzcyBmcm9tIHRo ZSBkZWxlZ2F0ZWQgcHJlZml4IHRvIG9yaWdpbmF0ZSB0cmFmZmljIHRvIHRoZSBJbnRlcm5ldC4g NDI0MSBzdWdnZXN0cyBhc3NpZ25pbmcgdGhlICIwIiBzdWJuZXQgbmV0d29yayB0byB0aGUgcm91 dGVyJ3MgbG9vcGJhY2suDQoNCihJIG5vdGUgdGhhdCB0aGlzIGNvdWxkIG1ha2UgdGhlIENQRSdz IGZpcmV3YWxsIG1vcmUgY29tcGxleCwgYXMgb25lIGNhbiAgYXNzdW1lIHRoYXQgYWxsIFBELzU2 IHRyYWZmaWMgaXMgdG8gYmUgcHJvdGVjdGVkIGVxdWFsbHkuKQ0KDQpGdXJ0aGVyLCBpZiB0aGUg V0FOIGxpbmsgaXMgbnVtYmVyZWQgYXMgYSAvNjQgZnJvbSB3aXRoaW4gdGhlIHByZWZpeCB0aGF0 ICh3aWxsIGJlKSBkZWxlZ2F0ZWQsIHRoYXQgYWxzbyB3b3VsZCBzZWVtIHRvIG1ha2UgdGhlIENQ RSdzIGZpcmV3YWxsIGV2ZW4gbW9yZSBjb21wbGV4LCBzbyBJJ2QgcmF0aGVyIG51bWJlciBpdCBv dXRzaWRlIHRoZSBQRCBpZiBpdCBuZWVkcyB0byBiZSBudW1iZXJlZCBhdCBhbGwuDQoNCk1lYW53 aGlsZSwgVFItMTg3IHNheXMgdGhhdCBSb3V0ZSBBZHZlcnRpc2VtZW50cyBhcmUgZ2VuZXJhdGVk IGJ5IHRoZSBCTkcuDQooc2VjdGlvbiA1LjINCg0KYW5kIHNheXM6DQogICAgV2hlbmV2ZXIgdGhl IEZyYW1lZC1JUHY2LVByZWZpeCBhdHRyaWJ1dGUgaXMgcmV0dXJuZWQgZnJvbSBSQURJVVMsIHRo ZQ0KICAgIEJORyBpbmNsdWRlcyB0aGlzIHByZWZpeCBhcyBPbi1MaW5rIGFuZCBBdXRvbm9tb3Vz IGluIHRoZSBSb3V0ZXINCiAgICBBZHZlcnRpc2VtZW50IFByZWZpeCBJbmZvcm1hdGlvbiBPcHRp b24uIElmIHRoaXMgYXR0cmlidXRlIGlzIG9taXR0ZWQsDQogICAgdGhlIEJORyB3aWxsIG5vdCBz ZW5kIGEgUHJlZml4IEluZm9ybWF0aW9uIE9wdGlvbi4gREhDUHY2IGlzIHVzZWQgdG8gZGVsZWdh dGUgcHJlZml4ZXMuDQoNCnNvIHRoaXMgaXMgZXhhY3RseSBpbmxpbmUgd2l0aCB3aGF0IEkgaGFk IGNvbmNsdWRlZDogbnVtYmVyIHRoZSBsaW5rIGlmIHByb3Zpc2lvbmVkIHRvIGRvIHNvLCBsZWF2 ZSBpdCB1bm51bWJlcmVkIG90aGVyd2lzZS4NCg0KSGFzIHRoaXMgd29ya2VkIHdlbGwgaW4gdGhl IGZpZWxkPw0KDQpzZWN0aW9uIDUuMy4xIHN1Z2dlc3RzIHRoYXQgdGhlIGRlbGVnYXRlZCBwcmVm aXggYmUgcmV0dXJuZWQgZHVyaW5nIHRoZSBpbml0aWFsIGNvbW11bmljYXRpb24gd2l0aCB0aGUg cmFkaXVzIHNlcnZlci4gIFRoaXMgaXMgZ3JlYXQgZm9yIHByZS1wcm92aXNpb25lZCBzeXN0ZW1z LCBidXQgc2VlbXMgdG8gcHJlbWVkaXRhdGUgdGhlIHNpemUgb2YgcHJlZml4ZXMgdGhhdCBjdXN0 b21lcnMgd2lsbCBnZXQsIHJlZ2FyZGxlc3Mgb2Ygd2hhdCB0aGV5IHB1dCBpbnRvIHRoZWlyIERI Q1B2NiBQRCByZXF1ZXN0Lg0KDQpJdCBhbHNvIGltcGxpZXMgdGhhdCBldmVyeSBjdXN0b21lciwg ZXZlbiB0aG9zZSBub3QgeWV0IElQdjYgcmVhZHksIGFyZSBnb2luZyB0byBnZXQgSVB2NiBwcmVm aXhlcyBkZWxlZ2F0ZWQgdG8gdGhlbSwgYXMgdGhlIHZhcmlvdXMgSVB2NiByYWRpdXMgYXR0cmli dXRlcyBhcmUgcmV0dXJuZWQgZHVyaW5nIFBQUCBMQ1AgcGhhc2UsIGFuZCBiZWZvcmUgb25lIGhh cyBhbnkgaWRlYSB0aGF0IHRoZSBjdXN0b21lciBpcyB2NiBjYXBhYmxlLiAgSXQgYWxzbyBwcmV2 ZW50cyB0aGUgQ1BFIGZyb20gdHVybmluZyBvbiBJUHY2IGxhdGVyIG9uIHdpdGhvdXQgY3ljbGlu ZyB0aGUgUFBQIGNvbm5lY3Rpb24uDQoNCkkgdGhpbmsgaXQgd291bGQgYmUgYmV0dGVyIHRvIG9t aXQgdGhhdCBvbiB0aGUgZmlyc3QgY29ubmVjdGlvbiwgYW5kIHBlcm1pdCB0aGUgYWxsb2NhdGlv biB0byBiZSBkcml2ZW4gYnkgdGhlIGFjdHVhbCBESENQdjYuICBSRkM2OTExIG91dGxpbmVzIHRo ZSBhdHRyaWJ1dGVzIHRvIGJlIHVzZWQsIGJ1dCBpdCBpc24ndCBjbGVhciB0byBtZSB0aGF0IHRo ZXkgaGF2ZSB0byBiZSBkb25lIGF0IFBQUCBMQ1AgdGltZS4NCg0KSXQgc2VlbXMgdGhhdCBUUi0x ODcsIGluIHJlcXVpcmVtZW50IFItMjIsIChzZWN0aW9uIDkpLCBpcyBzdWdnZXN0aW5nIHRoYXQN Ci8xMjggYWRkcmVzc2VzIGJlIGdpdmVuIG91dCB2aWEgc3RhdGVmdWwgREhDUHY2LiAgQnV0IFIt Mjkgc2F5cyAvNjQgZm9yIFNMQUFDLg0KDQoNClJvYmVydGEgTWFnbGlvbmUgPHJvYm1nbC5pZXRm QGdtYWlsLmNvbT4gd3JvdGU6DQogICAgPiBCYXNpY2FsbHkgYWxsIHRoZSBwYXJhbWV0ZXJzIHJl cXVpcmVkIHRvIGNvbmZpZ3VyZSB0aGUgUkcgY2FuIGJlIHNlbnQNCiAgICA+IGJ5IHRoZSBSQURJ VVMgU2VydmVyIHRvIHRoZSBCTkcgKFJBRElVUyBjbGllbnQpIGluIHRoZSBBY2Nlc3MtQWNjZXB0 DQogICAgPiBkdXJpbmcgdGhlIGF1dGhlbnRpY2F0aW9uIHBoYXNlIGFuZCB0aGVuIHRoZSBCTkcg KGFjdGluZyBhcyBESENQdjYNCiAgICA+IFNlcnZlcikgY2FuIHVzZSB0aGVtIHRvIG51bWJlciB0 aGUgV2FuIGxpbmsgYW5kIGRlbGVnYXRlIGFuIElQdjYgcHJlZml4DQogICAgPiB0byB0aGUgaG9t ZSBuZXR3b3JrLg0KDQpZZXMsICB0aGUgZGVsZWdhdGVkIHByZWZpeCBjb3VsZCBiZSBpbiB0aGUg aW5pdGlhbCBBY2Nlc3MtQWNjZXB0LCBhbmQgdGhpcyBpcyBlYXN5IHRvIGRvIGlmIHRoZSBwcmVm aXhlcyBhcmUgYWxsIHN0YXRpY2FsbHkgcHJvdmlzaW9uZWQuICBUaGVyZSBhcmUgcmFkaXVzIHNl cnZlcnMgdGhhdCBjYW4gZG8gZHluYW1pYyBhbGxvY2F0aW9uLCBidXQgdGhlIGJpZ2dlciBpc3N1 ZSBJJ20gY29uY2VybmVkIGFib3V0IGlzIHRoYXQgdGhlIGFsbG9jYXRpb24gbWF5IG5vdCBiZSBh YmxlIHRvIHJlZmxlY3Qgd2hhdCB0aGUgQ1BFIHdpbGwgYWN0dWFsbHkgYXNrIGZvci4NCg0KICAg ID4gUGxlYXNlIHRha2UgYSBsb29rIGF0IFRSLTE4NyBpc3N1ZTIgZnJvbSBCQkYNCg0KICAgID4g aHR0cDovL3d3dy5icm9hZGJhbmQtZm9ydW0ub3JnL3RlY2huaWNhbC9kb3dubG9hZC9UUi0xODdf SXNzdWUtMi5wZGYNCg0KVGhhbmsgeW91IHRoaXMgZG9jdW1lbnQgaXMgdXNlZnVsLiAgSSdkIGxp a2UgdG8gYXNrIHRoYXQgc29tZSBob21lbmV0IGRvY3VtZW50IGNpdGUgaXQuDQoNCiAgICBtY3I+ IMKgYW5kIFJGQyA0MjQxIGZvcsKgIG1vcmUgZGV0YWlscyBvbiB0aGUgYXJjaGl0ZWN0dXJhbCBt b2RlbC4gwqANCg0KICAgIG1jcj4gICAgIE9yLCBpZiB0aGUgcmFkaXVzIHNlcnZlciBoYWQgcmV0 dXJuZWQgc29tZSBraW5kIG9mIHNlc3Npb24gSUQgdG8NCiAgICBtY3I+IHRoZSBwcHAsIGl0IGNv dWxkIGNvbW11bmljYXRlIHRoYXQgdG8gYSBjby1sb2NhdGVkIERIQ1B2NiBzZXJ2ZXIgKG9yDQog ICAgbWNyPiByZWxheSkgdG8gaW5jbHVkZSBpbiB0aGUgcmVxdWVzdC4NCg0KSSBoYXZlIGJlZW4g cmVtaW5kZWQgb2YgdGhlIHJhZGl1cyBTdGF0ZSBhdHRyaWJ1dGUgd2hpY2ggaXMgY29tbW9ubHkg dXNlZC4NCg0KLS0NCl0gICAgICAgICAgICAgICBOZXZlciB0ZWxsIG1lIHRoZSBvZGRzISAgICAg ICAgICAgICAgICAgfCBpcHY2IG1lc2ggbmV0d29ya3MgWw0KXSAgIE1pY2hhZWwgUmljaGFyZHNv biwgU2FuZGVsbWFuIFNvZnR3YXJlIFdvcmtzICAgICAgICB8IG5ldHdvcmsgYXJjaGl0ZWN0ICBb DQpdICAgICBtY3JAc2FuZGVsbWFuLmNhICBodHRwOi8vd3d3LnNhbmRlbG1hbi5jYS8gICAgICAg IHwgICBydWJ5IG9uIHJhaWxzICAgIFsNCg0KDQotLQ0KTWljaGFlbCBSaWNoYXJkc29uIDxtY3Ir SUVURkBzYW5kZWxtYW4uY2E+LCBTYW5kZWxtYW4gU29mdHdhcmUgV29ya3MNCg0KDQo= From robmgl.ietf@gmail.com Fri Nov 15 10:32:49 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B7211E8234; Fri, 15 Nov 2013 10:32:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.349 X-Spam-Level: X-Spam-Status: No, score=-1.349 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, NO_RELAYS=-0.001] 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 pdGOri28Zi8O; Fri, 15 Nov 2013 10:32:47 -0800 (PST) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) by ietfa.amsl.com (Postfix) with ESMTP id D1F7211E8152; Fri, 15 Nov 2013 10:32:45 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id q8so1832722lbi.12 for ; Fri, 15 Nov 2013 10:32:44 -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=Hqh30GkOYDERXH0bYNYgB58UYk11X7tq5dFzY6D75x8=; b=e1m819OPJbd27g8pwdK9Fcb2DVjjQoLoS94VQbkCy2BmNsrFyZn+YJAWHxaqgoBbBP OQu1kVGJTxEEbPGIrQWbFft6zXOEbIb0gCT5v+6MPpEzRNKsEHWgmHaVH79IPQeetkkg H/cy09H5D6UOOOSfx9JtyNE1cRfV7Pzb42J3JiBqSQonjVz7fIIgpH0YHgFBPoZ2e92v ka8AsoWu2HmbS1xLZIhOcIBTDY6slih03Jb6Mp1c9JI/fpHkvWH1B4Azcf3igp7mtgei SF6hD63q7fmNP0JJdsC4Az4M0wXxKi67YsMMd2LUOvFwA0VPOmyHYSoE0nyXJUD0LyK2 xoCQ== MIME-Version: 1.0 X-Received: by 10.112.167.3 with SMTP id zk3mr4701210lbb.23.1384540364346; Fri, 15 Nov 2013 10:32:44 -0800 (PST) Received: by 10.112.159.3 with HTTP; Fri, 15 Nov 2013 10:32:44 -0800 (PST) In-Reply-To: <3135C2851EB6764BACEF35D8B495596806FB78DF8E@MOPESMBX01.eu.thmulti.com> References: <11836.1384276281@sandelman.ca> <3673.1384528283@sandelman.ca> <3135C2851EB6764BACEF35D8B495596806FB78DF8E@MOPESMBX01.eu.thmulti.com> Date: Fri, 15 Nov 2013 13:32:44 -0500 Message-ID: From: Roberta Maglione To: Wuyts Carl Content-Type: multipart/alternative; boundary=001a11c264a4981b7f04eb3b6c56 X-Mailman-Approved-At: Mon, 18 Nov 2013 05:18:09 -0800 Cc: Michael Richardson , "homenet@ietf.org" , "robmgl@cisco.com" , "radext@ietf.org" , "dhcwg@ietf.org WG" Subject: Re: [radext] [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 18:32:49 -0000 --001a11c264a4981b7f04eb3b6c56 Content-Type: text/plain; charset=ISO-8859-1 Please see comments inline [RM] Thanks Roberta On Fri, Nov 15, 2013 at 10:28 AM, Wuyts Carl wrote: > 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. > [RM] agree. Remote management was one of the use cases brought up at the BBF in order to support the numbered model. Somebody argued saying that you could leave the WAN unnumbered and use the loopback with a prefix taking by the delegated prefix, but some operators prefer to have a separate single IPv6 prefix for managing all the RG's. > > 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. > [RM] As I mentioned in my other email if you want to use an IPv6 prefix from the delegate prefix you would need to use prefix exclude option RFC 6603. I agree with you that you would save address space but this model may not be optimal for the operators that would like to have the management interface of all the RG's in the same IPv6 prefix in order to reduce/simplify the number of ACL's that they would need to add in the network to restrict the access to the management systems. Thanks Roberta > Regs > Carl > > > -----Original Message----- > From: homenet-bounces@ietf.org [mailto:homenet-bounces@ietf.org] On > Behalf Of Michael Richardson > Sent: vrijdag 15 november 2013 16:11 > To: Roberta Maglione > Cc: dhcwg@ietf.org WG; homenet@ietf.org; robmgl@cisco.com; radext@ietf.org > 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 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 , Sandelman Software Works > > > --001a11c264a4981b7f04eb3b6c56 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Please see comments inline [RM]=
Thanks
Rob= erta

On Fri, Nov 15, 2013 at 10:28 = AM, Wuyts Carl <Carl.Wuyts@technicolor.com> wrote:<= br>
All, some feedback from a CPE-vendor, feel free to ignore = of course.

1. Wan links don't NEED global IP address. =A0This will depend on diffe= rent factors and used protocols. =A0E.g. a PPP does not need a global IP fo= r sure, however, what if you want to run remote management on it through IP= v6 ? =A0It's very unlikely to be on the same link, hence link-local mig= ht not be sufficient.
[RM] agree. Remote management was one of the use cases=A0= brought up at the BBF in order to support the numbered model. Somebody argu= ed saying that you could leave the WAN unnumbered and=A0use the loopback wi= th a prefix taking by the delegated prefix, but=A0some operators prefer to = have a separate single IPv6 prefix for managing=A0all the RG's.
=A0=A0=A0

2. if the CPE sends an RS, the BNG doesn't have to translate this as &q= uot;please number my link", strange assumption I'd say.

3. the statement =A0 "After IPV6CP negotiation, the CPE initiates a pr= efix delegation request." =A0makes sense that DHCPv6 is indeed the loc= al next step after PPP IPv6 is "up", however, potentially, manual= config is possible, so to have this "automatically' in place migh= t 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 th= e CPE's firewall even more complex, so I'd rather number it outside= the PD if it needs to be numbered at all." =A0Agree that firewall con= fig might be more difficult, but don't forget that it saves address spa= ce +, more important, injects less administration for the ISP to keep track= of prefixes.
[RM] As I mentioned in my other email if you want to use = an IPv6=A0prefix from the delegate prefix you would need to use prefix excl= ude option RFC 6603. I agree with you that you would save address space but= this model may not be optimal for the operators that would like to have=A0= the management interface of=A0all the RG's in the same IPv6 prefix in o= rder to reduce/simplify the number of ACL's that they would need to add= in the network to restrict the access to the management systems.=A0
=A0
Thanks
Roberta
=A0
Regs
Carl


-----Original Message-----
From: homenet-bounces@ietf.org<= /a> [mailto:homenet-bounces@iet= f.org] On Behalf Of Michael Richardson
Sent: vrijdag 15 november 2013 16:11
To: Roberta Maglione
Cc: dhcwg@ietf.org WG; homenet@ietf.org; robmgl@cisco.com; radext@ietf.o= rg
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.
=A0 =A0 =A0http://www.broadband-forum.org/technical= /download/TR-187_Issue-2.pdf

RFC4241 is Informational... why didn't TR-187 come to the IETF to stand= ardize 4241? =A0(Will TR-187 get re-issued with the reference to access-16 = changed to RFC6911?)

=3D=3D=3D
I was wondering this week whether or not the WAN link needed other than lin= k-local addresses, and it seems to me that this depends very much on whethe= r 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 l= ink at all: stateless DHCPv6 to do PD is enough.

How can the BNG/BNAS know what will happen? =A0 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 provision= ing decision a-priori about this. =A0And this seems to imply that all custo= mers 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 a= nd 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 g= uarantee truck rolls)

RFC6204 does not (as far as I can see) suggest that (un)numbering the WAN l= ink is something the CPE can/should do. =A0RFC6204 says:
=A0 =A0 =A0W-3: =A0Absent other routing information, the IPv6 CE router MUS= T use
=A0 =A0 =A0 =A0 =A0 =A0Router Discovery as specified in [RFC4861] to discov= er a

yet, RFC4241 omits a RS/RA phase in section 2.2, which specifically goes =A0 =A0 =A0 =A0 from IPV6CP (link-address negotiation) to prefix delegation=

=A0 2.2. IP Layer
=A0 =A0 After IPV6CP negotiation, the CPE initiates a prefix delegation
=A0 =A0 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 dele= gated 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 ca= n =A0assume 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 eve= n more complex, so I'd rather number it outside the PD if it needs to b= e numbered at all.

Meanwhile, TR-187 says that Route Advertisements are generated by the BNG.<= br> (section 5.2

and says:
=A0 =A0 Whenever the Framed-IPv6-Prefix attribute is returned from RADIUS, = the
=A0 =A0 BNG includes this prefix as On-Link and Autonomous in the Router =A0 =A0 Advertisement Prefix Information Option. If this attribute is omitt= ed,
=A0 =A0 the BNG will not send a Prefix Information Option. DHCPv6 is used t= o delegate prefixes.

so this is exactly inline with what I had concluded: number the link if pro= visioned 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 ini= tial communication with the radius server. =A0This is great for pre-provisi= oned 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 goi= ng to get IPv6 prefixes delegated to them, as the various IPv6 radius attri= butes are returned during PPP LCP phase, and before one has any idea that t= he customer is v6 capable. =A0It 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. =A0RFC6911 outlines the = attributes to be used, but it isn't clear to me that they have to be do= ne at PPP LCP time.

It seems that TR-187, in requirement R-22, (section 9), is suggesting that<= br> /128 addresses be given out via stateful DHCPv6. =A0But R-29 says /64 for S= LAAC.


Roberta Maglione <robmgl.ietf@g= mail.com> wrote:
=A0 =A0 > Basically all the parameters required to configure the RG can = be sent
=A0 =A0 > by the RADIUS Server to the BNG (RADIUS client) in the Access-= Accept
=A0 =A0 > during the authentication phase and then the BNG (acting as DH= CPv6
=A0 =A0 > Server) can use them to number the Wan link and delegate an IP= v6 prefix
=A0 =A0 > to the home network.

Yes, =A0the delegated prefix could be in the initial Access-Accept, and thi= s is easy to do if the prefixes are all statically provisioned. =A0There ar= e 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 t= he CPE will actually ask for.

=A0 =A0 > Please take a look at TR-187 issue2 from BBF

=A0 =A0 > http://www.broadband-forum.org/technic= al/download/TR-187_Issue-2.pdf

Thank you this document is useful. =A0I'd like to ask that some homenet= document cite it.

=A0 =A0 mcr> =A0and RFC 4241 for=A0 more details on the architectural mo= del. =A0

=A0 =A0 mcr> =A0 =A0 Or, if the radius server had returned some kind of = session ID to
=A0 =A0 mcr> the ppp, it could communicate that to a co-located DHCPv6 s= erver (or
=A0 =A0 mcr> relay) to include in the request.

I have been reminded of the radius State attribute which is commonly used.<= br>
--
] =A0 =A0 =A0 =A0 =A0 =A0 =A0 Never tell me the odds! =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 | ipv6 mesh networks [
] =A0 Michael Richardson, Sandelman Software Works =A0 =A0 =A0 =A0| network= architect =A0[
] =A0 =A0 mcr@sandelman.ca =A0http://www.sandelman.ca/<= /a> =A0 =A0 =A0 =A0| =A0 ruby on rails =A0 =A0[


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



--001a11c264a4981b7f04eb3b6c56-- From aduitsis@gmail.com Fri Nov 15 12:59:16 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AEC611E8128; Fri, 15 Nov 2013 12:59:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 MrGa3BdxW3kW; Fri, 15 Nov 2013 12:59:16 -0800 (PST) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id D703311E80E0; Fri, 15 Nov 2013 12:59:06 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id to1so5523409ieb.31 for ; Fri, 15 Nov 2013 12:59:06 -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=X0vyp2gv5+/JZO9r+oesbEI4+JWfDs6JyIy7OT46spI=; b=oRB/SukqdLtY8aukdDeHQq7UKPXPESlc6uP16Sqt2nf7j/p5amwtmqsiyozFNIfYQc Gi4vWv2Z1B2nw8mtjZY19x/TQMlz/dQ3ZNADQeOiZtQXbHc8VRbwcfU8vIiucT+FaH/X DrcE2msNpeEpTXCBsxYEoyC65SpvvocgavbHdWtVwSRVlj4bDq6RUXGy4SiUYEtiyNsJ +9RHESVDm5J4DmOH7EBz/MhpwDuHo8IBQDkRButmEPeRj5cYYDWHRIGYTUjl40lT9dfo ebfoG2PPbffswPX2CMRRGT5XySoHgzGgbz3Y2gVwdRoO9z5YUk0MsNokFj6cD0EpkY0O J2gg== MIME-Version: 1.0 X-Received: by 10.50.30.229 with SMTP id v5mr5822474igh.27.1384549146465; Fri, 15 Nov 2013 12:59:06 -0800 (PST) Received: by 10.64.227.168 with HTTP; Fri, 15 Nov 2013 12:59:06 -0800 (PST) In-Reply-To: References: <11836.1384276281@sandelman.ca> <3673.1384528283@sandelman.ca> Date: Fri, 15 Nov 2013 22:59:06 +0200 Message-ID: From: Athanasios Douitsis To: Roberta Maglione Content-Type: multipart/alternative; boundary=047d7bacc30c0c9f2404eb3d785b X-Mailman-Approved-At: Mon, 18 Nov 2013 05:18:12 -0800 Cc: Michael Richardson , homenet@ietf.org, robmgl@cisco.com, radext@ietf.org, "dhcwg@ietf.org WG" Subject: Re: [radext] [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Nov 2013 20:59:16 -0000 --047d7bacc30c0c9f2404eb3d785b Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 15, 2013 at 7:57 PM, Roberta Maglione wrote: > 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. Hello, Shouldn't there also be a Prefix Exclude Option RADIUS attribute? I can imagine that the delegating router vendor could very well use the Framed-IPv6-Prefix with a different set of semantics (i.e. have a configuration option to use the Framed-IPv6-Prefix value in the prefix exclude option instead of an RA), but a separate RADIUS attribute would be more appropriate. Kind regards, -- Athanasios Douitsis --047d7bacc30c0c9f2404eb3d785b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Fri, Nov 15, 2013 at 7:57 PM, Roberta Maglione <robmgl.ietf@gmail.c= om> wrote:
More recently RFC 6603 about Prefix exclude = was published so today you could theoretically do that if you use prefix ex= clude option, but I'm not sure how much this model has been adopted. It= is referenced in =A0draft-ietf-v6ops-6204bis WPD-8.

Hello,

Shouldn't there also be a Prefix Exclude Option RADIUS= attribute? I can imagine that the delegating router vendor could very well= use the Framed-IPv6-Prefix with a different set of semantics (i.e. have a = configuration option to use the Framed-IPv6-Prefix value in the prefix excl= ude option instead of an RA), but a separate RADIUS attribute would be more= appropriate.=A0

Kind regards,
--
Athanasios Douitsis


--047d7bacc30c0c9f2404eb3d785b-- From ben@nostrum.com Mon Nov 18 15:39:17 2013 Return-Path: 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 917E01AE70E; Mon, 18 Nov 2013 15:39:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.664 X-Spam-Level: ** X-Spam-Status: No, score=2.664 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MANGLED_LIST=2.3] 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 nmwV6rBX9vwk; Mon, 18 Nov 2013 15:39:13 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 27EE51AE717; Mon, 18 Nov 2013 15:39:13 -0800 (PST) Received: from [172.20.10.7] (mobile-166-147-068-167.mycingular.net [166.147.68.167]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rAINd0DW092027 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Nov 2013 17:39:05 -0600 (CST) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Nov 2013 17:38:56 -0600 Message-Id: To: draft-ietf-radext-dtls.all@tools.ietf.org, radext@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 166.147.68.167 is authenticated by a trusted mechanism) X-Mailman-Approved-At: Tue, 19 Nov 2013 02:20:15 -0800 Cc: "gen-art@ietf.org Team \(gen-art@ietf.org\)" Subject: [radext] Gen-Art Early Review of draft-ietf-radext-dtls-07 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 23:39:17 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . This is an early review at WGLC last call. Document: draft-ietf-radext-dtls-07 Reviewer: Ben Campbell Review Date: 2013-11-18 Summary: This draft is on the right track, but there are significant = open issues that should be resolved before it progresses. [Note: This review is different from the usual Gen-ART review due to the = fact that it's an early (as in prior to pubreq) review, and that the = draft is intended to become an experimental RFC. The gen-ART review = process is tuned for drafts at IETF last call or later. It's a little = hard to figure out what criteria should be used for drafts at an earlier = point in the life-cycle. That being said, I reviewed this as if it were = near-final, and apologize if that turns out to be too strict for an = early review. I used similar review criteria as I would for a standards-track draft, = since this draft still specifies protocol with the hope of interoperable = implementations. The only difference comes from a few comments = explicitly about the experimental status of the draft.] *** Major issues: -- General: The draft needs an overhaul of it's use of normative language. There = appears to be redundant (and possibly contradictory) language for the = same requirements sprinkled throughout. There are also cases of = normative language being used for internal implementation guidance, = which is not appropriate as described by RFC 2119. (See the minor issues = section for details--most of the instances would not qualify as major = issues by themselves, but I think they constitute a major issue in the = aggregate.) -- section 3, 2nd paragraph: "... long-term use of RADIUS/UDP is NOT = RECOMMENDED."=20 While I agree with the sentiment, that's not an appropriate assertion = for an experimental RFC. It would either need to go into an = standards-track update to the RADIUS spec, or a BCP. (Also applies to the reiteration in 10.1) *** Minor issues: -- General: It might be worth some text on why this is experimental = rather than informational. Is there any plan to evaluate the = implementation results? Is there an expectation that a future = RADIUS/DTLS spec could become standards-track? Is there any plan to = evaluate the outcome of this document? -- Section 1, 2nd paragraph: Isn't this true for almost any use of IPSec? Is there some specific = reason this is worse for RADIUS than for other protocols? -- Section 1, 4th paragraph: The second sentence mentions that firewall rules do not need to be = changed. The following sentence recommends a change to firewall rules. The firewall rule recommendations in the 3rd sentence seems odd, since = it seems like any protocol over DTLS would pass. Also, does this imply a = recommendation that firewalls with DPI be used in the first place, since = the absence of such a firewall has the same effect as having one that = doesn't enforce the protocol? (Is there a reason a protocol spec should = recommend firewall rules in the first place, other than to mention = places where certain firewall rules might prevent interfere with = operation?) -- section 2.1, 5th paragraph (3rd paragraph after bullet list) : = "Implementations MUST support encapsulated RADIUS packets of 4096 in = length..." Please be more precise than "MUST support". Specifically, does "MUST = support" indicate you must support both sending and receiving of that = size? (since 4096 would generally exceed PMTU even for RADIUS/UDP) -- 2.2 and children: I find this section confusing as to where to find the authoritative = text. Some, but not all, of the material from 6614 is repeated as = normative text in later sections. The description of this draft as = applying 'semantic "patches"' to 6614 seems to imply you mean the 6114 = text, with these patches applied, to be normative, which creates some = potential conflicts. If, on the other hand, 2.2 (.x) is intended more as = a informative description of the differences, please say so. -- 3, 1st paragraph: Can you elaborate on the resulting "timeouts, lost traffic, and network = instabilities"? -- 3.1:=20 The section describes UDP/2083 as the "default port". But later sections = describe port related behavior in a way that makes it it look like the = impementations must always use 2083, which makes it more than just a = default. Is the administrator allowed to choose some other port for any = reason? If so, it might make more sense to refer to the port by role = rather than number when discussing port related behavior. (I note that = 6614 only mentions the port number in the initial assignment, the IANA = considerations, and the appendix.) -- 3.2, last paragraph: Can you elaborate on the bid down attack? Given that the use of dtls is = configured, rather than negotiated, how would an attacker bid it down? -- 4, 2nd paragraph: Seems like an (or maybe even the) important point would be that a client = should not fall back to cleartext if a server appears to not support it. -4, 3rd paragraph: Is the recommendation to use a local proxy for all clients, or just = those implemented as multiple processes? -- 5.1.1, third paragraph: "In those cases, the implementation MAY = delete the underlying session" Can you elaborate on why that's a MAY and not a SHOULD or MUST? -- 5.1.1, 4th paragraph: This paragraph rephrases 2119 normative language with more normative = language. That creates confusion about which text is authoritative. I = suggest either keeping the second paragraph and deleting the first, or = make the second non-normative. -- 5.1.1, 6th paragraph: "The timestamp SHOULD be updated ..." Why not MUST? -- 5.1.1, 7th paragraph: Is the "idle time" configurable setting on a per peer or global basis? -- 5.1.1, 8th paragraph: What does it mean to "track" sessions? Also, it seems like the "SHOULD = stop creating" guidance contradicts later guidance that least recently = used sessions might get dropped instead? -- 5.1.1, 10th paragraph: =20 Should the second sentence contain a normative MUST? Also, the 2nd and 3rd sentences taken together seem say "the server must = keep the session open until it decides not to"=20 How would an unauthenticated client close an active DTLS session? -- 5.2, 1st paragraph: The normative requirement for a client to use heartbeats _or_ the = application level watchdog algorithm seems to contradict the normative = guidance that a server SHOULD use both. -- 5.2, 3rd paragraph, 1st sentence: I would hesitate to phrase this that a client may violate the previous = normative SHOULDs. It would be better to phrase this as describing th = econsequences should the client ignore the SHOULD. -- 5.2, 2nd to last paragraph: Does this have actual interop or security issues beyond saying, "it's = harder to implement and you might screw it up"? If not, it seems counter = to the 2119 guidance on when normative language is appropriate. It would = be more properly non-normative implementation guidance. -- 6, 1st paragraph: You mention that these are implementation guidelines, and not part of = the protocol. But the section contains 2119 style normative = requirements. in general, that's not appropriate unless non-compliance = impact interoperability or create some other Bad Thing, such as insecure = behavior, excessive bandwidth usage, congestion, etc. Implementation = guidance for behavior that is not externally observable should use = non-normative. -- 6, 2nd and 3rd paragraph: The RECOMMENDation to allow administrative entry of keys and to derive = keys from a PRNG seem contradictory. -- 6.1, 1st paragraph: Does the guidance to use connected sockets remove previous normative = requirements about session management and tracking? If not, please = indicate the difference. -- 6.1, 3rd paragraph: This seems to assume that all radius clients are implementd as multiple = processes. Is that the intent? Also, it's better not to use normative requirements for internal = implementation choices. Describe the externally visible behavior = normatively. You can give implementation advice in the form of example = strategies to fulfill the black-box normative requirements. -- 9 Why not choose a new port? Is there absolute certainty this won't = conflict with the previous usage? I do note that 6414 made the same = choice, so I guess consistency with radius/TLS has some value. But that = draft talks about compatibility between radsec and radius/tls, which is = not mentioned here. -- 10, last paragraph: You describe the use of null crypto as an implementation or = configuration error. Was it intended to be forbidden from intentional = use? Is there a need to remove the fixed secret requirement for null = crypto, or to disallow null crypto entirely? -- 10.1, 3rd paragraph: It would be helpful to have guidance on how to match a certificate to a = client or server identity, how to configure trust for a self-signed = cert, etc. -- 10.1, 4th paragraph:=20 -- 10.1, last paragraph: Why does the historic use of shared secrets matter, since this document = requires all implementations to use a fixed value? Or do you mean the = use of poor secrets as PSKs? -- 10.2, 2nd paragraph: This is redundant with previous normative requirements. (Also = contradictory, since the previous text said "SHOULD", and contradictory = guidance on what to do when the limit is exceeded.) -- 10.3, 4th paragraph: Does this need to be as strong as SHOULD? Is this likely to conflict = with dynamic discovery, should it ever exist? -- 10.3, 5th and 6th paragraphs: Paragraph 5 says credentials should be statically configured. To me, = "credentials" means "the certificate" in this case. That seems to = disallow things like statically configuring a name that must match a = certificate (perhaps signed by a CA.) Paragraph 6 seems to entirely contradict paragraph 5 by recommending = private CAs, and accepting any peer that presents a cert signed by that = CA. That's pretty much the opposite of statically configured = credentials. (Paragraph 8 also seems to contradict the static = configuration part.) The last sentence refers to "the invalid server". What invalid server is = that? None have been mentioned so far. -- 10.4: The guidance in the last paragraph does not make sense. The section = seems to say that NATs will break radius/dtls, so you should use dtls = when behind a NAT. -- 10.6, last paragraph: Can you elaborate on this? Why would an unauthorized 3rd party be able = to get packets past the DTLS layer? OTOH, If an authorized client is = sending invalid radius packets, wouldn't you want to terminate the = session? -- 10.7 Redundant normative requirements (This is at least the third time the = separate process issue and local proxy guidance has been described.) *** Nits/editorial comments: -- IDNits reports some issues; please check. -- Abstract: Please avoid citations in the abstract. Please consider removing the = "scare quotes". -- Section 1, 5th paragraph: it seems like the RADIUS problems that this does not solve are in = generally solved by RADIUS/TLS. If so, it would probably be worth a = mention. -- section 2.1, 4th paragraph from end:=20 Seems like there are other changes as well. For example, you don't = include "Use DTLS" as one of the changes in RADIUS/DTLS from RADIUS/USP. -- 2.2 and children: In my strictly personal opinion, the approach of patching 6614 transfers = a lot of effort from the author to the reader. A reader will basically = need to keep both docs open side by side to understand this. I = understand the desire to avoid duplicating normative text, but I think = that the balance here has swung too far away from readability. (OTOH, = see my related comment under "minor issues). -- 2.2.1, paragraph 5: should TLS parameters be DTLS parameters? -- 2.2.2: Why a separate section to say sections 4 and 6 also apply? (The = re-iteration seems unneeded.) -- 3.1, last sentence: Really, 2.2.1 doesn't describe that. 6114 describes that. Better to cite = the source than to cite a citation to the source, especially when that = citation doesn't mention the issues at all. -- 4, 3rd paragraph: Do you really mean multiple independent _implementations_? Or multiple = independent instances or processes, perhaps running the same = implementation? -- section 5 and children: In consistent use of "connection" vs "session". -- 5.1.1, 2nd paragraph: What is an "entry" session? -- 6.1, 2nd paragraph: Source port? Source address? Both? -- 7: Only the first paragraph seems to be about implementation experience. -- 10, 2nd paragraph: "All of the security considerations for RADIUS = apply to the RADIUS portion of the specification." The next paragraph seems to contradict this. -- 10.3, 2nd paragraph: "... a client has a fixed IP address for a = server ..." This is ambiguous. Do you mean the server knows the client address, or = the client knows the server address? It sounds like the latter, but = later text makes me wonder if you meant the former. -- 10.3, 7th paragraph: "... pre-configured with a list of known public = CAs." By pre-configured, you mean by the manufacturer or vendor, right? -- 10.5, 2nd paragraph: Does this contradict guidance about using a private CA to identify = multiple peers? I don't think you intend it that way; I assume you mean = the cert presented by a client must be unique, but as written it's easy = to assume that you mean the server has to have unique certs configured = for each client, which it would not if it were to allow any arbitrary = client that has a cert signed by a private CA. From jouni.nospam@gmail.com Tue Nov 19 02:21:23 2013 Return-Path: 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 3AB9E1ADBCB; Tue, 19 Nov 2013 02:21:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.199 X-Spam-Level: ** X-Spam-Status: No, score=2.199 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MANGLED_LIST=2.3, SPF_PASS=-0.001] 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 oVQCUONf1zkp; Tue, 19 Nov 2013 02:21:20 -0800 (PST) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 10DCE1ADBC7; Tue, 19 Nov 2013 02:21:19 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id en1so3323226wid.5 for ; Tue, 19 Nov 2013 02:21:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OlYf0HCB7EsxJD+drY/Lcjdh0afU71mgM7NN0KvMfbw=; b=gSiFErgAMMgV4FDE4rv+Vv9uga5G/jtKvm6ebxsyXcKf/qaxh0GTvVi6C4LjVlUKt2 ojj0sW4T2AjK5evsGmmJ7rTJohg+9BrcQt3U1I3QA0vDIs3pzNuV12gqyUXs1m975P9/ up8sI9xWjM0iNVR8iaiCXCtki/7GFCaBoJtebfwCGnTKbk7XH1S39lHG0LeWTD58w2xC qLPj8oOrU47CYYaYLsIQDbix9JpUwbgBl1yVD8S15grimRC4Ykb3W8FqCPyk4YevPOsp 7fJZmQX+DSUKzLYbWmqnlQfSWDtzmiX/86f9JWQVH/skkX+stdOhZj31FGQhRnuh7L9N fz4A== X-Received: by 10.194.21.225 with SMTP id y1mr392758wje.60.1384856473556; Tue, 19 Nov 2013 02:21:13 -0800 (PST) Received: from [10.216.14.104] ([93.158.44.59]) by mx.google.com with ESMTPSA id ey4sm33022512wic.11.2013.11.19.02.21.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Nov 2013 02:21:12 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: Date: Tue, 19 Nov 2013 12:21:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8232E3F6-E7C1-4804-AD4F-B73052DECAB0@gmail.com> References: To: Ben Campbell X-Mailer: Apple Mail (2.1510) Cc: radext@ietf.org, draft-ietf-radext-dtls.all@tools.ietf.org, "gen-art@ietf.org Team \(gen-art@ietf.org\)" Subject: Re: [radext] Gen-Art Early Review of draft-ietf-radext-dtls-07 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 10:21:23 -0000 Thanks Ben for the review! - JOuni On Nov 19, 2013, at 1:38 AM, Ben Campbell wrote: >=20 > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at >=20 > . >=20 > This is an early review at WGLC last call. >=20 > Document: draft-ietf-radext-dtls-07 > Reviewer: Ben Campbell > Review Date: 2013-11-18 >=20 > Summary: This draft is on the right track, but there are significant = open issues that should be resolved before it progresses. >=20 > [Note: This review is different from the usual Gen-ART review due to = the fact that it's an early (as in prior to pubreq) review, and that the = draft is intended to become an experimental RFC. The gen-ART review = process is tuned for drafts at IETF last call or later. It's a little = hard to figure out what criteria should be used for drafts at an earlier = point in the life-cycle. That being said, I reviewed this as if it were = near-final, and apologize if that turns out to be too strict for an = early review. >=20 > I used similar review criteria as I would for a standards-track draft, = since this draft still specifies protocol with the hope of interoperable = implementations. The only difference comes from a few comments = explicitly about the experimental status of the draft.] >=20 >=20 > *** Major issues: >=20 > -- General: >=20 > The draft needs an overhaul of it's use of normative language. There = appears to be redundant (and possibly contradictory) language for the = same requirements sprinkled throughout. There are also cases of = normative language being used for internal implementation guidance, = which is not appropriate as described by RFC 2119. (See the minor issues = section for details--most of the instances would not qualify as major = issues by themselves, but I think they constitute a major issue in the = aggregate.) >=20 > -- section 3, 2nd paragraph: "... long-term use of RADIUS/UDP is NOT = RECOMMENDED."=20 >=20 > While I agree with the sentiment, that's not an appropriate assertion = for an experimental RFC. It would either need to go into an = standards-track update to the RADIUS spec, or a BCP. >=20 > (Also applies to the reiteration in 10.1) >=20 >=20 > *** Minor issues: >=20 > -- General: It might be worth some text on why this is experimental = rather than informational. Is there any plan to evaluate the = implementation results? Is there an expectation that a future = RADIUS/DTLS spec could become standards-track? Is there any plan to = evaluate the outcome of this document? >=20 > -- Section 1, 2nd paragraph: >=20 > Isn't this true for almost any use of IPSec? Is there some specific = reason this is worse for RADIUS than for other protocols? >=20 > -- Section 1, 4th paragraph: >=20 > The second sentence mentions that firewall rules do not need to be = changed. The following sentence recommends a change to firewall rules. >=20 > The firewall rule recommendations in the 3rd sentence seems odd, since = it seems like any protocol over DTLS would pass. Also, does this imply a = recommendation that firewalls with DPI be used in the first place, since = the absence of such a firewall has the same effect as having one that = doesn't enforce the protocol? (Is there a reason a protocol spec should = recommend firewall rules in the first place, other than to mention = places where certain firewall rules might prevent interfere with = operation?) >=20 > -- section 2.1, 5th paragraph (3rd paragraph after bullet list) : = "Implementations MUST support encapsulated RADIUS packets of 4096 in = length..." >=20 > Please be more precise than "MUST support". Specifically, does "MUST = support" indicate you must support both sending and receiving of that = size? (since 4096 would generally exceed PMTU even for RADIUS/UDP) >=20 > -- 2.2 and children: >=20 > I find this section confusing as to where to find the authoritative = text. Some, but not all, of the material from 6614 is repeated as = normative text in later sections. The description of this draft as = applying 'semantic "patches"' to 6614 seems to imply you mean the 6114 = text, with these patches applied, to be normative, which creates some = potential conflicts. If, on the other hand, 2.2 (.x) is intended more as = a informative description of the differences, please say so. >=20 > -- 3, 1st paragraph: >=20 > Can you elaborate on the resulting "timeouts, lost traffic, and = network instabilities"? >=20 > -- 3.1:=20 >=20 > The section describes UDP/2083 as the "default port". But later = sections describe port related behavior in a way that makes it it look = like the impementations must always use 2083, which makes it more than = just a default. Is the administrator allowed to choose some other port = for any reason? If so, it might make more sense to refer to the port by = role rather than number when discussing port related behavior. (I note = that 6614 only mentions the port number in the initial assignment, the = IANA considerations, and the appendix.) >=20 >=20 > -- 3.2, last paragraph: >=20 > Can you elaborate on the bid down attack? Given that the use of dtls = is configured, rather than negotiated, how would an attacker bid it = down? >=20 > -- 4, 2nd paragraph: >=20 > Seems like an (or maybe even the) important point would be that a = client should not fall back to cleartext if a server appears to not = support it. >=20 > -4, 3rd paragraph: >=20 > Is the recommendation to use a local proxy for all clients, or just = those implemented as multiple processes? >=20 > -- 5.1.1, third paragraph: "In those cases, the implementation MAY = delete the underlying session" >=20 > Can you elaborate on why that's a MAY and not a SHOULD or MUST? >=20 > -- 5.1.1, 4th paragraph: >=20 > This paragraph rephrases 2119 normative language with more normative = language. That creates confusion about which text is authoritative. I = suggest either keeping the second paragraph and deleting the first, or = make the second non-normative. >=20 > -- 5.1.1, 6th paragraph: "The timestamp SHOULD be updated ..." >=20 > Why not MUST? >=20 > -- 5.1.1, 7th paragraph: >=20 > Is the "idle time" configurable setting on a per peer or global basis? >=20 > -- 5.1.1, 8th paragraph: >=20 > What does it mean to "track" sessions? Also, it seems like the = "SHOULD stop creating" guidance contradicts later guidance that least = recently used sessions might get dropped instead? >=20 > -- 5.1.1, 10th paragraph: =20 >=20 > Should the second sentence contain a normative MUST? >=20 > Also, the 2nd and 3rd sentences taken together seem say "the server = must keep the session open until it decides not to"=20 >=20 > How would an unauthenticated client close an active DTLS session? >=20 > -- 5.2, 1st paragraph: >=20 > The normative requirement for a client to use heartbeats _or_ the = application level watchdog algorithm seems to contradict the normative = guidance that a server SHOULD use both. >=20 > -- 5.2, 3rd paragraph, 1st sentence: >=20 > I would hesitate to phrase this that a client may violate the previous = normative SHOULDs. It would be better to phrase this as describing th = econsequences should the client ignore the SHOULD. >=20 > -- 5.2, 2nd to last paragraph: >=20 > Does this have actual interop or security issues beyond saying, "it's = harder to implement and you might screw it up"? If not, it seems counter = to the 2119 guidance on when normative language is appropriate. It would = be more properly non-normative implementation guidance. >=20 > -- 6, 1st paragraph: >=20 > You mention that these are implementation guidelines, and not part of = the protocol. But the section contains 2119 style normative = requirements. in general, that's not appropriate unless non-compliance = impact interoperability or create some other Bad Thing, such as insecure = behavior, excessive bandwidth usage, congestion, etc. Implementation = guidance for behavior that is not externally observable should use = non-normative. >=20 > -- 6, 2nd and 3rd paragraph: >=20 > The RECOMMENDation to allow administrative entry of keys and to derive = keys from a PRNG seem contradictory. >=20 >=20 > -- 6.1, 1st paragraph: >=20 > Does the guidance to use connected sockets remove previous normative = requirements about session management and tracking? If not, please = indicate the difference. >=20 > -- 6.1, 3rd paragraph: >=20 > This seems to assume that all radius clients are implementd as = multiple processes. Is that the intent? >=20 > Also, it's better not to use normative requirements for internal = implementation choices. Describe the externally visible behavior = normatively. You can give implementation advice in the form of example = strategies to fulfill the black-box normative requirements. >=20 > -- 9 >=20 > Why not choose a new port? Is there absolute certainty this won't = conflict with the previous usage? I do note that 6414 made the same = choice, so I guess consistency with radius/TLS has some value. But that = draft talks about compatibility between radsec and radius/tls, which is = not mentioned here. >=20 > -- 10, last paragraph: >=20 > You describe the use of null crypto as an implementation or = configuration error. Was it intended to be forbidden from intentional = use? Is there a need to remove the fixed secret requirement for null = crypto, or to disallow null crypto entirely? >=20 > -- 10.1, 3rd paragraph: >=20 > It would be helpful to have guidance on how to match a certificate to = a client or server identity, how to configure trust for a self-signed = cert, etc. >=20 > -- 10.1, 4th paragraph:=20 >=20 > -- 10.1, last paragraph: >=20 > Why does the historic use of shared secrets matter, since this = document requires all implementations to use a fixed value? Or do you = mean the use of poor secrets as PSKs? >=20 > -- 10.2, 2nd paragraph: >=20 > This is redundant with previous normative requirements. (Also = contradictory, since the previous text said "SHOULD", and contradictory = guidance on what to do when the limit is exceeded.) >=20 > -- 10.3, 4th paragraph: >=20 > Does this need to be as strong as SHOULD? Is this likely to conflict = with dynamic discovery, should it ever exist? >=20 > -- 10.3, 5th and 6th paragraphs: >=20 > Paragraph 5 says credentials should be statically configured. To me, = "credentials" means "the certificate" in this case. That seems to = disallow things like statically configuring a name that must match a = certificate (perhaps signed by a CA.) >=20 > Paragraph 6 seems to entirely contradict paragraph 5 by recommending = private CAs, and accepting any peer that presents a cert signed by that = CA. That's pretty much the opposite of statically configured = credentials. (Paragraph 8 also seems to contradict the static = configuration part.) >=20 > The last sentence refers to "the invalid server". What invalid server = is that? None have been mentioned so far. >=20 > -- 10.4: >=20 > The guidance in the last paragraph does not make sense. The section = seems to say that NATs will break radius/dtls, so you should use dtls = when behind a NAT. >=20 > -- 10.6, last paragraph: >=20 > Can you elaborate on this? Why would an unauthorized 3rd party be able = to get packets past the DTLS layer? OTOH, If an authorized client is = sending invalid radius packets, wouldn't you want to terminate the = session? >=20 > -- 10.7 >=20 > Redundant normative requirements (This is at least the third time the = separate process issue and local proxy guidance has been described.) >=20 >=20 >=20 > *** Nits/editorial comments: >=20 > -- IDNits reports some issues; please check. >=20 > -- Abstract: > Please avoid citations in the abstract. Please consider removing the = "scare quotes". >=20 > -- Section 1, 5th paragraph: >=20 > it seems like the RADIUS problems that this does not solve are in = generally solved by RADIUS/TLS. If so, it would probably be worth a = mention. >=20 > -- section 2.1, 4th paragraph from end:=20 >=20 > Seems like there are other changes as well. For example, you don't = include "Use DTLS" as one of the changes in RADIUS/DTLS from RADIUS/USP. >=20 > -- 2.2 and children: >=20 > In my strictly personal opinion, the approach of patching 6614 = transfers a lot of effort from the author to the reader. A reader will = basically need to keep both docs open side by side to understand this. = I understand the desire to avoid duplicating normative text, but I think = that the balance here has swung too far away from readability. (OTOH, = see my related comment under "minor issues). >=20 > -- 2.2.1, paragraph 5: >=20 > should TLS parameters be DTLS parameters? >=20 > -- 2.2.2: >=20 > Why a separate section to say sections 4 and 6 also apply? (The = re-iteration seems unneeded.) >=20 > -- 3.1, last sentence: >=20 > Really, 2.2.1 doesn't describe that. 6114 describes that. Better to = cite the source than to cite a citation to the source, especially when = that citation doesn't mention the issues at all. >=20 > -- 4, 3rd paragraph: >=20 > Do you really mean multiple independent _implementations_? Or multiple = independent instances or processes, perhaps running the same = implementation? >=20 > -- section 5 and children: >=20 > In consistent use of "connection" vs "session". >=20 > -- 5.1.1, 2nd paragraph: >=20 > What is an "entry" session? >=20 > -- 6.1, 2nd paragraph: >=20 > Source port? Source address? Both? >=20 > -- 7: >=20 > Only the first paragraph seems to be about implementation experience. >=20 > -- 10, 2nd paragraph: "All of the security considerations for RADIUS = apply to the RADIUS portion of the specification." >=20 > The next paragraph seems to contradict this. >=20 > -- 10.3, 2nd paragraph: "... a client has a fixed IP address for a = server ..." >=20 > This is ambiguous. Do you mean the server knows the client address, or = the client knows the server address? It sounds like the latter, but = later text makes me wonder if you meant the former. >=20 > -- 10.3, 7th paragraph: "... pre-configured with a list of known = public CAs." >=20 > By pre-configured, you mean by the manufacturer or vendor, right? >=20 > -- 10.5, 2nd paragraph: >=20 > Does this contradict guidance about using a private CA to identify = multiple peers? I don't think you intend it that way; I assume you mean = the cert presented by a client must be unique, but as written it's easy = to assume that you mean the server has to have unique certs configured = for each client, which it would not if it were to allow any arbitrary = client that has a cert signed by a private CA. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 From aduitsis@gmail.com Tue Nov 19 03:16:02 2013 Return-Path: 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 49D9E1ADBFF; Tue, 19 Nov 2013 03:16:02 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 5I7E64eC83YE; Tue, 19 Nov 2013 03:16:01 -0800 (PST) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id D30621ADE87; Tue, 19 Nov 2013 03:16:00 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id e14so4129608iej.12 for ; Tue, 19 Nov 2013 03:15:54 -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=9YCTPq75XDP2CiTBjpiQEZ65eYQNgy0rL8owRGDjhec=; b=t2OcD1Js1U/Bx8z1/iDJygT/E6UeSO9vo+oZ9lWcE2kbDGLxYY8zjcftOy7BVbSHqv JPVJ+IItFP+J9v+HhkbgaXEPSVsOLUeadGqjqIavNJNcSCJ3qL+DQOoMAxYyGjjIqsYf cXYwPHxUdQukvLaAnEdfa1jSqkQzZW3BuJ+Ji5e42skEoRf5S9IchKhGaIph7hh3gJD9 iDUbIxON8p/sjoQCQmDKENgalwo7JakOp6+oNPV7QS4bQfqyNng8tvs7KKbXkqK8XWpD 95yR4LrgeTPkxL6IMNS8+ZHmTBAxlBF7IB4xf3xTjSJu4i81qWBEellwCva9CNssCpEX iXjQ== MIME-Version: 1.0 X-Received: by 10.50.6.99 with SMTP id z3mr18661655igz.27.1384859754853; Tue, 19 Nov 2013 03:15:54 -0800 (PST) Received: by 10.64.227.168 with HTTP; Tue, 19 Nov 2013 03:15:54 -0800 (PST) In-Reply-To: References: <11836.1384276281@sandelman.ca> <3673.1384528283@sandelman.ca> Date: Tue, 19 Nov 2013 13:15:54 +0200 Message-ID: From: Athanasios Douitsis To: Roberta Maglione Content-Type: multipart/alternative; boundary=e89a8f3b9c23c0800404eb85c9f1 Cc: Michael Richardson , homenet@ietf.org, robmgl@cisco.com, radext@ietf.org, "dhcwg@ietf.org WG" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 11:16:02 -0000 --e89a8f3b9c23c0800404eb85c9f1 Content-Type: text/plain; charset=ISO-8859-1 (i.e. have a configuration option to use the Framed-IPv6-Prefix value in > the prefix exclude option instead of an RA) Correction, the above is incorrect, as has been rightly pointed. Are there any cases where the Framed-IPv6-Prefix value will not be copied as-is in the OPTION_PD_EXCLUDE value? --e89a8f3b9c23c0800404eb85c9f1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

=
(i.e. have a configuration option to use= the Framed-IPv6-Prefix value in the prefix exclude option instead of an RA= )

Correction, the above is incorre= ct, as has been rightly pointed.

A= re there any cases where the Framed-IPv6-Prefix value will not be copied as= -is in the OPTION_PD_EXCLUDE value?




--e89a8f3b9c23c0800404eb85c9f1-- From aduitsis@gmail.com Tue Nov 19 04:39:40 2013 Return-Path: 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 A369E1ADF60; Tue, 19 Nov 2013 04:39:40 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 t35I6npyMq9G; Tue, 19 Nov 2013 04:39:38 -0800 (PST) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC1D1ADF44; Tue, 19 Nov 2013 04:39:38 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id ar20so4868070iec.30 for ; Tue, 19 Nov 2013 04:39:32 -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=SeO5uhpZRId+vkxU8MmfshD2DlSfESRkRR8NmwBYld4=; b=B/m/y16mlKnxRkBVwJPyWPfbe1zbsoX7vY8wVP+jqNPV9+SQsRhF7OrHjNyENrw3rY bnVbGBpLFxj4l5+79Sm+IqdZqgD6CiOZ2OOOTuiBxqFP8G3meRJfw90SgQGA6gTT/eUG O45shEPrJZcRSrPbZSNtwMbBRloo09APHSMg5VZWUxzzwmsC/UaGJnpp/Ei1yxX4s41C MyOy+SctgMShMGDgICtz1pqysp/BI4rDvWMIZVYANLUfIqXlq+kGfOm/1UAO6a+8TVWq 96eBNpxdm3W1mDQk8ToOvNB0AxEiQwjBn9pSXZcM4qpr8gxLO0TzYmD+qHo7pg1aGu98 9W6Q== MIME-Version: 1.0 X-Received: by 10.50.73.74 with SMTP id j10mr18633108igv.50.1384864772351; Tue, 19 Nov 2013 04:39:32 -0800 (PST) Received: by 10.64.227.168 with HTTP; Tue, 19 Nov 2013 04:39:32 -0800 (PST) In-Reply-To: <70913413-2B68-4703-84E3-F7CC47E1A0E2@cisco.com> References: <11836.1384276281@sandelman.ca> <3673.1384528283@sandelman.ca> <70913413-2B68-4703-84E3-F7CC47E1A0E2@cisco.com> Date: Tue, 19 Nov 2013 14:39:32 +0200 Message-ID: From: Athanasios Douitsis To: "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary=089e01228a3cd17fe404eb86f461 Cc: "radext@ietf.org" , Michael Richardson , "Roberta Maglione \(robmgl\)" , "dhcwg@ietf.org WG" , Roberta Maglione , "homenet@ietf.org" Subject: Re: [radext] [dhcwg] [homenet] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 12:39:40 -0000 --089e01228a3cd17fe404eb86f461 Content-Type: text/plain; charset=ISO-8859-1 Hello (thanks for the answer), The uplink connection between the delegating and the requesting router will be in many cases enumerated with a prefix dictated by the Framed-IPv6-Prefix value. If this uplink prefix is going to be a part of the greater prefix that will be delegated, we would in effect have to include the value of the Framed-IPv6-Prefix in the OPTION_PD_EXCLUDE. Example, if a delegating router makes a RADIUS request and gets the following attributes in the reply: Framed-IPv6-Prefix='2001:dead:beef::/64' Delegated-IPv6-Prefix='2001:dead:beef::/56' Then the delegating router should 1)send an RA in the client uplink interface with 2001:dead:beef::/64. The uplink is enumerated with that /64. 2)Afterwards, when requested for PD, it should reply with the 2001:dead:beef::/56 to the requesting router, but excluding the 2001:dead:beef::/64 from that /56 by putting it in the OPTION_PD_EXCLUDE. So in effect, the Framed-IPv6-Prefix has been copied in the OPTION_PD_EXCLUDE option. If I have misunderstood something in the RFC or the discussion, I'd be grateful if you would correct me. Thanks very much, Athanasios On Tue, Nov 19, 2013 at 2:07 PM, Bernie Volz (volz) wrote: > Why would it ever be copied into that option? That makes no sense to me. > > - Bernie (from iPad) > > On Nov 19, 2013, at 6:16 AM, "Athanasios Douitsis" > wrote: > > > > (i.e. have a configuration option to use the Framed-IPv6-Prefix value in >> the prefix exclude option instead of an RA) > > > Correction, the above is incorrect, as has been rightly pointed. > > Are there any cases where the Framed-IPv6-Prefix value will not be > copied as-is in the OPTION_PD_EXCLUDE value? > > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg > > -- Athanasios Douitsis --089e01228a3cd17fe404eb86f461 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello (thanks for the answer),

The = uplink connection between the delegating and the requesting router will be = in many cases enumerated with a prefix dictated by the Framed-IPv6-Prefix v= alue. If this uplink prefix is going to be a part of the greater prefix tha= t will be delegated, we would in effect have to include the value of the Fr= amed-IPv6-Prefix in the OPTION_PD_EXCLUDE.

Example, if a delegating router makes a RADIUS request and g= ets the following attributes in the reply:

Framed-IPv6-Pr= efix=3D'2001:dead:beef::/64'
Delegated-IPv6-Prefix=3D= '2001:dead:beef::/56'

Then the delegating router should
1)send an RA in the cl= ient uplink interface with 2001:dead:beef::/64. The uplink is enumerated wi= th that /64.
2)Afterwards, when requested for PD, it should r= eply with the 2001:dead:beef::/56 to the requesting router, but excluding t= he 2001:dead:beef::/64 from that /56 by putting it in the OPTION_PD_EXCLUDE= .

So in effect, the Framed-IPv6-Prefix has been copied in the = OPTION_PD_EXCLUDE option.

If I have misunderstood somethi= ng in the RFC or the discussion, I'd be grateful if you would correct m= e.

Thanks very much,
Athanasios


=








On Tue, Nov 19, 2013 at= 2:07 PM, Bernie Volz (volz) <volz@cisco.com> wrote:
Why would it ever be copied into that option? That makes no sense to m= e.

- Bernie (from iPad)

On Nov 19, 2013, at 6:16 AM, "Athanasios Douitsis" <aduitsis@gmail.com> wr= ote:



(i.e. have a configuration option to use the Framed-IPv6-Prefix value in th= e prefix exclude option instead of an RA)

Correction, the above is incorrect, as has been = rightly pointed.

Are there any cases where the Framed-IPv6-Prefix= value will not be copied as-is in the OPTION_PD_EXCLUDE value?




_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg



--
Athanasios Douitsis
=

--089e01228a3cd17fe404eb86f461-- From jouni.nospam@gmail.com Tue Nov 19 04:45:07 2013 Return-Path: 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 0CF991ADF82; Tue, 19 Nov 2013 04:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 0NIg6_bDj9q4; Tue, 19 Nov 2013 04:45:05 -0800 (PST) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id C6BD11ADF80; Tue, 19 Nov 2013 04:45:04 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id u56so360612wes.23 for ; Tue, 19 Nov 2013 04:44:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=W2GO3CAUoiQ7T821SPUyWzeCwaNow/wgyg8m/cNWoKA=; b=dCyvTxN39okvf6Cks0RgZm60xGJZoRwzh9Es9S4hfv9hHeFYDj81erqlny/9bR2wVE 0blYohMm1boIWnsG7BuBZjs+2eb4TVoKxPbVfVW9Nm5bNN7VtjFtwRq/LudENiZb4Ttb 2Mubf0da4FNti4Mv6bUE0onlAMj8fTOAYK6R/c/ozZIZ2BjyOBk80TPd9RBeZ5BfZmzt vzkfWBuDEylNun0d6KCmW3MyCxhPMS2mRTo564ws8+Epm5B2GaiRaBANiEoGfiwkdOqP Nb1luRHC9eB64rNvjBaDm2CPYGnnCf1eoiUcSVZqh0UGsuTV2ILGGQxezJQnsLkA4Hol EeFQ== X-Received: by 10.181.13.6 with SMTP id eu6mr20779079wid.42.1384865098108; Tue, 19 Nov 2013 04:44:58 -0800 (PST) Received: from [10.216.15.149] ([93.158.48.157]) by mx.google.com with ESMTPSA id y20sm34219949wib.0.2013.11.19.04.44.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Nov 2013 04:44:57 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <70913413-2B68-4703-84E3-F7CC47E1A0E2@cisco.com> Date: Tue, 19 Nov 2013 14:44:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2E6FE96B-441C-4702-811C-154F1EC4F570@gmail.com> References: <11836.1384276281@sandelman.ca> <3673.1384528283@sandelman.ca> , <70913413-2B68-4703-84E3-F7CC47E1A0E2@cisco.com> To: Bernie Volz (volz) X-Mailer: Apple Mail (2.1510) Cc: "radext@ietf.org" , Athanasios Douitsis , Michael Richardson , "Roberta Maglione \(robmgl\)" , "dhcwg@ietf.org WG" , Roberta Maglione , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 12:45:07 -0000 Just a general reminder. If you crosspost, make sure you also have = subscribed to the lists you CC. - Jouni (RADEXT co-chair) On Nov 19, 2013, at 2:07 PM, Bernie Volz (volz) wrote: > Why would it ever be copied into that option? That makes no sense to = me. >=20 > - Bernie (from iPad) >=20 > On Nov 19, 2013, at 6:16 AM, "Athanasios Douitsis" = wrote: >=20 >>=20 >>=20 >> (i.e. have a configuration option to use the Framed-IPv6-Prefix value = in the prefix exclude option instead of an RA) >>=20 >> Correction, the above is incorrect, as has been rightly pointed.=20 >>=20 >> Are there any cases where the Framed-IPv6-Prefix value will not be = copied as-is in the OPTION_PD_EXCLUDE value? >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> dhcwg mailing list >> dhcwg@ietf.org >> https://www.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From volz@cisco.com Tue Nov 19 04:07:49 2013 Return-Path: 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 3393B1ADF51; Tue, 19 Nov 2013 04:07:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.541 X-Spam-Level: X-Spam-Status: No, score=-8.541 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_ADULT2=1.474, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, T_FRT_ADULT2=0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 e06Rp7L1VEtQ; Tue, 19 Nov 2013 04:07:47 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED661A802D; Tue, 19 Nov 2013 04:07:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2580; q=dns/txt; s=iport; t=1384862862; x=1386072462; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=R7y++NC2qgk6WWqB2S4+oSz6SQlKKVh/KFY8dFw3qUA=; b=lVTE9z2igFugZw1RH9Bh1LR8KtPPkZ96wxg2TFKFqo9NUQei00Bme5/e dkqahhXGZlNYju1V60XenSo5Y7Aw5pd+LGOQkB63rfr93xnJnhveuOUBm 0UVtGN9hpVCAZC3oWLHAmC8R1wNyuKHPbb6kt3pHYNq2LKr6ogdAU7gT4 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAEdTi1KtJXG//2dsb2JhbABZgwc4wBKBIBZ0giYBAQQBAQFrCxACAQgEAQkxByEGCxQRAgQOBYdvAw8NuHYNiTkTBIxjgnAEB4MggRIDlieBa4xVhTiDKA X-IronPort-AV: E=Sophos;i="4.93,729,1378857600"; d="scan'208,217";a="575326" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-2.cisco.com with ESMTP; 19 Nov 2013 12:07:41 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAJC7ebm003945 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Nov 2013 12:07:40 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.192]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Tue, 19 Nov 2013 06:07:40 -0600 From: "Bernie Volz (volz)" To: Athanasios Douitsis Thread-Topic: [dhcwg] [homenet] PPP, DHCPv6 and Prefix Delegation Thread-Index: AQHO5Ri7/ZQxPbNQZU2e9Sr4HhC+RposdbHZ Date: Tue, 19 Nov 2013 12:07:40 +0000 Message-ID: <70913413-2B68-4703-84E3-F7CC47E1A0E2@cisco.com> References: <11836.1384276281@sandelman.ca> <3673.1384528283@sandelman.ca> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_709134132B68470384E3F7CC47E1A0E2ciscocom_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 19 Nov 2013 04:47:28 -0800 Cc: "radext@ietf.org" , Michael Richardson , "Roberta Maglione \(robmgl\)" , "dhcwg@ietf.org WG" , Roberta Maglione , "homenet@ietf.org" Subject: Re: [radext] [dhcwg] [homenet] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 12:07:49 -0000 --_000_709134132B68470384E3F7CC47E1A0E2ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Why would it ever be copied into that option? That makes no sense to me. - Bernie (from iPad) On Nov 19, 2013, at 6:16 AM, "Athanasios Douitsis" > wrote: (i.e. have a configuration option to use the Framed-IPv6-Prefix value in th= e prefix exclude option instead of an RA) Correction, the above is incorrect, as has been rightly pointed. Are there any cases where the Framed-IPv6-Prefix value will not be copied a= s-is in the OPTION_PD_EXCLUDE value? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg --_000_709134132B68470384E3F7CC47E1A0E2ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Why would it ever be copied into that option? That makes no sense to m= e.

- Bernie (from iPad)

On Nov 19, 2013, at 6:16 AM, "Athanasios Douitsis" <aduitsis@gmail.com> wrote:



(i.e. have a configuration option to use the Framed-IPv6-Prefix value in th= e prefix exclude option instead of an RA)

Correction, the above is incorrect, as has been = rightly pointed.

Are there any cases where the Framed-IPv6-Prefix= value will not be copied as-is in the OPTION_PD_EXCLUDE value?




_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.i= etf.org/mailman/listinfo/dhcwg
--_000_709134132B68470384E3F7CC47E1A0E2ciscocom_-- From Carl.Wuyts@technicolor.com Tue Nov 19 04:46:36 2013 Return-Path: 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 5970E1ADF80; Tue, 19 Nov 2013 04:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.716 X-Spam-Level: X-Spam-Status: No, score=-2.716 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADULT2=1.474, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_FRT_ADULT2=0.01] autolearn=ham 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 V8MMp47MKhEE; Tue, 19 Nov 2013 04:46:31 -0800 (PST) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by ietfa.amsl.com (Postfix) with ESMTP id 991491ADF88; Tue, 19 Nov 2013 04:46:27 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKUotdnOZUsFhnobkm3RYU+1YH0Z30zITT@postini.com; Tue, 19 Nov 2013 04:46:25 PST Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 19 Nov 2013 13:43:28 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.71]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Tue, 19 Nov 2013 13:43:30 +0100 From: Wuyts Carl To: Athanasios Douitsis , "Bernie Volz (volz)" Date: Tue, 19 Nov 2013 13:43:29 +0100 Thread-Topic: [dhcwg] [homenet] PPP, DHCPv6 and Prefix Delegation Thread-Index: Ac7lJHGFVFb+NLyBQYyV6Fm0s9ia9QAADPVQ Message-ID: <3135C2851EB6764BACEF35D8B495596806FB82BE47@MOPESMBX01.eu.thmulti.com> References: <11836.1384276281@sandelman.ca> <3673.1384528283@sandelman.ca> <70913413-2B68-4703-84E3-F7CC47E1A0E2@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3135C2851EB6764BACEF35D8B495596806FB82BE47MOPESMBX01eut_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 19 Nov 2013 04:47:28 -0800 Cc: "radext@ietf.org" , "homenet@ietf.org" , "Roberta Maglione \(robmgl\)" , "dhcwg@ietf.org WG" , Michael Richardson Subject: Re: [radext] [dhcwg] [homenet] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 12:46:36 -0000 --_000_3135C2851EB6764BACEF35D8B495596806FB82BE47MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It's probably just a remark/side note, but pd_exclude could also be used wi= th DHCPv6 iso RA on the WAN-link. I've not bumped in to many customers usi= ng RA on WAN links to number them, not with separate prefix nor with exclud= ed prefix, so the typical use case will be to get/use an excluded prefix, a= nd to assign an IP from it to the WAN link through ia_na. Regs Carl From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Athanasios Douitsi= s Sent: dinsdag 19 november 2013 13:40 To: Bernie Volz (volz) Cc: radext@ietf.org; Michael Richardson; Roberta Maglione (robmgl); dhcwg@i= etf.org WG; homenet@ietf.org Subject: Re: [dhcwg] [homenet] PPP, DHCPv6 and Prefix Delegation Hello (thanks for the answer), The uplink connection between the delegating and the requesting router will= be in many cases enumerated with a prefix dictated by the Framed-IPv6-Pref= ix value. If this uplink prefix is going to be a part of the greater prefix= that will be delegated, we would in effect have to include the value of th= e Framed-IPv6-Prefix in the OPTION_PD_EXCLUDE. Example, if a delegating router makes a RADIUS request and gets the followi= ng attributes in the reply: Framed-IPv6-Prefix=3D'2001:dead:beef::/64' Delegated-IPv6-Prefix=3D'2001:dead:beef::/56' Then the delegating router should 1)send an RA in the client uplink interface with 2001:dead:beef::/64. The u= plink is enumerated with that /64. 2)Afterwards, when requested for PD, it should reply with the 2001:dead:bee= f::/56 to the requesting router, but excluding the 2001:dead:beef::/64 from= that /56 by putting it in the OPTION_PD_EXCLUDE. So in effect, the Framed-IPv6-Prefix has been copied in the OPTION_PD_EXCLU= DE option. If I have misunderstood something in the RFC or the discussion, I'd be grat= eful if you would correct me. Thanks very much, Athanasios On Tue, Nov 19, 2013 at 2:07 PM, Bernie Volz (volz) > wrote: Why would it ever be copied into that option? That makes no sense to me. - Bernie (from iPad) On Nov 19, 2013, at 6:16 AM, "Athanasios Douitsis" > wrote: (i.e. have a configuration option to use the Framed-IPv6-Prefix value in th= e prefix exclude option instead of an RA) Correction, the above is incorrect, as has been rightly pointed. Are there any cases where the Framed-IPv6-Prefix value will not be copied a= s-is in the OPTION_PD_EXCLUDE value? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg -- Athanasios Douitsis --_000_3135C2851EB6764BACEF35D8B495596806FB82BE47MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It’s probably just a remark/side note, but pd_exclude could also = be used with DHCPv6 iso RA on the WAN-link.  I’ve not bumped in = to many customers using RA on WAN links to number them, not with separate p= refix nor with excluded prefix, so the typical use case will be to get/use = an excluded prefix, and to assign an IP from it to the WAN link through ia_= na.

&nbs= p;

Regs=

Carl<= /p>

 

 

From: dhcwg [mailto:dhcwg-bounces@ietf= .org] On Behalf Of Athanasios Douitsis
Sent: dinsdag 19 no= vember 2013 13:40
To: Bernie Volz (volz)
Cc: radext@iet= f.org; Michael Richardson; Roberta Maglione (robmgl); dhcwg@ietf.org WG; ho= menet@ietf.org
Subject: Re: [dhcwg] [homenet] PPP, DHCPv6 and Pre= fix Delegation

 <= /p>

Hello= (thanks for the answer),

The uplink connection between the delegating and the= requesting router will be in many cases enumerated with a prefix dictated = by the Framed-IPv6-Prefix value. If this uplink prefix is going to be a par= t of the greater prefix that will be delegated, we would in effect have to = include the value of the Framed-IPv6-Prefix in the OPTION_PD_EXCLUDE. =

Example, if a delegating router m= akes a RADIUS request and gets the following attributes in the reply:<= /o:p>


Framed-IPv6-Prefix=3D'2001:dea= d:beef::/64'

Delegated-IPv6-Prefix=3D'2001:dead:beef::/56'

=

Then the delegating router should
1)sen= d an RA in the client uplink interface with 2001:dead:beef::/64. The uplink= is enumerated with that /64.

2)Afterwards, when requested for PD, it sho= uld reply with the 2001:dead:beef::/56 to the requesting router, but exclud= ing the 2001:dead:beef::/64 from that /56 by putting it in the OPTION_PD_EX= CLUDE.

So in effect, the Framed-IPv6-Prefix has been copied in the OPTIO= N_PD_EXCLUDE option.

If I have misunderstood something in the RFC or the = discussion, I'd be grateful if you would correct me.

<= div>

Thanks very much,Athanasios

 


 

=

 

<= o:p> 

 

On Tue, Nov 19, 2013= at 2:07 PM, Bernie Volz (volz) <volz@cisco.com> wrote:

Why would it ever be copied into that option? That makes no se= nse to me.

- Bernie (from iPad)

<= p class=3DMsoNormal style=3D'margin-bottom:12.0pt'>
On Nov 19, 2013, at = 6:16 AM, "Athanasios Douitsis" <aduitsis@gmail.com> wrote:

<= /div>
<= div>

 

 

(i.e. have a configuration option to use the Framed-IPv6-Pr= efix value in the prefix exclude option instead of an RA)

 

Correction, the above is inco= rrect, as has been rightly pointed.

Are there any cases where the Framed-IPv6-Prefix value will not be = copied as-is in the OPTION_PD_EXCLUDE value?

=




=

__= _____________________________________________
dhcwg mailing list
dhcwg@ietf.org
https:= //www.ietf.org/mailman/listinfo/dhcwg

=


<= br clear=3Dall>
--
Athanasios Douitsis

<= /div>= --_000_3135C2851EB6764BACEF35D8B495596806FB82BE47MOPESMBX01eut_-- From aduitsis@gmail.com Tue Nov 19 07:00:46 2013 Return-Path: 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 4F93F1AE000; Tue, 19 Nov 2013 07:00:46 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 NJxPyH4HJMHi; Tue, 19 Nov 2013 07:00:44 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 311B21ADFE7; Tue, 19 Nov 2013 07:00:44 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id lx4so3215110iec.9 for ; Tue, 19 Nov 2013 07:00:38 -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=+vJH6yW0rUE9kRGr8/n2BidAQq5iMcYItDwJOocgKGA=; b=x4XCiY8L96eWqSK/PXxO9RjEssUHFR2gBu3Ft9/UvySq3NSbPH9E5HsH+WFIuOp51N +Wve2l7vLVTKH324GLOTVuL9N9YhetYh0imqLA1uLrmUe6UnMjxFxnpQDUG30dRHdbyU 8D62yhxqtitXaCT2PNRm4ELSzyRh7xLXGv5vDwJbWWTNXy/vubutjQnABAXXds9FeSci tXdTOMscXre/DGieYPqSfv8AMCPJ4c6YLKnHzcfX1t88cBUthMcdPro4KayKZ9LddIsa bWxrKeJkVZq5hTS4eXnOOsRcltz6L0dHaaGkD9p1+TmgYgdE0OiYALqe4BuyIhSiE7by uqbg== MIME-Version: 1.0 X-Received: by 10.42.66.84 with SMTP id o20mr332332ici.71.1384873238171; Tue, 19 Nov 2013 07:00:38 -0800 (PST) Received: by 10.64.227.168 with HTTP; Tue, 19 Nov 2013 07:00:37 -0800 (PST) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AD9CDF7@xmb-rcd-x04.cisco.com> References: <11836.1384276281@sandelman.ca> <3673.1384528283@sandelman.ca> <70913413-2B68-4703-84E3-F7CC47E1A0E2@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AD9CDF7@xmb-rcd-x04.cisco.com> Date: Tue, 19 Nov 2013 17:00:37 +0200 Message-ID: From: Athanasios Douitsis To: "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary=90e6ba614b2a6b977c04eb88edc2 Cc: "radext@ietf.org" , "homenet@ietf.org" , "Roberta Maglione \(robmgl\)" , "dhcwg@ietf.org WG" , Michael Richardson Subject: Re: [radext] [dhcwg] [homenet] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 15:00:46 -0000 --90e6ba614b2a6b977c04eb88edc2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Nov 19, 2013 at 3:19 PM, Bernie Volz (volz) wrote: > I guess from RFC 4818, Delegated-IPv6-Prefix is used for PD. Whereas it > says: > > > > The Framed-IPv6-Prefix attribute [4] is not designed to support > > delegation of IPv6 prefixes to be used in the user's network, and > > therefore Framed-IPv6-Prefix and Delegated-IPv6-Prefix attributes may > > be included in the same RADIUS packet. > > > > But, I=92m not really clear if that ends up mapping to OPTION_PD_EXCLUDE = for > the Framed-IPv6-Prefix. Perhaps if the case is as in your example > (Framed-IPv6-Prefix is contained by Delegated-IPv6-Prefix, but not equal) > then using the Framed-IPv6-Prefix for OPTION_PD_EXCLUDE makes some sense? > Hello, In some cases like the one you and I have described here, I think it probably makes sense for the delegating router to use the Framed-IPv6-Prefix to infer what to put in the OPTION_PD_EXCLUDE. In these cases, the delegating router probably has all the information it needs to answer PD requests. Of course, some configuration options (e.g. do copy the Framed-IPv6-Prefix to OPTION_PD_EXCLUDE) and sanity checks (e.g. make sure the Framed is contained in the Delegated prefix) may be in order to make it work right, but the idea remains essentially the same. What I was also wondering previously is whether there are valid cases where one would want to explicitly dictate the OPTION_PD_EXCLUDE via RADIUS, presumably along with the Delegated-IPv6-Prefix. If those cases actually exist, maybe a separate RADIUS attribute could be useful. Just thinking loudly, not sure yet. Kind regards, --=20 Athanasios Douitsis --90e6ba614b2a6b977c04eb88edc2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

= On Tue, Nov 19, 2013 at 3:19 PM, Bernie Volz (volz) <<= a href=3D"mailto:volz@cisco.com" target=3D"_blank">volz@cisco.com> wrote:

I guess from RFC 4818, Delegated-IPv6-Prefix = is used for PD. Whereas it says:

=A0

=A0=A0 The Framed-IPv6-Prefix attribute [4] is not designed = to support

=A0=A0 delegation of IPv6 prefixes to be used in the user= 9;s network, and

=A0=A0 therefore Framed-IPv6-Prefix and Delegated-IPv6-Prefi= x attributes may

=A0=A0 be included in the same RADIUS packet.<= /span>

=A0

But, I=92m not reall= y clear if that ends up mapping to OPTION_PD_EXCLUDE for the Framed-IPv6-Pr= efix. Perhaps if the case is as in your example (Framed-IPv6-Prefix is contained by Delegated-IPv6-Prefix, but not equal) then using the Frame= d-IPv6-Prefix for OPTION_PD_EXCLUDE makes some sense?


Hello,

In some cases li= ke the one you and I have described here, I think it probably makes sense f= or the delegating router to use the Framed-IPv6-Prefix to infer what to put= in the OPTION_PD_EXCLUDE. In these cases, the delegating router probably h= as all the information it needs to answer PD requests. Of course, some conf= iguration options (e.g. do copy the Framed-IPv6-Prefix to OPTION_PD_EXCLUDE= ) and sanity checks (e.g. make sure the Framed is contained in the Delegate= d prefix) may be in order to make it work right, but the idea remains essen= tially the same.

What I was also wondering previously i= s whether there are valid cases where one would want to explicitly dictate = the OPTION_PD_EXCLUDE via RADIUS, presumably along with the Delegated-IPv6-= Prefix. If those cases actually exist, maybe a separate RADIUS attribute co= uld be useful. Just thinking loudly, not sure yet.

Kind = regards,
--
Athanasios Douitsis


--90e6ba614b2a6b977c04eb88edc2-- From robmgl@cisco.com Tue Nov 19 07:16:57 2013 Return-Path: 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 5F1811AE01C; Tue, 19 Nov 2013 07:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.541 X-Spam-Level: X-Spam-Status: No, score=-13.541 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_ADULT2=1.474, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, T_FRT_ADULT2=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 GwclZXmH5Dct; Tue, 19 Nov 2013 07:16:52 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 50CEE1ADFF3; Tue, 19 Nov 2013 07:16:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16603; q=dns/txt; s=iport; t=1384874206; x=1386083806; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9VrlUk8T2fZOP7CWfAu6qrHDhZ+jmSZsTAayFJXmVu4=; b=L2S53iqUPUtzRc29dzXjsqckA9hf0WoQ5Unc68auPaJIj9y5Ajathu8I NhLKJ+qbZWeZPcPoHDGsq7xorULqEF6JACO3wjBbx55IODvsTnWqrou2+ 1QT/Cln9sm/Y53s2xRj+mUYLxAZO8SAwe9KCwNl/ofW6o3lamxSX2qGo8 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAFWAi1KtJXHB/2dsb2JhbABZgkNEOFO/PoEhFnSCJQEBAQQBAQEqQQsQAgEIEQQBAQsdByEGCxQJCAIEAQ0FCIdnAw8Ntk4NiEgTBIxjgkMtBAYBgyCBEgOWJ45AhTiDKIIq X-IronPort-AV: E=Sophos;i="4.93,729,1378857600"; d="scan'208,217";a="286069451" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 19 Nov 2013 15:16:45 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rAJFGjk5010268 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Nov 2013 15:16:45 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Tue, 19 Nov 2013 09:16:45 -0600 From: "Roberta Maglione (robmgl)" To: Wuyts Carl , Athanasios Douitsis , "Bernie Volz (volz)" Thread-Topic: [dhcwg] [homenet] PPP, DHCPv6 and Prefix Delegation Thread-Index: AQHO5SRsttdYcQjLZEODiORjPZunGZos5DGA///C96A= Date: Tue, 19 Nov 2013 15:16:45 +0000 Message-ID: <57C3345230A4F94C9B2F5CFA05D7F2BD1D4ED6B6@xmb-rcd-x01.cisco.com> References: <11836.1384276281@sandelman.ca> <3673.1384528283@sandelman.ca> <70913413-2B68-4703-84E3-F7CC47E1A0E2@cisco.com> <3135C2851EB6764BACEF35D8B495596806FB82BE47@MOPESMBX01.eu.thmulti.com> In-Reply-To: <3135C2851EB6764BACEF35D8B495596806FB82BE47@MOPESMBX01.eu.thmulti.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.148.141] Content-Type: multipart/alternative; boundary="_000_57C3345230A4F94C9B2F5CFA05D7F2BD1D4ED6B6xmbrcdx01ciscoc_" MIME-Version: 1.0 Cc: "radext@ietf.org" , "homenet@ietf.org" , "dhcwg@ietf.org WG" , Michael Richardson Subject: Re: [radext] [dhcwg] [homenet] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 15:16:57 -0000 --_000_57C3345230A4F94C9B2F5CFA05D7F2BD1D4ED6B6xmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Carl, I agree with you that using DHCPv6 to number the WAN is a more common appro= ach. In such case you don't really need PD exclude; you just need a single IPv6 = address for that link and RFC 6911 in section 3.1 already defines the Frame= d-IPv6-Address Radius attribute to be used for this purpose. "3.1. Framed-IPv6-Address The Framed-IPv6-Address Attribute indicates an IPv6 address that is assigned to the NAS-facing interface of the RG/host." Thanks Roberta From: Wuyts Carl [mailto:Carl.Wuyts@technicolor.com] Sent: Tuesday, November 19, 2013 7:43 AM To: Athanasios Douitsis; Bernie Volz (volz) Cc: radext@ietf.org; Michael Richardson; Roberta Maglione (robmgl); dhcwg@i= etf.org WG; homenet@ietf.org Subject: RE: [dhcwg] [homenet] PPP, DHCPv6 and Prefix Delegation It's probably just a remark/side note, but pd_exclude could also be used wi= th DHCPv6 iso RA on the WAN-link. I've not bumped in to many customers usi= ng RA on WAN links to number them, not with separate prefix nor with exclud= ed prefix, so the typical use case will be to get/use an excluded prefix, a= nd to assign an IP from it to the WAN link through ia_na. Regs Carl From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Athanasios Douitsi= s Sent: dinsdag 19 november 2013 13:40 To: Bernie Volz (volz) Cc: radext@ietf.org; Michael Richardson; Roberta Ma= glione (robmgl); dhcwg@ietf.org WG; homenet@ietf.org= Subject: Re: [dhcwg] [homenet] PPP, DHCPv6 and Prefix Delegation Hello (thanks for the answer), The uplink connection between the delegating and the requesting router will= be in many cases enumerated with a prefix dictated by the Framed-IPv6-Pref= ix value. If this uplink prefix is going to be a part of the greater prefix= that will be delegated, we would in effect have to include the value of th= e Framed-IPv6-Prefix in the OPTION_PD_EXCLUDE. Example, if a delegating router makes a RADIUS request and gets the followi= ng attributes in the reply: Framed-IPv6-Prefix=3D'2001:dead:beef::/64' Delegated-IPv6-Prefix=3D'2001:dead:beef::/56' Then the delegating router should 1)send an RA in the client uplink interface with 2001:dead:beef::/64. The u= plink is enumerated with that /64. 2)Afterwards, when requested for PD, it should reply with the 2001:dead:bee= f::/56 to the requesting router, but excluding the 2001:dead:beef::/64 from= that /56 by putting it in the OPTION_PD_EXCLUDE. So in effect, the Framed-IPv6-Prefix has been copied in the OPTION_PD_EXCLU= DE option. If I have misunderstood something in the RFC or the discussion, I'd be grat= eful if you would correct me. Thanks very much, Athanasios On Tue, Nov 19, 2013 at 2:07 PM, Bernie Volz (volz) > wrote: Why would it ever be copied into that option? That makes no sense to me. - Bernie (from iPad) On Nov 19, 2013, at 6:16 AM, "Athanasios Douitsis" > wrote: (i.e. have a configuration option to use the Framed-IPv6-Prefix value in th= e prefix exclude option instead of an RA) Correction, the above is incorrect, as has been rightly pointed. Are there any cases where the Framed-IPv6-Prefix value will not be copied a= s-is in the OPTION_PD_EXCLUDE value? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg -- Athanasios Douitsis --_000_57C3345230A4F94C9B2F5CFA05D7F2BD1D4ED6B6xmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Carl,

I agree with you that usi= ng DHCPv6 to number the WAN is a more common approach.

In such case you don̵= 7;t really need PD exclude; you just need a single IPv6 address for that li= nk and RFC 6911 in section 3.1 already defines the Framed-IPv6-Address Radius attribute to be used for this purpose.

“3.1. Framed-IPv6-A= ddress

   The Framed-I= Pv6-Address Attribute indicates an IPv6 address that is

   assigned to = the NAS-facing interface of the RG/host.”

 <= /p>

Thanks<= /p>

Roberta=

 <= /p>

From: Wuyts Ca= rl [mailto:Carl.Wuyts@technicolor.com]
Sent: Tuesday, November 19, 2013 7:43 AM
To: Athanasios Douitsis; Bernie Volz (volz)
Cc: radext@ietf.org; Michael Richardson; Roberta Maglione (robmgl); = dhcwg@ietf.org WG; homenet@ietf.org
Subject: RE: [dhcwg] [homenet] PPP, DHCPv6 and Prefix Delegation

 

It’s probably just = a remark/side note, but pd_exclude could also be used with DHCPv6 iso RA on= the WAN-link.  I’ve not bumped in to many customers using RA on WAN links to number them, not with separate prefix nor with excluded pr= efix, so the typical use case will be to get/use an excluded prefix, and to= assign an IP from it to the WAN link through ia_na.

 <= /p>

Regs

Carl

 <= /p>

 <= /p>

From: dhcwg [<= a href=3D"mailto:dhcwg-bounces@ietf.org">mailto:dhcwg-bounces@ietf.org] On Behalf Of Athanasios Douitsis
Sent: dinsdag 19 november 2013 13:40
To: Bernie Volz (volz)
Cc: radext@ietf.org; Michael = Richardson; Roberta Maglione (robmgl); dhcwg@ietf.org WG; homenet@ietf.org
Subject: Re: [dhcwg] [homenet] PPP, DHCPv6 and Prefix Delegation

 

= Hello (thanks for the answer),

= The uplink connection between the delegating and the requesting router will= be in many cases enumerated with a prefix dictated by the Framed-IPv6-Pref= ix value. If this uplink prefix is going to be a part of the greater prefix that will be delegated, we would in eff= ect have to include the value of the Framed-IPv6-Prefix in the OPTION_PD_EX= CLUDE.

Example, if a delegating router= makes a RADIUS request and gets the following attributes in the reply:


Framed-IPv6-Prefix=3D'2001:dead:beef::/64'

= Delegated-IPv6-Prefix=3D'2001:dead:beef::/56'

Then the delegating router shou= ld
1)send an RA in the client uplink interface with 2001:dead:beef::/64. The u= plink is enumerated with that /64.

= 2)Afterwards, when requested for PD, it should reply with the 2001:dead:bee= f::/56 to the requesting router, but excluding the 2001:dead:beef::/64 from= that /56 by putting it in the OPTION_PD_EXCLUDE.

= So in effect, the Framed-IPv6-Prefix has been copied in the OPTION_PD_EXCLU= DE option.

= If I have misunderstood something in the RFC or the discussion, I'd be grat= eful if you would correct me.

= Thanks very much,
Athanasios

 

=  

 

 

 

=  

On Tue, Nov 19, 2013 at 2:07 PM= , Bernie Volz (volz) <volz@cisco.com> wrote:

Why would it ever be copied int= o that option? That makes no sense to me.

- Bernie (from iPad)

=
On Nov 19, 2013, at 6:16 AM, "Athanasios Douitsis" <aduitsis@gmail.com> wr= ote:

 

 

(i.e. have a configuration opti= on to use the Framed-IPv6-Prefix value in the prefix exclude option instead= of an RA)

 

= Correction, the above is incorrect, as has been rightly pointed.

Are there any cases where the F= ramed-IPv6-Prefix value will not be copied as-is in the OPTION_PD_EXCLUDE v= alue?

=

_______________________________= ________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg

=


--
Athanasios Douitsis

--_000_57C3345230A4F94C9B2F5CFA05D7F2BD1D4ED6B6xmbrcdx01ciscoc_-- From robmgl@cisco.com Tue Nov 19 07:21:07 2013 Return-Path: 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 7FB761AE017; Tue, 19 Nov 2013 07:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.541 X-Spam-Level: X-Spam-Status: No, score=-8.541 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_ADULT2=1.474, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, T_FRT_ADULT2=0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 GocICOrOhOHk; Tue, 19 Nov 2013 07:21:04 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 70C7C1AE010; Tue, 19 Nov 2013 07:21:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19278; q=dns/txt; s=iport; t=1384874458; x=1386084058; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=20+KGlSFAxPYhCt4X9wxufe22Tti1Uk/qNbt3BhSKmI=; b=EvyguP1QqrCJ2s6N+Zfw+jLRGih8qHj5DAAbB9fqzvsCXfy38mX7s9Un 3JTK6zUtnA2PWPo2Y97lURlhCbSJuMU7sj/IdFDJ8ITbhs+RKWvJJCmbb gKwkgJ6tMPVMuaVcfJjyuj+IMgf3q4EYVLT7dvQzGjnF3dpO07csdzGaa Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFADeBi1KtJV2b/2dsb2JhbABZgkNEOFO/PoEhFnSCJQEBAQMBAQEBKkELBQsCAQgRBAEBCx0HIQYLFAkIAgQBDQUIh2cDCQYNtk8NiEgTBIxjgkMtBAYBgyCBEgOWJ45AhTiDKIIq X-IronPort-AV: E=Sophos;i="4.93,729,1378857600"; d="scan'208,217";a="627037" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP; 19 Nov 2013 15:20:56 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAJFKuMi011166 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Nov 2013 15:20:56 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Tue, 19 Nov 2013 09:20:56 -0600 From: "Roberta Maglione (robmgl)" To: "Bernie Volz (volz)" , Athanasios Douitsis Thread-Topic: [dhcwg] [homenet] PPP, DHCPv6 and Prefix Delegation Thread-Index: AQHO5SRsttdYcQjLZEODiORjPZunGZos7mSA//+8S8A= Date: Tue, 19 Nov 2013 15:20:55 +0000 Message-ID: <57C3345230A4F94C9B2F5CFA05D7F2BD1D4ED6EB@xmb-rcd-x01.cisco.com> References: <11836.1384276281@sandelman.ca> <3673.1384528283@sandelman.ca> <70913413-2B68-4703-84E3-F7CC47E1A0E2@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AD9CDF7@xmb-rcd-x04.cisco.com> In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AD9CDF7@xmb-rcd-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.148.141] Content-Type: multipart/alternative; boundary="_000_57C3345230A4F94C9B2F5CFA05D7F2BD1D4ED6EBxmbrcdx01ciscoc_" MIME-Version: 1.0 Cc: "radext@ietf.org" , "homenet@ietf.org" , "dhcwg@ietf.org WG" , Michael Richardson Subject: Re: [radext] [dhcwg] [homenet] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 15:21:07 -0000 --_000_57C3345230A4F94C9B2F5CFA05D7F2BD1D4ED6EBxmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > Perhaps if the case is as in your example (Framed-IPv6-Prefix is containe= d by Delegated-IPv6-Prefix, but not equal) >then using the Framed-IPv6-Pref= ix for OPTION_PD_EXCLUDE makes some sense? Maybe it could theoretically make sense but is this a common deployment mod= el? Are there any Service Providers that use or plan to use this model? Thanks Roberta From: Bernie Volz (volz) Sent: Tuesday, November 19, 2013 8:20 AM To: Athanasios Douitsis Cc: radext@ietf.org; Michael Richardson; Roberta Maglione (robmgl); dhcwg@i= etf.org WG; homenet@ietf.org Subject: RE: [dhcwg] [homenet] PPP, DHCPv6 and Prefix Delegation I guess from RFC 4818, Delegated-IPv6-Prefix is used for PD. Whereas it say= s: The Framed-IPv6-Prefix attribute [4] is not designed to support delegation of IPv6 prefixes to be used in the user's network, and therefore Framed-IPv6-Prefix and Delegated-IPv6-Prefix attributes may be included in the same RADIUS packet. But, I'm not really clear if that ends up mapping to OPTION_PD_EXCLUDE for = the Framed-IPv6-Prefix. Perhaps if the case is as in your example (Framed-I= Pv6-Prefix is contained by Delegated-IPv6-Prefix, but not equal) then using= the Framed-IPv6-Prefix for OPTION_PD_EXCLUDE makes some sense? - Bernie From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Athanasios Douitsi= s Sent: Tuesday, November 19, 2013 7:40 AM To: Bernie Volz (volz) Cc: radext@ietf.org; Michael Richardson; Roberta Ma= glione (robmgl); dhcwg@ietf.org WG; homenet@ietf.org= Subject: Re: [dhcwg] [homenet] PPP, DHCPv6 and Prefix Delegation Hello (thanks for the answer), The uplink connection between the delegating and the requesting router will= be in many cases enumerated with a prefix dictated by the Framed-IPv6-Pref= ix value. If this uplink prefix is going to be a part of the greater prefix= that will be delegated, we would in effect have to include the value of th= e Framed-IPv6-Prefix in the OPTION_PD_EXCLUDE. Example, if a delegating router makes a RADIUS request and gets the followi= ng attributes in the reply: Framed-IPv6-Prefix=3D'2001:dead:beef::/64' Delegated-IPv6-Prefix=3D'2001:dead:beef::/56' Then the delegating router should 1)send an RA in the client uplink interface with 2001:dead:beef::/64. The u= plink is enumerated with that /64. 2)Afterwards, when requested for PD, it should reply with the 2001:dead:bee= f::/56 to the requesting router, but excluding the 2001:dead:beef::/64 from= that /56 by putting it in the OPTION_PD_EXCLUDE. So in effect, the Framed-IPv6-Prefix has been copied in the OPTION_PD_EXCLU= DE option. If I have misunderstood something in the RFC or the discussion, I'd be grat= eful if you would correct me. Thanks very much, Athanasios On Tue, Nov 19, 2013 at 2:07 PM, Bernie Volz (volz) > wrote: Why would it ever be copied into that option? That makes no sense to me. - Bernie (from iPad) On Nov 19, 2013, at 6:16 AM, "Athanasios Douitsis" > wrote: (i.e. have a configuration option to use the Framed-IPv6-Prefix value in th= e prefix exclude option instead of an RA) Correction, the above is incorrect, as has been rightly pointed. Are there any cases where the Framed-IPv6-Prefix value will not be copied a= s-is in the OPTION_PD_EXCLUDE value? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg -- Athanasios Douitsis --_000_57C3345230A4F94C9B2F5CFA05D7F2BD1D4ED6EBxmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> Perhaps if the case = is as in your example (Framed-IPv6-Prefix is contained by Delegated-IPv6-Pr= efix, but not equal) >then using the Framed-IPv6-Prefix for OPTION_PD_EXCLUDE makes some sense?

 <= /p>

Maybe it could theoretica= lly make sense but is this a common deployment model? Are there any Service= Providers that use or plan to use this model?

 <= /p>

Thanks<= /p>

Roberta=

 <= /p>

From: Bernie V= olz (volz)
Sent: Tuesday, November 19, 2013 8:20 AM
To: Athanasios Douitsis
Cc: radext@ietf.org; Michael Richardson; Roberta Maglione (robmgl); = dhcwg@ietf.org WG; homenet@ietf.org
Subject: RE: [dhcwg] [homenet] PPP, DHCPv6 and Prefix Delegation

 

I guess from RFC 4818, De= legated-IPv6-Prefix is used for PD. Whereas it says:

 <= /p>

   The Framed-IPv6-Prefix attribute = [4] is not designed to support

   delegation of IPv6 prefixes to be= used in the user's network, and

   therefore Framed-IPv6-Prefix and = Delegated-IPv6-Prefix attributes may

   be included in the same RADIUS pa= cket.

 <= /p>

But, I’m not really= clear if that ends up mapping to OPTION_PD_EXCLUDE for the Framed-IPv6-Pre= fix. Perhaps if the case is as in your example (Framed-IPv6-Prefix is contained by Delegated-IPv6-Prefix, but not equal) then using the Frame= d-IPv6-Prefix for OPTION_PD_EXCLUDE makes some sense?

 <= /p>

- =        Bernie=

 <= /p>

From: dhcwg [<= a href=3D"mailto:dhcwg-bounces@ietf.org">mailto:dhcwg-bounces@ietf.org] On Behalf Of Athanasios Douitsis
Sent: Tuesday, November 19, 2013 7:40 AM
To: Bernie Volz (volz)
Cc: radext@ietf.org; Michael = Richardson; Roberta Maglione (robmgl); dhcwg@ietf.org WG; homenet@ietf.org
Subject: Re: [dhcwg] [homenet] PPP, DHCPv6 and Prefix Delegation

 

Hello (thanks for the= answer),

The uplink connection= between the delegating and the requesting router will be in many cases enu= merated with a prefix dictated by the Framed-IPv6-Prefix value. If this upl= ink prefix is going to be a part of the greater prefix that will be delegated, we would in effect have to incl= ude the value of the Framed-IPv6-Prefix in the OPTION_PD_EXCLUDE.

Example, if a delegating router makes a RADIUS reque= st and gets the following attributes in the reply:


Framed-IPv6-Prefix=3D'2001:dead:beef::/64'

Delegated-IPv6-Prefix= =3D'2001:dead:beef::/56'

Then the delegating router should
1)send an RA in the client uplink interface with 2001:dead:beef::/64. The u= plink is enumerated with that /64.

2)Afterwards, when re= quested for PD, it should reply with the 2001:dead:beef::/56 to the request= ing router, but excluding the 2001:dead:beef::/64 from that /56 by putting = it in the OPTION_PD_EXCLUDE.

So in effect, the Fra= med-IPv6-Prefix has been copied in the OPTION_PD_EXCLUDE option.=

If I have misundersto= od something in the RFC or the discussion, I'd be grateful if you would cor= rect me.

Thanks very much,
Athanasios

 

 

 

 

 

 

On Tue, Nov 19, 2013 at 2:07 PM, Bernie Volz (volz) = <volz@cisco.com&= gt; wrote:

Why would it ever be copied into that option? That m= akes no sense to me.

- Bernie (from iPad)


On Nov 19, 2013, at 6:16 AM, "Athanasios Douitsis" <aduitsis@gmail.com> wr= ote:

 

 

(i.e. have a configuration option to use the Framed-= IPv6-Prefix value in the prefix exclude option instead of an RA)=

 

Correction, the above= is incorrect, as has been rightly pointed.

Are there any cases where the Framed-IPv6-Prefix val= ue will not be copied as-is in the OPTION_PD_EXCLUDE value?



_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg




--
Athanasios Douitsis

--_000_57C3345230A4F94C9B2F5CFA05D7F2BD1D4ED6EBxmbrcdx01ciscoc_-- From aduitsis@gmail.com Tue Nov 19 08:07:54 2013 Return-Path: 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 731231AE009; Tue, 19 Nov 2013 08:07:54 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 pYoIufIXqUdz; Tue, 19 Nov 2013 08:07:52 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 825271ADF70; Tue, 19 Nov 2013 08:07:52 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id at1so1012498iec.35 for ; Tue, 19 Nov 2013 08:07:46 -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=FbA07J/Vk0sk84TRsM0pNt/e11xTVdORdwOLeSyxE+c=; b=LwvV1doTOZMZt+GAHYUXeFy2JrSZThRmnqKhsN7zLAyVaF3fAY0vhJD+DIocGznrwr /9H4WVLe7vopZa1xirbq+JgIeA2pC16qkLaZB9iYansmcId9ykO2fjIHEm3+Kp/FMVk3 0Gz5PbQA0YaiuljqxqFaDrz4CFdsVBAtf9prh9ASs24krmwfbmU3rSJaNyrf4bA0xQDv q5k2TXwocpKYGX+u5JDitXCz8GmLwGbK3jN0iTOaGZdzAqoGzD5LRZMM3DVeQ1gqedSd ll2TFknILsIqrxHPYyPlsJf7b4s9yX7hrYFhfzY6OXC2xJtgVoFuO+E23PVGLWXVOL02 HvsA== MIME-Version: 1.0 X-Received: by 10.50.128.72 with SMTP id nm8mr19792977igb.10.1384877266459; Tue, 19 Nov 2013 08:07:46 -0800 (PST) Received: by 10.64.227.168 with HTTP; Tue, 19 Nov 2013 08:07:46 -0800 (PST) In-Reply-To: <57C3345230A4F94C9B2F5CFA05D7F2BD1D4ED6EB@xmb-rcd-x01.cisco.com> References: <11836.1384276281@sandelman.ca> <3673.1384528283@sandelman.ca> <70913413-2B68-4703-84E3-F7CC47E1A0E2@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AD9CDF7@xmb-rcd-x04.cisco.com> <57C3345230A4F94C9B2F5CFA05D7F2BD1D4ED6EB@xmb-rcd-x01.cisco.com> Date: Tue, 19 Nov 2013 18:07:46 +0200 Message-ID: From: Athanasios Douitsis To: "Roberta Maglione (robmgl)" Content-Type: multipart/alternative; boundary=089e013c5af08665fe04eb89ddcd Cc: "radext@ietf.org" , "homenet@ietf.org" , "Bernie Volz \(volz\)" , "dhcwg@ietf.org WG" , Michael Richardson Subject: Re: [radext] [dhcwg] [homenet] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 16:07:54 -0000 --089e013c5af08665fe04eb89ddcd Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 19, 2013 at 5:20 PM, Roberta Maglione (robmgl) wrote: > > Perhaps if the case is as in your example (Framed-IPv6-Prefix is > contained by Delegated-IPv6-Prefix, but not equal) >then using the > Framed-IPv6-Prefix for OPTION_PD_EXCLUDE makes some sense? > > > > Maybe it could theoretically make sense but is this a common deployment > model? Are there any Service Providers that use or plan to use this model? > Hello, I wonder how common it is for providers to enumerate the WAN with a global prefix. If one wants to enumerate the WAN with a global prefix one should unavoidably have to find a /64 additionally to the /56 (or whatever is allocated) per customer. Without PD_EXCLUDE, the framed /64 must be foreign to the delegated /56, which means different prefix pools, double the size of the routing table in your delegating router, etc. Basically the "3 - Problem Background" from rfc6603 says it much better than me. In our setup (moderate size provider with PPP links over DSL enumerated with NDRA and then DHCPv6-PD), we use both Framed-IPv6-Prefix (global) and Delegated-IPv6-Prefix (also global) to tell the delegating router what to give out. Obviously these two prefixes come from different pools of global prefixes, foreign to each other. I really don't know how common it is, but if instead of maintaining two separate prefix pools for framed and delegated we could just use a single pool of /56 prefixes where the framed /64 comes from inside the corresponding /56 for each customer, that would be indeed great. -- Athanasios Douitsis --089e013c5af08665fe04eb89ddcd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Tue, Nov 19, 2013 at 5:20 PM, Roberta Maglione (robmgl) <robmgl@cisco.co= m> wrote:

> Perhaps if the case is as in your example (Fra= med-IPv6-Prefix is contained by Delegated-IPv6-Prefix, but not equal) >t= hen using the Framed-IPv6-Prefix for OPTION_PD_EXCLUDE makes some sense?

=A0<= /p>

Maybe it could theo= retically make sense but is this a common deployment model? Are there any S= ervice Providers that use or plan to use this model?


Hello,

I wonder how common it is for providers to enum= erate the WAN with a global prefix. If one wants to enumerate the WAN with = a global prefix one should unavoidably have to find a /64 additionally to t= he /56 (or whatever is allocated) per customer. Without PD_EXCLUDE, the fra= med /64 must be foreign to the delegated /56, which means different prefix = pools, double the size of the routing table in your delegating router, etc.= Basically the "3 - Problem Background" from rfc6603 says it much= better than me.

In our setup (moderate size provider w= ith PPP links over DSL enumerated with NDRA and then DHCPv6-PD), we use bot= h Framed-IPv6-Prefix (global) and Delegated-IPv6-Prefix (also global) to te= ll the delegating router what to give out. Obviously these two prefixes com= e from different pools of global prefixes, foreign to each other. I really = don't know how common it is, but if instead of maintaining two separate= prefix pools for framed and delegated we could just use a single pool of /= 56 prefixes where the framed /64 comes from inside the corresponding /56 fo= r each customer, that would be indeed great.

--
Athanasios Douitsis


--089e013c5af08665fe04eb89ddcd-- From jouni.nospam@gmail.com Tue Nov 19 08:22:50 2013 Return-Path: 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 432BE1AE071; Tue, 19 Nov 2013 08:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham 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 e-O2YySbG3AO; Tue, 19 Nov 2013 08:22:48 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 7C7D01ADF70; Tue, 19 Nov 2013 08:22:47 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id fb10so1718524wid.1 for ; Tue, 19 Nov 2013 08:22:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TY7RFpYAqPVKhdieewYCxjra3u2evHw+2k03hC0+kMY=; b=WKwVZ0D2qhVNtl24npzBKpl9wz0jFjelUOXiaCd3+v+o8iPyNhg35IDP7stuFgGXbr hd0ZNUR34KJxhbrkBBqkBUIDFPUWnfrqUrlmXjGssSl1YYMA/xjb7CfZkV6zJBpL9pOe ucjH3H7w7S8bsRlrxilCC6Pp5YwV4VUAzJG4FPd4mLHja3sDy5p9jrc1EdA74q/86LrW /xz1QDUFoqTicON+0pIGkNzYR/jP7iSNAHGy8flSYoYJuUfnEjNNx6RJydsuchdcYuYB jzcbjteXf7Le8k8sVjmnNP5E73oy6bDK1MdC+lkel9xs1cCdUXDSyL3TTzOAG7ll2Aik UKfQ== X-Received: by 10.180.160.240 with SMTP id xn16mr21493046wib.62.1384878160946; Tue, 19 Nov 2013 08:22:40 -0800 (PST) Received: from [10.216.15.149] ([93.158.48.157]) by mx.google.com with ESMTPSA id uc12sm7089626wib.3.2013.11.19.08.22.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Nov 2013 08:22:40 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AD9CDF7@xmb-rcd-x04.cisco.com> Date: Tue, 19 Nov 2013 18:22:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11836.1384276281@sandelman.ca> <3673.1384528283@sandelman.ca> <70913413-2B68-4703-84E3-F7CC47E1A0E2@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AD9CDF7@xmb-rcd-x04.cisco.com> To: Bernie Volz (volz) X-Mailer: Apple Mail (2.1510) Cc: "radext@ietf.org" , Athanasios Douitsis , Michael Richardson , "Roberta Maglione \(robmgl\)" , "dhcwg@ietf.org WG" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 16:22:50 -0000 On Nov 19, 2013, at 3:19 PM, Bernie Volz (volz) wrote: > I guess from RFC 4818, Delegated-IPv6-Prefix is used for PD. Whereas = it says: > =20 > The Framed-IPv6-Prefix attribute [4] is not designed to support > delegation of IPv6 prefixes to be used in the user's network, and > therefore Framed-IPv6-Prefix and Delegated-IPv6-Prefix attributes = may > be included in the same RADIUS packet. > =20 > But, I=92m not really clear if that ends up mapping to = OPTION_PD_EXCLUDE for the Framed-IPv6-Prefix. Perhaps if the case is as = in your example (Framed-IPv6-Prefix is contained by = Delegated-IPv6-Prefix, but not equal) then using the Framed-IPv6-Prefix = for OPTION_PD_EXCLUDE makes some sense? 3GPP system uses these in the above manner i.e. Framed-IPv6-Prefix -> = what you put into RA, Delegated-IPv6-Prefix -> what you delegate via = DHCPv6. And in this case what was in Framed-IPv6-Prefix goes into = OPTION_PD_EXCLUDE. - Jouni > =20 > - Bernie > =20 > From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Athanasios = Douitsis > Sent: Tuesday, November 19, 2013 7:40 AM > To: Bernie Volz (volz) > Cc: radext@ietf.org; Michael Richardson; Roberta Maglione (robmgl); = dhcwg@ietf.org WG; homenet@ietf.org > Subject: Re: [dhcwg] [homenet] PPP, DHCPv6 and Prefix Delegation > =20 > Hello (thanks for the answer), >=20 > The uplink connection between the delegating and the requesting router = will be in many cases enumerated with a prefix dictated by the = Framed-IPv6-Prefix value. If this uplink prefix is going to be a part of = the greater prefix that will be delegated, we would in effect have to = include the value of the Framed-IPv6-Prefix in the OPTION_PD_EXCLUDE. >=20 > Example, if a delegating router makes a RADIUS request and gets the = following attributes in the reply: >=20 > Framed-IPv6-Prefix=3D'2001:dead:beef::/64' > Delegated-IPv6-Prefix=3D'2001:dead:beef::/56' >=20 > Then the delegating router should=20 > 1)send an RA in the client uplink interface with 2001:dead:beef::/64. = The uplink is enumerated with that /64. > 2)Afterwards, when requested for PD, it should reply with the = 2001:dead:beef::/56 to the requesting router, but excluding the = 2001:dead:beef::/64 from that /56 by putting it in the = OPTION_PD_EXCLUDE. >=20 > So in effect, the Framed-IPv6-Prefix has been copied in the = OPTION_PD_EXCLUDE option. >=20 > If I have misunderstood something in the RFC or the discussion, I'd be = grateful if you would correct me. >=20 > Thanks very much, > Athanasios >=20 > =20 >=20 >=20 >=20 > =20 > =20 > =20 > =20 >=20 > On Tue, Nov 19, 2013 at 2:07 PM, Bernie Volz (volz) = wrote: > Why would it ever be copied into that option? That makes no sense to = me. >=20 > - Bernie (from iPad) >=20 > On Nov 19, 2013, at 6:16 AM, "Athanasios Douitsis" = wrote: >=20 > =20 > =20 > (i.e. have a configuration option to use the Framed-IPv6-Prefix value = in the prefix exclude option instead of an RA) > =20 > Correction, the above is incorrect, as has been rightly pointed. >=20 > Are there any cases where the Framed-IPv6-Prefix value will not be = copied as-is in the OPTION_PD_EXCLUDE value? >=20 >=20 >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg >=20 >=20 >=20 > --=20 > Athanasios Douitsis >=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From volz@cisco.com Tue Nov 19 05:20:09 2013 Return-Path: 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 61FBF1ADFA8; Tue, 19 Nov 2013 05:20:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.541 X-Spam-Level: X-Spam-Status: No, score=-8.541 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_ADULT2=1.474, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, T_FRT_ADULT2=0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 8qse3Ge4v5TO; Tue, 19 Nov 2013 05:20:07 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id DC6A01ADFA6; Tue, 19 Nov 2013 05:20:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18596; q=dns/txt; s=iport; t=1384867201; x=1386076801; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5ND2Ub+e+evZCSQc8tE6N2LABhaS5O9VpLjraz0GqzA=; b=Ffdm3TiozT/q24XxbkpOoqM0FtCgEpMP4lsy5AnSdvdP1uBFbYyDulrg 56huOGSOjS2RnRKjmEscSTk7ZCtKmnEmguZKrKVR0rsWTKambyjt4HDb1 bS9i6TQ7Qk5UBYhEU5+SBVWsKO05WPmQ6RziFZe3HXbDQdnMN4D4dYCs7 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFABZli1KtJV2c/2dsb2JhbABZgkNEOFO/PoEfFnSCJQEBAQQBAQEqQQsQAgEIDgMEAQELHQchBgsUCQgCBA4FCIdnAw8Ntj8NiTkTBIxjgkMtBAYBgyCBEgOWJ45AhTiDKIIq X-IronPort-AV: E=Sophos;i="4.93,729,1378857600"; d="scan'208,217";a="595038" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-8.cisco.com with ESMTP; 19 Nov 2013 13:20:00 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rAJDK0HL020798 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Nov 2013 13:20:00 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.192]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Tue, 19 Nov 2013 07:19:59 -0600 From: "Bernie Volz (volz)" To: Athanasios Douitsis Thread-Topic: [dhcwg] [homenet] PPP, DHCPv6 and Prefix Delegation Thread-Index: AQHO5SRrepnZi6kuBkSQ4npy9bk7mJosiNgw Date: Tue, 19 Nov 2013 13:19:59 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AD9CDF7@xmb-rcd-x04.cisco.com> References: <11836.1384276281@sandelman.ca> <3673.1384528283@sandelman.ca> <70913413-2B68-4703-84E3-F7CC47E1A0E2@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.241.183] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1AD9CDF7xmbrcdx04ciscoc_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 19 Nov 2013 08:24:28 -0800 Cc: "radext@ietf.org" , "homenet@ietf.org" , "Roberta Maglione \(robmgl\)" , "dhcwg@ietf.org WG" , Michael Richardson Subject: Re: [radext] [dhcwg] [homenet] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 13:20:09 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1AD9CDF7xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I guess from RFC 4818, Delegated-IPv6-Prefix is used for PD. Whereas it say= s: The Framed-IPv6-Prefix attribute [4] is not designed to support delegation of IPv6 prefixes to be used in the user's network, and therefore Framed-IPv6-Prefix and Delegated-IPv6-Prefix attributes may be included in the same RADIUS packet. But, I'm not really clear if that ends up mapping to OPTION_PD_EXCLUDE for = the Framed-IPv6-Prefix. Perhaps if the case is as in your example (Framed-I= Pv6-Prefix is contained by Delegated-IPv6-Prefix, but not equal) then using= the Framed-IPv6-Prefix for OPTION_PD_EXCLUDE makes some sense? - Bernie From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Athanasios Douitsi= s Sent: Tuesday, November 19, 2013 7:40 AM To: Bernie Volz (volz) Cc: radext@ietf.org; Michael Richardson; Roberta Maglione (robmgl); dhcwg@i= etf.org WG; homenet@ietf.org Subject: Re: [dhcwg] [homenet] PPP, DHCPv6 and Prefix Delegation Hello (thanks for the answer), The uplink connection between the delegating and the requesting router will= be in many cases enumerated with a prefix dictated by the Framed-IPv6-Pref= ix value. If this uplink prefix is going to be a part of the greater prefix= that will be delegated, we would in effect have to include the value of th= e Framed-IPv6-Prefix in the OPTION_PD_EXCLUDE. Example, if a delegating router makes a RADIUS request and gets the followi= ng attributes in the reply: Framed-IPv6-Prefix=3D'2001:dead:beef::/64' Delegated-IPv6-Prefix=3D'2001:dead:beef::/56' Then the delegating router should 1)send an RA in the client uplink interface with 2001:dead:beef::/64. The u= plink is enumerated with that /64. 2)Afterwards, when requested for PD, it should reply with the 2001:dead:bee= f::/56 to the requesting router, but excluding the 2001:dead:beef::/64 from= that /56 by putting it in the OPTION_PD_EXCLUDE. So in effect, the Framed-IPv6-Prefix has been copied in the OPTION_PD_EXCLU= DE option. If I have misunderstood something in the RFC or the discussion, I'd be grat= eful if you would correct me. Thanks very much, Athanasios On Tue, Nov 19, 2013 at 2:07 PM, Bernie Volz (volz) > wrote: Why would it ever be copied into that option? That makes no sense to me. - Bernie (from iPad) On Nov 19, 2013, at 6:16 AM, "Athanasios Douitsis" > wrote: (i.e. have a configuration option to use the Framed-IPv6-Prefix value in th= e prefix exclude option instead of an RA) Correction, the above is incorrect, as has been rightly pointed. Are there any cases where the Framed-IPv6-Prefix value will not be copied a= s-is in the OPTION_PD_EXCLUDE value? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg -- Athanasios Douitsis --_000_489D13FBFA9B3E41812EA89F188F018E1AD9CDF7xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I guess from RFC 4818, De= legated-IPv6-Prefix is used for PD. Whereas it says:

 <= /p>

   The Framed-IPv6-Prefix attribute = [4] is not designed to support

   delegation of IPv6 prefixes to be= used in the user's network, and

   therefore Framed-IPv6-Prefix and = Delegated-IPv6-Prefix attributes may

   be included in the same RADIUS pa= cket.

 <= /p>

But, I’m not really= clear if that ends up mapping to OPTION_PD_EXCLUDE for the Framed-IPv6-Pre= fix. Perhaps if the case is as in your example (Framed-IPv6-Prefix is contained by Delegated-IPv6-Prefix, but not equal) then using the Frame= d-IPv6-Prefix for OPTION_PD_EXCLUDE makes some sense?

 <= /p>

- =          Bernie=

 <= /p>

From: dhcwg [m= ailto:dhcwg-bounces@ietf.org] On Behalf Of Athanasios Douitsis
Sent: Tuesday, November 19, 2013 7:40 AM
To: Bernie Volz (volz)
Cc: radext@ietf.org; Michael Richardson; Roberta Maglione (robmgl); = dhcwg@ietf.org WG; homenet@ietf.org
Subject: Re: [dhcwg] [homenet] PPP, DHCPv6 and Prefix Delegation

 

Hello (thanks for the= answer),

The uplink connection= between the delegating and the requesting router will be in many cases enu= merated with a prefix dictated by the Framed-IPv6-Prefix value. If this upl= ink prefix is going to be a part of the greater prefix that will be delegated, we would in effect have to incl= ude the value of the Framed-IPv6-Prefix in the OPTION_PD_EXCLUDE.

Example, if a delegating router makes a RADIUS reque= st and gets the following attributes in the reply:


Framed-IPv6-Prefix=3D'2001:dead:beef::/64'

Delegated-IPv6-Prefix= =3D'2001:dead:beef::/56'

Then the delegating router should
1)send an RA in the client uplink interface with 2001:dead:beef::/64. The u= plink is enumerated with that /64.

2)Afterwards, when re= quested for PD, it should reply with the 2001:dead:beef::/56 to the request= ing router, but excluding the 2001:dead:beef::/64 from that /56 by putting = it in the OPTION_PD_EXCLUDE.

So in effect, the Fra= med-IPv6-Prefix has been copied in the OPTION_PD_EXCLUDE option.=

If I have misundersto= od something in the RFC or the discussion, I'd be grateful if you would cor= rect me.

Thanks very much,
Athanasios

 



 

 

 

 

On Tue, Nov 19, 2013 at 2:07 PM, Bernie Volz (volz) = <volz@cisco.com&= gt; wrote:

Why would it ever be copied into that option? That m= akes no sense to me.

- Bernie (from iPad)


On Nov 19, 2013, at 6:16 AM, "Athanasios Douitsis" <aduitsis@gmail.com> wr= ote:

 

 

(i.e. have a configuration option to use the Framed-= IPv6-Prefix value in the prefix exclude option instead of an RA)=

 

Correction, the above= is incorrect, as has been rightly pointed.

Are there any cases where the Framed-IPv6-Prefix val= ue will not be copied as-is in the OPTION_PD_EXCLUDE value?




_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dhcwg




--
Athanasios Douitsis

--_000_489D13FBFA9B3E41812EA89F188F018E1AD9CDF7xmbrcdx04ciscoc_-- From Carl.Wuyts@technicolor.com Tue Nov 19 07:22:22 2013 Return-Path: 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 5DD7F1AE035; Tue, 19 Nov 2013 07:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.716 X-Spam-Level: X-Spam-Status: No, score=-2.716 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADULT2=1.474, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_FRT_ADULT2=0.01] autolearn=ham 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 k9E6kOK1LJ7U; Tue, 19 Nov 2013 07:22:17 -0800 (PST) Received: from na3sys009aog128.obsmtp.com (na3sys009aog128.obsmtp.com [74.125.149.141]) by ietfa.amsl.com (Postfix) with ESMTP id 812771AE036; Tue, 19 Nov 2013 07:22:07 -0800 (PST) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob128.postini.com ([74.125.148.12]) with SMTP ID DSNKUouCFsMYUEhr58hzlzlzCX4QhWpaYJG/@postini.com; Tue, 19 Nov 2013 07:22:04 PST Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 19 Nov 2013 16:18:35 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.71]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Tue, 19 Nov 2013 16:18:38 +0100 From: Wuyts Carl To: "Roberta Maglione (robmgl)" , Athanasios Douitsis , "Bernie Volz (volz)" Date: Tue, 19 Nov 2013 16:18:37 +0100 Thread-Topic: [dhcwg] [homenet] PPP, DHCPv6 and Prefix Delegation Thread-Index: AQHO5SRsttdYcQjLZEODiORjPZunGZos5DGA///C96CAAAOZcA== Message-ID: <3135C2851EB6764BACEF35D8B495596806FB82C198@MOPESMBX01.eu.thmulti.com> References: <11836.1384276281@sandelman.ca> <3673.1384528283@sandelman.ca> <70913413-2B68-4703-84E3-F7CC47E1A0E2@cisco.com> <3135C2851EB6764BACEF35D8B495596806FB82BE47@MOPESMBX01.eu.thmulti.com> <57C3345230A4F94C9B2F5CFA05D7F2BD1D4ED6B6@xmb-rcd-x01.cisco.com> In-Reply-To: <57C3345230A4F94C9B2F5CFA05D7F2BD1D4ED6B6@xmb-rcd-x01.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_3135C2851EB6764BACEF35D8B495596806FB82C198MOPESMBX01eut_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 19 Nov 2013 08:24:28 -0800 Cc: "radext@ietf.org" , "homenet@ietf.org" , "dhcwg@ietf.org WG" , Michael Richardson Subject: Re: [radext] [dhcwg] [homenet] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 15:22:22 -0000 --_000_3135C2851EB6764BACEF35D8B495596806FB82C198MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No, indeed, you don't really need pd_exclude, but it saves admin on not hav= ing to use separate ia_pd and ia_na Regs Carl From: Roberta Maglione (robmgl) [mailto:robmgl@cisco.com] Sent: dinsdag 19 november 2013 16:17 To: Wuyts Carl; Athanasios Douitsis; Bernie Volz (volz) Cc: radext@ietf.org; Michael Richardson; dhcwg@ietf.org WG; homenet@ietf.or= g Subject: RE: [dhcwg] [homenet] PPP, DHCPv6 and Prefix Delegation Hello Carl, I agree with you that using DHCPv6 to number the WAN is a more common appro= ach. In such case you don't really need PD exclude; you just need a single IPv6 = address for that link and RFC 6911 in section 3.1 already defines the Frame= d-IPv6-Address Radius attribute to be used for this purpose. "3.1. Framed-IPv6-Address The Framed-IPv6-Address Attribute indicates an IPv6 address that is assigned to the NAS-facing interface of the RG/host." Thanks Roberta From: Wuyts Carl [mailto:Carl.Wuyts@technicolor.com] Sent: Tuesday, November 19, 2013 7:43 AM To: Athanasios Douitsis; Bernie Volz (volz) Cc: radext@ietf.org; Michael Richardson; Roberta Ma= glione (robmgl); dhcwg@ietf.org WG; homenet@ietf.org= Subject: RE: [dhcwg] [homenet] PPP, DHCPv6 and Prefix Delegation It's probably just a remark/side note, but pd_exclude could also be used wi= th DHCPv6 iso RA on the WAN-link. I've not bumped in to many customers usi= ng RA on WAN links to number them, not with separate prefix nor with exclud= ed prefix, so the typical use case will be to get/use an excluded prefix, a= nd to assign an IP from it to the WAN link through ia_na. Regs Carl From: dhcwg [mailto:dhcwg-bounces@ietf.org] On Behalf Of Athanasios Douitsi= s Sent: dinsdag 19 november 2013 13:40 To: Bernie Volz (volz) Cc: radext@ietf.org; Michael Richardson; Roberta Ma= glione (robmgl); dhcwg@ietf.org WG; homenet@ietf.org= Subject: Re: [dhcwg] [homenet] PPP, DHCPv6 and Prefix Delegation Hello (thanks for the answer), The uplink connection between the delegating and the requesting router will= be in many cases enumerated with a prefix dictated by the Framed-IPv6-Pref= ix value. If this uplink prefix is going to be a part of the greater prefix= that will be delegated, we would in effect have to include the value of th= e Framed-IPv6-Prefix in the OPTION_PD_EXCLUDE. Example, if a delegating router makes a RADIUS request and gets the followi= ng attributes in the reply: Framed-IPv6-Prefix=3D'2001:dead:beef::/64' Delegated-IPv6-Prefix=3D'2001:dead:beef::/56' Then the delegating router should 1)send an RA in the client uplink interface with 2001:dead:beef::/64. The u= plink is enumerated with that /64. 2)Afterwards, when requested for PD, it should reply with the 2001:dead:bee= f::/56 to the requesting router, but excluding the 2001:dead:beef::/64 from= that /56 by putting it in the OPTION_PD_EXCLUDE. So in effect, the Framed-IPv6-Prefix has been copied in the OPTION_PD_EXCLU= DE option. If I have misunderstood something in the RFC or the discussion, I'd be grat= eful if you would correct me. Thanks very much, Athanasios On Tue, Nov 19, 2013 at 2:07 PM, Bernie Volz (volz) > wrote: Why would it ever be copied into that option? That makes no sense to me. - Bernie (from iPad) On Nov 19, 2013, at 6:16 AM, "Athanasios Douitsis" > wrote: (i.e. have a configuration option to use the Framed-IPv6-Prefix value in th= e prefix exclude option instead of an RA) Correction, the above is incorrect, as has been rightly pointed. Are there any cases where the Framed-IPv6-Prefix value will not be copied a= s-is in the OPTION_PD_EXCLUDE value? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg -- Athanasios Douitsis --_000_3135C2851EB6764BACEF35D8B495596806FB82C198MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

No, indeed, you don’t really need pd_exclude, but it saves admin = on not having to use separate ia_pd and ia_na

 

Regs

<= span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-ser= if";color:#1F497D'>Carl

 

<= b>From: Roberta Maglione (robmgl) [mailto:robmgl@cisco= .com]
Sent: dinsdag 19 november 2013 16:17
To: Wuyts C= arl; Athanasios Douitsis; Bernie Volz (volz)
Cc: radext@ietf.org;= Michael Richardson; dhcwg@ietf.org WG; homenet@ietf.org
Subject:= RE: [dhcwg] [homenet] PPP, DHCPv6 and Prefix Delegation<= /p>

 

Hello Carl,

I agree with you that using DHCPv6 to number the WAN = is a more common approach.

In such case you don’t really need PD exclude; you just= need a single IPv6 address for that link and RFC 6911 in section 3.1 alrea= dy defines the Framed-IPv6-Address Radius attribute to be used for this pur= pose.

“= 3.1. Framed-IPv6-Address

   The Framed-IPv6-Address Attribute indicates an IPv= 6 address that is

   assigned to the NAS-facing interface of the RG/host.̶= 1;

 = ;

Thanks

Roberta

 

From: Wuyts Car= l [mailto:Carl.Wuyts@technico= lor.com]
Sent: Tuesday, November 19, 2013 7:43 AM
To:<= /b> Athanasios Douitsis; Bernie Volz (volz)
Cc: radext@ietf.org; Michael Richardson; Roberta Maglione= (robmgl); dhcwg@ietf.org WG; homenet@ietf.org
Subject: RE: [d= hcwg] [homenet] PPP, DHCPv6 and Prefix Delegation

 

It’s probably just a remark= /side note, but pd_exclude could also be used with DHCPv6 iso RA on the WAN= -link.  I’ve not bumped in to many customers using RA on WAN lin= ks to number them, not with separate prefix nor with excluded prefix, so th= e typical use case will be to get/use an excluded prefix, and to assign an = IP from it to the WAN link through ia_na.

 

Regs

Carl

 

 

From:<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Tahoma","sans-seri= f"'> dhcwg [mailto:dhcwg-bounces@= ietf.org] On Behalf Of Athanasios Douitsis
Sent: dinsd= ag 19 november 2013 13:40
To: Bernie Volz (volz)
Cc: radext@ietf.org; Michael Richardson; R= oberta Maglione (robmgl); dhcwg@ietf.org<= /a> WG; homenet@ietf.org
Subj= ect: Re: [dhcwg] [homenet] PPP, DHCPv6 and Prefix Delegation=

 

Hello (thanks for the answer),=

Th= e uplink connection between the delegating and the requesting router will b= e in many cases enumerated with a prefix dictated by the Framed-IPv6-Prefix= value. If this uplink prefix is going to be a part of the greater prefix t= hat will be delegated, we would in effect have to include the value of the = Framed-IPv6-Prefix in the OPTION_PD_EXCLUDE.

Example, if a delegating router makes a RADIUS request and= gets the following attributes in the reply:


Framed-IPv6-Prefix=3D'2001:dead:beef::/64'

Delegated-= IPv6-Prefix=3D'2001:dead:beef::/56'

Then the delegating router should
1)send an RA in the client upl= ink interface with 2001:dead:beef::/64. The uplink is enumerated with that = /64.

2)Afterwards, when requested for PD, it should reply with the 2001:d= ead:beef::/56 to the requesting router, but excluding the 2001:dead:beef::/= 64 from that /56 by putting it in the OPTION_PD_EXCLUDE.

So in effect, t= he Framed-IPv6-Prefix has been copied in the OPTION_PD_EXCLUDE option.=

If= I have misunderstood something in the RFC or the discussion, I'd be gratef= ul if you would correct me.

Thanks very much,
Athanasios

 

 

 

=  

 

=

 <= /p>

On Tue, Nov 19, 2013 at 2:07 PM, Bernie Volz (= volz) <volz@cisco.co= m> wrote:

Why would it = ever be copied into that option? That makes no sense to me.

- Bernie= (from iPad)


On Nov 19, 2013, at 6:16 AM, "Athanasios= Douitsis" <aduitsis@gmail.com> wrote:

=  

 

(i.e. have a configuration option to use the Fr= amed-IPv6-Prefix value in the prefix exclude option instead of an RA)<= /o:p>

 

Correction, the a= bove is incorrect, as has been rightly pointed.

<= p class=3DMsoNormal>Are there any cases where the Framed-IPv6-Prefix value = will not be copied as-is in the OPTION_PD_EXCLUDE value?

=  

_______________________________________________
dhcwg mailing listdhcwg@ietf.org= https://www.ietf.org/mailman/listinfo/dhcwg




--
Athanasios Douitsis

= --_000_3135C2851EB6764BACEF35D8B495596806FB82C198MOPESMBX01eut_-- From aduitsis@gmail.com Tue Nov 19 08:38:37 2013 Return-Path: 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 94FDA1AE074; Tue, 19 Nov 2013 08:38:37 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 cYwz8FgyH_6b; Tue, 19 Nov 2013 08:38:36 -0800 (PST) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8341AE004; Tue, 19 Nov 2013 08:38:35 -0800 (PST) Received: by mail-ie0-f181.google.com with SMTP id e14so4573109iej.40 for ; Tue, 19 Nov 2013 08:38:29 -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=fU648LIiLyZaDYisFf+qAvX2k2hNzIKliEcEN3E1VPQ=; b=03TZJIbBl9uFe1PJ8qwEq02mnUHf5ZE2DcENPzZt5o+PFmqJVEEcqQ6zTTRLa2bF2B 14CiSIPn8uZlPq2CikBgGoQlwJg+V7mDsT17xACvdwGpMyLyiErreGUg9OHHBmFmLsiz qAOalQH+8gqQysrpWGdpEc4yVaLUHN1werKn83hQiRXzgbfw2ozr1P+Uz5xay4qswGq1 XIyiMvrpZ9/DzRp83vkJBGjevt7VfiRmPqHPd/4G07Q8knPXNAr9Z9HF/mkDRw8e8Qpc 7h8HU0vj4jjVcpAaT1nfjPzx9xC+JrH97C/MDwXzCM0s8vEq4BpxDNm74GSzfiqXRV6R WBqg== MIME-Version: 1.0 X-Received: by 10.50.6.99 with SMTP id z3mr19727272igz.27.1384879109911; Tue, 19 Nov 2013 08:38:29 -0800 (PST) Received: by 10.64.227.168 with HTTP; Tue, 19 Nov 2013 08:38:29 -0800 (PST) In-Reply-To: References: <11836.1384276281@sandelman.ca> <3673.1384528283@sandelman.ca> <70913413-2B68-4703-84E3-F7CC47E1A0E2@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AD9CDF7@xmb-rcd-x04.cisco.com> Date: Tue, 19 Nov 2013 18:38:29 +0200 Message-ID: From: Athanasios Douitsis To: Jouni Korhonen Content-Type: multipart/alternative; boundary=e89a8f3b9c23673bf504eb8a4b31 Cc: "radext@ietf.org" , Bernie Volz , Michael Richardson , "Roberta Maglione \(robmgl\)" , "dhcwg@ietf.org WG" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 16:38:37 -0000 --e89a8f3b9c23673bf504eb8a4b31 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Nov 19, 2013 at 6:22 PM, Jouni Korhonen wrote: > 3GPP system uses these in the above manner i.e. Framed-IPv6-Prefix -> what > you put into RA, Delegated-IPv6-Prefix -> what you delegate via DHCPv6. And > in this case what was in Framed-IPv6-Prefix goes into OPTION_PD_EXCLUDE. Hello, In your opinion, should the copying Framed-IPv6-Prefix -> OPTION_PD_EXCLUDE be rather be done (1) by the RADIUS server (assuming that a new separate hypothetical RADIUS attribute exists) or (2) by the delegating router? In other words, do you see any benefits in (1)? -- Athanasios Douitsis --e89a8f3b9c23673bf504eb8a4b31 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Tue, Nov 19, 2013 at 6:22 PM, Jouni Korhonen <jouni.nospam@gmail.c= om> wrote:
3GPP system uses these in the above manner i= .e. Framed-IPv6-Prefix -> what you put into RA, Delegated-IPv6-Prefix -&= gt; what you delegate via DHCPv6. And in this case what was in Framed-IPv6-= Prefix goes into OPTION_PD_EXCLUDE.

Hello,

In your opinion, s= hould the copying Framed-IPv6-Prefix -> OPTION_PD_EXCLUDE be rather be d= one (1) by the RADIUS server (assuming that a new separate hypothetical RAD= IUS attribute exists) or (2) by the delegating router?

In other words, do you see any benefit= s in (1)?

--
Athanasios Douitsis


--e89a8f3b9c23673bf504eb8a4b31-- From volz@cisco.com Tue Nov 19 08:42:21 2013 Return-Path: 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 F38C31AE078; Tue, 19 Nov 2013 08:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.541 X-Spam-Level: X-Spam-Status: No, score=-13.541 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_ADULT2=1.474, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, T_FRT_ADULT2=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 SvTAj29OoHOu; Tue, 19 Nov 2013 08:42:17 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8ADFC1AE074; Tue, 19 Nov 2013 08:42:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8657; q=dns/txt; s=iport; t=1384879332; x=1386088932; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9oZ9iuauy1yUlnCrsxKcG4yI8F8RCI3Ho4YyT+Fy69o=; b=hzE+jKat3IQllQ+8I1R8buXXtlcVYqOysYpE/tt3sHyysBt2ujyA9Ios KpEkKJDdkfxfnmCReX0sI8Y0vyR91NLlT925Ob4FPM+qIhJaJ2+iTgZnJ 9GmW6Hxbybg6cI0C5Gk+ahn5d11GMop7c2hNO6ceERh9o777zKERZapd9 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFALeTi1KtJXG+/2dsb2JhbABZgkNEOFO/PoEhFnSCJQEBAQQnBkwQAgEIDgMEAQELHQchERQJCAIEAQ0FCIdnAw+2Zw2ISBeMY4JDMQYBgyCBEgOWJ45AhTiDKIIq X-IronPort-AV: E=Sophos;i="4.93,730,1378857600"; d="scan'208,217";a="286120133" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 19 Nov 2013 16:42:11 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id rAJGgBic003961 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Nov 2013 16:42:11 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.192]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.03.0123.003; Tue, 19 Nov 2013 10:42:11 -0600 From: "Bernie Volz (volz)" To: Athanasios Douitsis , Jouni Korhonen Thread-Topic: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation Thread-Index: AQHO5UXOUF1xN076806q9v+WC3QBBposwc7w Date: Tue, 19 Nov 2013 16:42:10 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E1AD9D36C@xmb-rcd-x04.cisco.com> References: <11836.1384276281@sandelman.ca> <3673.1384528283@sandelman.ca> <70913413-2B68-4703-84E3-F7CC47E1A0E2@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AD9CDF7@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.65.118] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E1AD9D36Cxmbrcdx04ciscoc_" MIME-Version: 1.0 Cc: Michael Richardson , "radext@ietf.org" , "homenet@ietf.org" , "Roberta Maglione \(robmgl\)" , "dhcwg@ietf.org WG" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 16:42:21 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E1AD9D36Cxmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This must be done by the delegation router (if you are talking about the DH= CPv6 packet itself) - as it is the one that constructs the Advertise and Re= ply messages to the client. - Bernie From: Athanasios Douitsis [mailto:aduitsis@gmail.com] Sent: Tuesday, November 19, 2013 11:38 AM To: Jouni Korhonen Cc: Bernie Volz (volz); 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:22 PM, Jouni Korhonen > wrote: 3GPP system uses these in the above manner i.e. Framed-IPv6-Prefix -> what = you put into RA, Delegated-IPv6-Prefix -> what you delegate via DHCPv6. And= in this case what was in Framed-IPv6-Prefix goes into OPTION_PD_EXCLUDE. Hello, In your opinion, should the copying Framed-IPv6-Prefix -> OPTION_PD_EXCLUDE= be rather be done (1) by the RADIUS server (assuming that a new separate h= ypothetical RADIUS attribute exists) or (2) by the delegating router? In other words, do you see any benefits in (1)? -- Athanasios Douitsis --_000_489D13FBFA9B3E41812EA89F188F018E1AD9D36Cxmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This must be done by the = delegation router (if you are talking about the DHCPv6 packet itself) ̵= 1; as it is the one that constructs the Advertise and Reply messages to the client.

 <= /p>

- =          Bernie=

 <= /p>

From: Athanasi= os Douitsis [mailto:aduitsis@gmail.com]
Sent: Tuesday, November 19, 2013 11:38 AM
To: Jouni Korhonen
Cc: Bernie Volz (volz); radext@ietf.org; homenet@ietf.org; Roberta M= aglione (robmgl); dhcwg@ietf.org WG; Michael Richardson
Subject: Re: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation

 

 

On Tue, Nov 19, 2013 at 6:22 PM, Jouni Korhonen <= jouni.nospam@gm= ail.com> wrote:

3GPP system uses these in the above manner i.e. Fram= ed-IPv6-Prefix -> what you put into RA, Delegated-IPv6-Prefix -> what= you delegate via DHCPv6. And in this case what was in Framed-IPv6-Prefix g= oes into OPTION_PD_EXCLUDE.

 

Hello,

In your opinion, should the copying Framed-IPv6-Prefix -> OPTION_PD_EXCL= UDE be rather be done (1) by the RADIUS server (assuming that a new separat= e hypothetical RADIUS attribute exists) or (2) by the delegating router?

In other words, do you see any benefits in (1)?


--
Athanasios Douitsis

--_000_489D13FBFA9B3E41812EA89F188F018E1AD9D36Cxmbrcdx04ciscoc_-- From aduitsis@gmail.com Tue Nov 19 08:49:52 2013 Return-Path: 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 54CCF1AE0BC; Tue, 19 Nov 2013 08:49:52 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 EMXULDwQGEg7; Tue, 19 Nov 2013 08:49:50 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id B217B1AE0CA; Tue, 19 Nov 2013 08:49:50 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id lx4so3416105iec.37 for ; Tue, 19 Nov 2013 08:49:44 -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=dcU/pClsyWfQTnyr7PBLm+Pid12S1wKjKEFydqV62no=; b=Nlh/wUop++wWKJxrm90PDt1Wa6eVqK+Qi17XGgo6pq125LWj5OoBPZMBgVdTGEPXmW W88ZrcP3HY/J+9daRi6A62pydth/BgyfqlU+vQCCb519fW1aQPswK0NNJdv0Dw5dKJ6D PgLb9WWIKvLUwHxZr1J37vH5+IYBYgzRc/uWhVYBX0fskonRq45oXI7JoCaajjgCSXlv FoKh6f+MS+LWBDLva8SkLCwhGl2LdImPqXX8Fipc8uLoWWtCTvdvlwEqdDATxptcL0/A ENuxrccJvdW59mw8MOMQdGOpPv+qI8PbHyhY4u+bQjywQRPuoW7OhGkGVchjYSc7EfGy VcHw== MIME-Version: 1.0 X-Received: by 10.50.110.74 with SMTP id hy10mr19714505igb.0.1384879784651; Tue, 19 Nov 2013 08:49:44 -0800 (PST) Received: by 10.64.227.168 with HTTP; Tue, 19 Nov 2013 08:49:44 -0800 (PST) In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AD9D36C@xmb-rcd-x04.cisco.com> References: <11836.1384276281@sandelman.ca> <3673.1384528283@sandelman.ca> <70913413-2B68-4703-84E3-F7CC47E1A0E2@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AD9CDF7@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AD9D36C@xmb-rcd-x04.cisco.com> Date: Tue, 19 Nov 2013 18:49:44 +0200 Message-ID: From: Athanasios Douitsis To: "Bernie Volz (volz)" Content-Type: multipart/alternative; boundary=047d7bf182d29ef50004eb8a73dc Cc: "radext@ietf.org" , Michael Richardson , Jouni Korhonen , "Roberta Maglione \(robmgl\)" , "dhcwg@ietf.org WG" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 16:49:52 -0000 --047d7bf182d29ef50004eb8a73dc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Nov 19, 2013 at 6:42 PM, Bernie Volz (volz) wrote: > This must be done by the delegation router (if you are talking about the > DHCPv6 packet itself) =96 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, --=20 Athanasios Douitsis --047d7bf182d29ef50004eb8a73dc Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

= On Tue, Nov 19, 2013 at 6:42 PM, Bernie Volz (volz) <<= a href=3D"mailto:volz@cisco.com" target=3D"_blank">volz@cisco.com> wrote:
This must be done= by the delegation router (if you are talking about the DHCPv6 packet itsel= f) =96 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 assignmen= t, 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 va= lue.

Kind regards,
--
Athanasio= s Douitsis


--047d7bf182d29ef50004eb8a73dc-- From robmgl@cisco.com Tue Nov 19 09:10:53 2013 Return-Path: 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 30B6B1AE0EA; Tue, 19 Nov 2013 09:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.541 X-Spam-Level: X-Spam-Status: No, score=-13.541 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_ADULT2=1.474, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, T_FRT_ADULT2=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 ZwlizUmzWGSq; Tue, 19 Nov 2013 09:10:50 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 119A01AE00B; Tue, 19 Nov 2013 09:10:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8340; q=dns/txt; s=iport; t=1384881044; x=1386090644; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nlxKWhOio5OqQQoLg/FG8KHFQckwZWJBAgHkTk/A8Io=; b=DXfSl1+wIgqvF36LlS4tk7QqknYEAfF6rU0Krf4/2gUwRY8JTHolSKIy lc9k3q/t1CCdOezjJ4zqq2NNebaLeV73t+ODY6zjBufFT3lRCz/Me05v0 gu7ltwIT56lAaPr+9I6JN37ZDsGKzHEatQmj69f/A1E88S6qYiz9+Qwy5 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAP+ai1KtJV2Z/2dsb2JhbABZgkNEOFO/PoEhFnSCJQEBAQQtTBACAQgOAwQBAQsdByERFAkIAgQBDQUIh2cDD7Z2DYhIF4xjgkMxBgGDIIESA5QwgXeOQIU4gyiCKg X-IronPort-AV: E=Sophos;i="4.93,730,1378857600"; d="scan'208,217";a="283114983" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 19 Nov 2013 17:10:43 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAJHAhdm019230 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Nov 2013 17:10:43 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0123.003; Tue, 19 Nov 2013 11:10:43 -0600 From: "Roberta Maglione (robmgl)" To: Athanasios Douitsis , "Bernie Volz (volz)" Thread-Topic: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation Thread-Index: AQHO5UXOsn3IR999/EelIBkBsrSMwJotJp4AgAACHQD//50pQA== Date: Tue, 19 Nov 2013 17:10:42 +0000 Message-ID: <57C3345230A4F94C9B2F5CFA05D7F2BD1D4ED850@xmb-rcd-x01.cisco.com> References: <11836.1384276281@sandelman.ca> <3673.1384528283@sandelman.ca> <70913413-2B68-4703-84E3-F7CC47E1A0E2@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AD9CDF7@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AD9D36C@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.147.178] Content-Type: multipart/alternative; boundary="_000_57C3345230A4F94C9B2F5CFA05D7F2BD1D4ED850xmbrcdx01ciscoc_" MIME-Version: 1.0 Cc: Michael Richardson , "radext@ietf.org" , Jouni Korhonen , "homenet@ietf.org" , "dhcwg@ietf.org WG" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 17:10:53 -0000 --_000_57C3345230A4F94C9B2F5CFA05D7F2BD1D4ED850xmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 des= cribed in a clean way you would need a new RADIUS attribute for PD_EXCLUDE. The reason why I think a new radius would be required is because you need t= o differentiate between the scenario where Framed-IPv6-Prefix is used to nu= mber 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. Today the BNG (that in this case is acting both as RADIUS Client and Delega= ting 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 overloa= d the sematic of the Framed-IPv6-Prefix. Any comment? 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 (ro= bmgl); 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) > wrote: This must be done by the delegation router (if you are talking about the DH= CPv6 packet itself) - as it is the one that constructs the Advertise and Re= ply 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 va= lue. Kind regards, -- Athanasios Douitsis --_000_57C3345230A4F94C9B2F5CFA05D7F2BD1D4ED850xmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,<= /p>

I see your point. In my o= pinion 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.<= /o:p>

The reason why I think a = new radius would be required is because you need to differentiate between t= he scenario where Framed-IPv6-Prefix is used to number the Wan link with a separate prefix (not included in the PD - without the PD_E= XCLUDE) 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.

Today the BNG (that in th= is 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?

Thanks<= /p>

Roberta=

 <= /p>

From: Athanasi= os 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 Magli= one (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&= gt; wrote:

This must be done by the = delegation router (if you are talking about the DHCPv6 packet itself) ̵= 1; 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 packet= s.

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

--_000_57C3345230A4F94C9B2F5CFA05D7F2BD1D4ED850xmbrcdx01ciscoc_-- From jouni.nospam@gmail.com Tue Nov 19 09:36:58 2013 Return-Path: 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 802AD1AE0DB; Tue, 19 Nov 2013 09:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.484 X-Spam-Level: X-Spam-Status: No, score=0.484 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, FREEMAIL_REPLY=1, FRT_ADULT2=1.474, 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 dV3ZTtOvCY-q; Tue, 19 Nov 2013 09:36:57 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7B4621AE08C; Tue, 19 Nov 2013 09:36:56 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id k14so8007220wgh.17 for ; Tue, 19 Nov 2013 09:36:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DrXUE2lSNaWES5+Mg7lQStw6S8yWiiDZcGC7d5QYEFY=; b=oqkVH0Uj5fuarLbCd0bwzVjeM7jImfRn4oxUcHBj3mtSLSm8ISDXjFcBO6nwBUFJFd 2Y+/zdpHp+WqLHeqwnZYRGJ8KYkJFeh1r6Oqspqf6xZzEAuAT4Ntj0whtmRykLrwcnyy tEFAMaKJlvAuQxu2sB3FM7sExGO/R0ljGWZnvfBfvBt5te/liS7FyNxGcxMqnxG27R3k 8h67JvUWQnkHgylwMI0KwoVneJM1GZCskHtS2lMye9HjaXFPn46K7ExyGbNGptJspOE2 QmAG1tofFnbAjw60TWSlTpuJByHpAIsLLCCWzbGjaqgKfXBZ+iFBpV+71RRsjuBbyq8E OOSw== X-Received: by 10.180.101.230 with SMTP id fj6mr1733496wib.58.1384882609995; Tue, 19 Nov 2013 09:36:49 -0800 (PST) Received: from troma.lan (APuteaux-652-1-7-49.w82-124.abo.wanadoo.fr. [82.124.30.49]) by mx.google.com with ESMTPSA id hv5sm7689214wib.2.2013.11.19.09.36.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Nov 2013 09:36:47 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E1AD9D36C@xmb-rcd-x04.cisco.com> Date: Tue, 19 Nov 2013 19:36:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <67EEF6D2-3FF4-4A56-AA6B-D2B4B22D31A4@gmail.com> References: <11836.1384276281@sandelman.ca> <3673.1384528283@sandelman.ca> <70913413-2B68-4703-84E3-F7CC47E1A0E2@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AD9CDF7@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AD9D36C@xmb-rcd-x04.cisco.com> To: "Bernie Volz (volz)" X-Mailer: Apple Mail (2.1510) Cc: "radext@ietf.org" , Athanasios Douitsis , Michael Richardson , "Roberta Maglione \(robmgl\)" , "dhcwg@ietf.org WG" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 17:36:58 -0000 In 3GPP system in this particular setup the first hop router (for the = device/cpe) is also the delegating router and the RADIUS client.=20 - Jouni On Nov 19, 2013, at 6:42 PM, "Bernie Volz (volz)" = wrote: > This must be done by the delegation router (if you are talking about = the DHCPv6 packet itself) =96 as it is the one that constructs the = Advertise and Reply messages to the client. > =20 > - Bernie > =20 > From: Athanasios Douitsis [mailto:aduitsis@gmail.com]=20 > Sent: Tuesday, November 19, 2013 11:38 AM > To: Jouni Korhonen > Cc: Bernie Volz (volz); radext@ietf.org; homenet@ietf.org; Roberta = Maglione (robmgl); dhcwg@ietf.org WG; Michael Richardson > Subject: Re: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation > =20 > =20 > On Tue, Nov 19, 2013 at 6:22 PM, Jouni Korhonen = wrote: > 3GPP system uses these in the above manner i.e. Framed-IPv6-Prefix -> = what you put into RA, Delegated-IPv6-Prefix -> what you delegate via = DHCPv6. And in this case what was in Framed-IPv6-Prefix goes into = OPTION_PD_EXCLUDE. > =20 > Hello, >=20 > In your opinion, should the copying Framed-IPv6-Prefix -> = OPTION_PD_EXCLUDE be rather be done (1) by the RADIUS server (assuming = that a new separate hypothetical RADIUS attribute exists) or (2) by the = delegating router? >=20 > In other words, do you see any benefits in (1)? >=20 > --=20 > Athanasios Douitsis >=20 >=20 From jouni.nospam@gmail.com Tue Nov 19 09:43:01 2013 Return-Path: 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 C87C21AE118; Tue, 19 Nov 2013 09:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.484 X-Spam-Level: X-Spam-Status: No, score=0.484 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, FREEMAIL_REPLY=1, FRT_ADULT2=1.474, 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 dojDfd3SpMoR; Tue, 19 Nov 2013 09:43:00 -0800 (PST) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 371301AE117; Tue, 19 Nov 2013 09:42:59 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id x12so7869088wgg.13 for ; Tue, 19 Nov 2013 09:42:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Z16Ztk4xVQvEp7I2+OdsSriXy82xwcANqIzO3ym5fXw=; b=EdsFP4qc/V1N6DgslDvwyw/Qf+Zxo+pE9K5gQ86ZEPfV6kTRIt5JVIMafQCijjwYEA gt7jQQ5MKLW0qV1nYdWyDh0xPDE23igwHlr7eH9jY5H4EIOahHd+4eUc8iCNAhK1aoVT 0xg3uSoHyp409my5PCPnk2Nzchd6dQ2knKK2Hiuzy0PhV5HNwGTKLucas0ObClJ+ZQaw ZSwhzyMFFQmy9q4tgo5DNnqFWvEZ7lvpYBJeJHQMR7J9TknElCRPiwxppXCFLW9AYHbc +SBNYID0PgEPgSjeHHCXvMJeb8sIKYdVPu5EkZKdV3s6CquCQ3rkk03Iy7hwj0MJSE4b wuoQ== X-Received: by 10.180.75.115 with SMTP id b19mr1794876wiw.19.1384882972562; Tue, 19 Nov 2013 09:42:52 -0800 (PST) Received: from troma.lan (APuteaux-652-1-7-49.w82-124.abo.wanadoo.fr. [82.124.30.49]) by mx.google.com with ESMTPSA id qc10sm36551286wic.9.2013.11.19.09.42.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Nov 2013 09:42:51 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <57C3345230A4F94C9B2F5CFA05D7F2BD1D4ED850@xmb-rcd-x01.cisco.com> Date: Tue, 19 Nov 2013 19:42:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <659AA1B8-BA47-420F-A452-24DB776B3061@gmail.com> References: <11836.1384276281@sandelman.ca> <3673.1384528283@sandelman.ca> <70913413-2B68-4703-84E3-F7CC47E1A0E2@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AD9CDF7@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AD9D36C@xmb-rcd-x04.cisco.com> <57C3345230A4F94C9B2F5CFA05D7F2BD1D4ED850@xmb-rcd-x01.cisco.com> To: "Roberta Maglione (robmgl)" X-Mailer: Apple Mail (2.1510) 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 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 17:43:02 -0000 On Nov 19, 2013, at 7:10 PM, "Roberta Maglione (robmgl)" = 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.=20 - Jouni > Thanks > Roberta > =20 > From: Athanasios Douitsis [mailto:aduitsis@gmail.com]=20 > 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 > =20 > =20 > On Tue, Nov 19, 2013 at 6:42 PM, Bernie Volz (volz) = wrote: > This must be done by the delegation router (if you are talking about = the DHCPv6 packet itself) =96 as it is the one that constructs the = Advertise and Reply messages to the client. > =20 > Pardon me, I meant to wonder who should make the assignment, not who = should construct the packets. >=20 > 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. >=20 > Kind regards, > --=20 > Athanasios Douitsis >=20 >=20 From robmgl@cisco.com Tue Nov 19 09:47:55 2013 Return-Path: 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 53F0B1AE0AA; Tue, 19 Nov 2013 09:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.542 X-Spam-Level: X-Spam-Status: No, score=-8.542 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FRT_ADULT2=1.474, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, T_FRT_ADULT2=0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 J4sGW3uW95iE; Tue, 19 Nov 2013 09:47:54 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id C20011AE09B; Tue, 19 Nov 2013 09:47:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3213; q=dns/txt; s=iport; t=1384883268; x=1386092868; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=FM5v3tcATdWRHknCyVLpdVfSaQYXF3knK3Jg7voD/cI=; b=YGYZJ+H426IDsIQhixzKWZbu3xpiMNC9ABtgx3Uqc3spjvFPXRwEqMVc eDl+Nli5XyZeeo3o583JMT7GVqNB0t0L2uQ0k1maZZRr/U9UXx2e+GnSg Av+3VeYSoz8RgOarwIBQQJUMMT9QkojkvtESvSz6TgXCdUIFvLayeByP6 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAPaii1KtJV2b/2dsb2JhbABZgwc4U75wToEhFnSCJQEBAQMBAQEBJBM0CwUHBAIBCBEEAQEBChQJByEGCxQJCAIEDgUIh2cDCQYNtnENiEgTBIxjgkMxBwaDGoESA5QwgXeOQIU4gyiCKg X-IronPort-AV: E=Sophos;i="4.93,730,1378857600"; d="scan'208";a="665399" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-3.cisco.com with ESMTP; 19 Nov 2013 17:47:47 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAJHlluO008814 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Nov 2013 17:47:47 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.140]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0123.003; Tue, 19 Nov 2013 11:47:47 -0600 From: "Roberta Maglione (robmgl)" To: Jouni Korhonen Thread-Topic: [radext] [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation Thread-Index: AQHO5UXOsn3IR999/EelIBkBsrSMwJotJp4AgAACHQD//50pQIAAcasA//+cQSA= Date: Tue, 19 Nov 2013 17:47:46 +0000 Message-ID: <57C3345230A4F94C9B2F5CFA05D7F2BD1D4EDB99@xmb-rcd-x01.cisco.com> References: <11836.1384276281@sandelman.ca> <3673.1384528283@sandelman.ca> <70913413-2B68-4703-84E3-F7CC47E1A0E2@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AD9CDF7@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AD9D36C@xmb-rcd-x04.cisco.com> <57C3345230A4F94C9B2F5CFA05D7F2BD1D4ED850@xmb-rcd-x01.cisco.com> <659AA1B8-BA47-420F-A452-24DB776B3061@gmail.com> In-Reply-To: <659AA1B8-BA47-420F-A452-24DB776B3061@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.147.178] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 17:47:55 -0000 >That would be a trivial check in the RADIUS client, right? If the Framed-I= Pv6-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 =20 -----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 Richa= rdson; 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)" = wrote: > Hello, > I see your point. In my opinion if you would like to have all the prefixe= s assigned by RADIUS server in order to be able to cover the scenario you d= escribed in a clean way you would need a new RADIUS attribute for PD_EXCLUD= E. 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 - withou= t the PD_EXCLUDE) and the scenario you described where the prefix for the W= AN link is part of the PD and you need to copy it into the PD exclude optio= n. That would be a trivial check in the RADIUS client, right? If the Framed-IP= v6-Prefix falls into the Delegated-IPv6-Prefix, then you do the exclude, ot= herwise not. > Today the BNG (that in this case is acting both as RADIUS Client and Dele= gating Router) has no mean to know if the Framed-IPv6-Prefix should be use= d for the PD_EXCLUDE or not and in my opinion it would be better not overl= oad the sematic of the Framed-IPv6-Prefix. > Any comment? I would do the check rather than define a new attribute.=20 - Jouni > Thanks > Roberta > =20 > From: Athanasios Douitsis [mailto:aduitsis@gmail.com]=20 > 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 > =20 > =20 > On Tue, Nov 19, 2013 at 6:42 PM, Bernie Volz (volz) wrot= e: > 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. > =20 > Pardon me, I meant to wonder who should make the assignment, not who shou= ld construct the packets. >=20 > When you are using the Delegated-IPv6-Prefix AV pair, the delegating rout= er obviously constructs the packets with the delegated prefix value, but th= e 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. >=20 > Kind regards, > --=20 > Athanasios Douitsis >=20 >=20 _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aduitsis@gmail.com Tue Nov 19 11:27:44 2013 Return-Path: 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 ; 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> <3673.1384528283@sandelman.ca> <70913413-2B68-4703-84E3-F7CC47E1A0E2@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AD9CDF7@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AD9D36C@xmb-rcd-x04.cisco.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: From: Athanasios Douitsis To: "Roberta Maglione (robmgl)" Content-Type: multipart/alternative; boundary=e89a8f3b9c231e7efa04eb8ca8a0 Cc: "radext@ietf.org" , "Bernie Volz \(volz\)" , Michael Richardson , Jouni Korhonen , "dhcwg@ietf.org WG" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 19:27:44 -0000 --e89a8f3b9c231e7efa04eb8ca8a0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 =10(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) 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)" > 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 attribu= te > 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 us= ed > 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 f= or > the WAN link is part of the PD and you need to copy it into the PD exclud= e > 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) > wrote: > > This must be done by the delegation router (if you are talking about th= e > DHCPv6 packet itself) - as it is the one that constructs the Advertise an= d > 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 > --=20 Athanasios Douitsis --e89a8f3b9c231e7efa04eb8ca8a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

Thanks for the com= ments!

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

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

If, for example, the client is= not exclude-capable, then having the RADIUS return a Framed-IPv6-Prefix th= at is part of the =10(greater) Delegated-IPv6-Prefix is problematic for obv= ious reasons. In fact, I, for one, cannot wrap my head around a way to cove= r both cases (exclude-capable and non-exclude-capable) using only the two e= xisting RADIUS attributes *and* at the same time maintain backwards compati= bility with old customers.=A0

As suggested, one approach would be to define a new RADIUS attrib= ute (say IPv6-Excluded-Prefix) which would be used to enumerate the WAN (an= d 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-Ex= cluded-Prefix is used to enumerate the WAN, otherwise the normal avenue (Fr= amed-IPv6-Prefix or Framed-IPv6-Pool or Framed-IPv6-Address, etc) is follow= ed and the IPv6-Excluded-Prefix is ignored. And, admittedly, having to alwa= ys provide a Framed-IPv6-Prefix foreign to the Delegated-IPv6-Prefix kind o= f defeats the whole purpose of RFC6603 in some ways.

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

Kind regards,
Athanasios Douitsis






On Tue, Nov 19, 2013 at 7:47 PM, Ro= berta Maglione (robmgl) <robmgl@cisco.com> wrote:
>That would be a trivial check in the RAD= IUS 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-boun= ces@ietf.org] On Behalf Of Jouni Korhonen
Sent: Tuesday, November 19, 2013 12:43 PM
To: Roberta Maglione (robmgl)
Cc: radext@ietf.org; Athanasios Doui= tsis; Bernie Volz (volz); Michael Richardson; dhcwg@ietf.org WG; homenet@iet= f.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 pref= ixes assigned by RADIUS server in order to be able to cover the scenario yo= u described in a clean way you would need a new RADIUS attribute for PD_EXC= LUDE.

I am not sure I agree entirely.


> The reason why I think a new radius would be required is because you n= eed 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 - wit= hout the PD_EXCLUDE) and the scenario you described where the prefix for th= e WAN link is part of the PD and you need to copy it into the PD exclude op= tion.

That would be a trivial check in the RADIUS client, right? If the Framed-IP= v6-Prefix falls into the Delegated-IPv6-Prefix, then you do the exclude, ot= herwise not.


> Today the BNG (that in this case is acting both as RADIUS Client and D= elegating Router) has no mean to know if the =A0Framed-IPv6-Prefix should b= e used for the =A0PD_EXCLUDE or not and in my opinion it would be better no= t 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 Mag= lione (robmgl); dhcwg@ietf.org WG; Mi= chael 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 t= he DHCPv6 packet itself) - as it is the one that constructs the Advertise a= nd Reply messages to the client.
>
> Pardon me, I meant to wonder who should make the assignment, not who s= hould construct the packets.
>
> When you are using the Delegated-IPv6-Prefix AV pair, the delegating r= outer obviously constructs the packets with the delegated prefix value, but= the actual assignment has been done by the RADIUS server. By the same toke= n, I wondered whether it makes sense to do the same for the OPTION_PD_EXCLU= DE value.
>
> Kind regards,
> --
> Athanasios Douitsis
>
>

_______________________________________________
radext mailing list
radext@ietf.org
= https://www.ietf.org/mailman/listinfo/radext



--
Athanasios Douitsis
=

--e89a8f3b9c231e7efa04eb8ca8a0-- From jouni.nospam@gmail.com Wed Nov 20 00:55:16 2013 Return-Path: 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 374B01AC7EE; Wed, 20 Nov 2013 00:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.595 X-Spam-Level: X-Spam-Status: No, score=0.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, FRT_ADULT2=1.474, NML_ADSP_CUSTOM_MED=0.9, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, 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 3xZXd5sLOohD; Wed, 20 Nov 2013 00:55:14 -0800 (PST) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 72FF41AC4AB; Wed, 20 Nov 2013 00:55:13 -0800 (PST) Received: by mail-wg0-f44.google.com with SMTP id k14so8834935wgh.35 for ; Wed, 20 Nov 2013 00:55:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=nX56uyf0aZQE0PPGC9YPu4cgW+rs9fIkTwvo9jl2fKA=; b=b2Ujo9WoJrUOCO8SglgXNAvjNkd0+gZ6Lm9Cdaj1htZgGjNSMF+cdYTlli8NiWYB6Q oY+EGMchLNVCEf1El+eil8MMGBuOU3f4tWBB48z01TOxEUc6zmSfOVg3wUFo87ZvZOn2 6w+EvkL7tv4ZVoqZqiA9S6RBycjmG4skOiNBl7gwiUO9zvuFaAR8E7/rTefctOk0Q7+9 zI5Zzq9F87WrbikOT8mtWtaHhLzX6G1GPj8H7cbjXUSw+R+OWaztYwHzEWCTMc3r4ct3 SqYf8bUaGR61RlmSPL8NadecVL4e3lduHWWRJkTGQuBY3JalnMFrW3keVd0g6EDwwGE0 pgRg== X-Received: by 10.194.240.41 with SMTP id vx9mr184218wjc.70.1384937706782; Wed, 20 Nov 2013 00:55:06 -0800 (PST) Received: from [10.216.14.148] ([93.158.55.29]) by mx.google.com with ESMTPSA id f15sm29321609wik.6.2013.11.20.00.55.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Nov 2013 00:55:06 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: Date: Wed, 20 Nov 2013 10:55:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6EEC4A96-FD3B-47E8-AA6B-14A40BF1D983@gmail.com> References: <11836.1384276281@sandelman.ca> <3673.1384528283@sandelman.ca> <70913413-2B68-4703-84E3-F7CC47E1A0E2@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AD9CDF7@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AD9D36C@xmb-rcd-x04.cisco.com> <57C3345230A4F94C9B2F5CFA05D7F2BD1D4ED850@xmb-rcd-x01.cisco.com> <659AA1B8-BA47-420F-A452-24DB776B3061@gmail.com> <57C3345230A4F94C9B2F5CFA05D7F2BD1D4EDB99@xmb-rcd-x01.cisco.com> To: Athanasios Douitsis X-Mailer: Apple Mail (2.1510) Cc: "radext@ietf.org" , "Bernie Volz \(volz\)" , Michael Richardson , "Roberta Maglione \(robmgl\)" , "dhcwg@ietf.org WG" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 08:55:16 -0000 On Nov 19, 2013, at 9:27 PM, Athanasios Douitsis = wrote: > Hello, >=20 > Thanks for the comments!=20 >=20 > 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. =20 >=20 > 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. =20 >=20 > If, for example, the client is not exclude-capable, then having the = RADIUS return a Framed-IPv6-Prefix that is part of the =10(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. =20 I don't think having multiple attributes brings any additional value. = That would mean you allocate "just to be sure" a prefix from another = block. What I would do in this specific case is just to halve delegated = prefix and pick the single prefix from there and delegate the rest to = the client. That wastes half of the delegated prefix but I as a = delegating router am allowed to do so. This would make the = logic/provisioning on the RADIUS server and the client always the same. = The additional logic would be in the delegating router to device whether = it halves the delegated prefix or not. - Jouni > 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.=20 >=20 > Any comments on that? How do you believe the case of mixed clients = should be handled without breaking existing conventions?=20 >=20 > Kind regards, > Athanasios Douitsis >=20 >=20 >=20 >=20 >=20 >=20 > On Tue, Nov 19, 2013 at 7:47 PM, Roberta Maglione (robmgl) = 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. >=20 > Ok, you are right this is a way to do it. >=20 > Thanks > Roberta >=20 > -----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 >=20 >=20 > On Nov 19, 2013, at 7:10 PM, "Roberta Maglione (robmgl)" = wrote: >=20 > > 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. >=20 > I am not sure I agree entirely. >=20 >=20 > > 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. >=20 > 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. >=20 >=20 > > 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? >=20 > I would do the check rather than define a new attribute. >=20 > - Jouni >=20 >=20 > > 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) = 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 > > > > >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 >=20 >=20 > --=20 > Athanasios Douitsis >=20 >=20 From aduitsis@gmail.com Wed Nov 20 01:59:09 2013 Return-Path: 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 E8EF21AE17E; Wed, 20 Nov 2013 01:59:09 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 RJah140lgWSi; Wed, 20 Nov 2013 01:59:08 -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 30DCD1AE19D; Wed, 20 Nov 2013 01:59:08 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id at1so7206111iec.19 for ; Wed, 20 Nov 2013 01:59:01 -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=OhgoUXxJqxqHsU88EE3sRFQTCu5kfIgbvQ+5Qt4zL9o=; b=hkTFMycnnWzfMzZ/3QvoeZHd+P4Q6t8IJk1n69jqORn7bOmt9k82qjGCuvOywqOPP0 z4AETfWaHNUClXklfj1stNOFg/8ldbGTGotFYzNA7ZXLQTeZxj1B6d38PM2F2kLQ+xjD r+RohHxcewPn/wG8qr76ycdpTPLMZhT3PPDtCHMqtcuBvgdwZXugN6poyTEi4qAfKWeb 7tXFbrH8dv4Pk0OBPidJIjxiYZ5RawOBgzshL/7V8k65SNEI1wAsqjRwH+rjrdwupNyA MvUlJNn9yQgAn5i/GJgPutYGxrXBUB92Cy/9UJxRM9tECVpFRoEUeavrIkgQEAppgnN/ CQhw== MIME-Version: 1.0 X-Received: by 10.50.30.229 with SMTP id v5mr22595654igh.27.1384941541803; Wed, 20 Nov 2013 01:59:01 -0800 (PST) Received: by 10.64.227.168 with HTTP; Wed, 20 Nov 2013 01:59:01 -0800 (PST) In-Reply-To: <6EEC4A96-FD3B-47E8-AA6B-14A40BF1D983@gmail.com> References: <11836.1384276281@sandelman.ca> <3673.1384528283@sandelman.ca> <70913413-2B68-4703-84E3-F7CC47E1A0E2@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AD9CDF7@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AD9D36C@xmb-rcd-x04.cisco.com> <57C3345230A4F94C9B2F5CFA05D7F2BD1D4ED850@xmb-rcd-x01.cisco.com> <659AA1B8-BA47-420F-A452-24DB776B3061@gmail.com> <57C3345230A4F94C9B2F5CFA05D7F2BD1D4EDB99@xmb-rcd-x01.cisco.com> <6EEC4A96-FD3B-47E8-AA6B-14A40BF1D983@gmail.com> Date: Wed, 20 Nov 2013 11:59:01 +0200 Message-ID: From: Athanasios Douitsis To: Jouni Korhonen Content-Type: multipart/alternative; boundary=047d7bacc30ca24f7504eb98d4c3 Cc: "radext@ietf.org" , "Bernie Volz \(volz\)" , Michael Richardson , "Roberta Maglione \(robmgl\)" , "dhcwg@ietf.org WG" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 09:59:10 -0000 --047d7bacc30ca24f7504eb98d4c3 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 20, 2013 at 10:55 AM, Jouni Korhonen wrote: > I don't think having multiple attributes brings any additional value. That > would mean you allocate "just to be sure" a prefix from another block. What > I would do in this specific case is just to halve delegated prefix and pick > the single prefix from there and delegate the rest to the client. That > wastes half of the delegated prefix but I as a delegating router am allowed > to do so. This would make the logic/provisioning on the RADIUS server and > the client always the same. The additional logic would be in the delegating > router to device whether it halves the delegated prefix or not. Hello, Yes, using one prefix and halving it if necessary is simpler and more elegant from a certain point of view. Admittedly allocating "just to be sure" is by the same token ugly. The only downside that I'd like to mention is that many administrators generally like to do as much as possible in the RADIUS and rely on specialized router features as little as possible. Not only is it easier to add functionality and logic on the side of the RADIUS, but it makes one more standards compliant and vendor independent in case one would like to make a switch in the future. From that point of view, relying on the BNG to halve (or in any other way modify) the prefixes if necessary can be slightly disadvantageous. Especially if it is not possible to tell what eventually happened with the prefix(es), even by looking at the radius accounting records. My regards and thanks very much, -- Athanasios Douitsis --047d7bacc30ca24f7504eb98d4c3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

= On Wed, Nov 20, 2013 at 10:55 AM, Jouni Korhonen <jouni.nospam@gmail.= com> wrote:
I don't think having multiple attributes= brings any additional value. That would mean you allocate "just to be= sure" a prefix from another block. What I would do in this specific c= ase is just to halve delegated prefix and pick the single prefix from there= and delegate the rest to the client. That wastes half of the delegated pre= fix but I as a delegating router am allowed to do so. This would make the l= ogic/provisioning on the RADIUS server and the client always the same. The = additional logic would be in the delegating router to device whether it hal= ves the delegated prefix or not.

Hello,

Yes, using one prefix and halving it if necessary is simpl= er and more elegant from a certain point of view. Admittedly allocating &qu= ot;just to be sure" is by the same token ugly.

The o= nly downside that I'd like to mention is that many administrators gener= ally like to do as much as possible in the RADIUS and rely on specialized r= outer features as little as possible. Not only is it easier to add function= ality and logic on the side of the RADIUS, but it makes one more standards = compliant and vendor independent in case one would like to make a switch in= the future. From that point of view, relying on the BNG to halve (or in an= y other way modify) the prefixes if necessary can be slightly disadvantageo= us. Especially if it is not possible to tell what eventually happened with = the prefix(es), even by looking at the radius accounting records.

My regards and thanks very much,
--
Athanasios Douitsis


--047d7bacc30ca24f7504eb98d4c3-- From mcr@sandelman.ca Wed Nov 20 06:04:04 2013 Return-Path: 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 2EDB31ADF92; Wed, 20 Nov 2013 06:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, T_TVD_MIME_NO_HEADERS=0.01] autolearn=ham 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 XUphV83u88ls; Wed, 20 Nov 2013 06:04:02 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8411ADF8F; Wed, 20 Nov 2013 06:04:02 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id F3E8F2036E; Wed, 20 Nov 2013 10:16:25 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id B2C86A9042; Wed, 20 Nov 2013 09:03:52 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9E58CB8EBE; Wed, 20 Nov 2013 09:03:52 -0500 (EST) From: Michael Richardson To: "Roberta Maglione \(robmgl\)" In-Reply-To: <57C3345230A4F94C9B2F5CFA05D7F2BD1D4ED850@xmb-rcd-x01.cisco.com> References: <11836.1384276281@sandelman.ca> <3673.1384528283@sandelman.ca> <70913413-2B68-4703-84E3-F7CC47E1A0E2@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AD9CDF7@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AD9D36C@xmb-rcd-x04.cisco.com> <57C3345230A4F94C9B2F5CFA05D7F2BD1D4ED850@xmb-rcd-x01.cisco.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 Sender: mcr@sandelman.ca Cc: "radext@ietf.org" , Athanasios Douitsis , "Bernie Volz \(volz\)" , Jouni Korhonen , "dhcwg@ietf.org WG" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 14:04:04 -0000 --=-=-= Roberta Maglione (robmgl) wrote: > 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. > 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. If the DHCPv6 server that is constructing the PD can know what how the WAN link is numbered, then it can include the PD_EXCLUDE based upon a simple calculation. If one assumes the inclusion of the Framed-IPv6-Prefix in the DHCPv6 RADIUS option added by a relay, then even if the DHCPv6 is not co-located, it could know about the Framed-IPv6-Prefix. That might not cover all situations however, in particular, it won't cover cases where the WAN link was not numbered as a result of RADIUS attributes. Is a DHCP relay that isn't talking to a radius server allowed to synthesize that attribute, or do we need another way to do this? Or we are just overthinking things? Roberta, is PD_EXCLUDE widely implemented in CPEs that do 6204? -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUozBSIqHRg3pndX9AQL2zQP/SnzekPCA/jqf7ZCMqVlgEfCMRTChlzqz zSy/1I4olLShogxr8CJ4HaMX+K0xmqhAuczGF9n9mlpfMYXkuFqbSQ9ieSkNBFKS +2QHXCq5/vkc6H7Mswy4CSAk/6y6IJMF+kd8HbRLUAbXwx7exbGCPbq2hyYs7LoP 4h6DvNBP4fk= =upBt -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Wed Nov 20 06:08:48 2013 Return-Path: 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 DB8771ADFAC; Wed, 20 Nov 2013 06:08:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.942 X-Spam-Level: X-Spam-Status: No, score=-0.942 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADULT2=1.474, RP_MATCHES_RCVD=-0.525, 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 jOanfH6YKF-O; Wed, 20 Nov 2013 06:08:46 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 979141ADFA3; Wed, 20 Nov 2013 06:08:46 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 283982036E; Wed, 20 Nov 2013 10:21:10 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id D99A6A9042; Wed, 20 Nov 2013 09:08:36 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C3F22B8EBE; Wed, 20 Nov 2013 09:08:36 -0500 (EST) From: Michael Richardson To: Athanasios Douitsis In-Reply-To: References: <11836.1384276281@sandelman.ca> <3673.1384528283@sandelman.ca> <70913413-2B68-4703-84E3-F7CC47E1A0E2@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AD9CDF7@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AD9D36C@xmb-rcd-x04.cisco.com> <57C3345230A4F94C9B2F5CFA05D7F2BD1D4ED850@xmb-rcd-x01.cisco.com> <659AA1B8-BA47-420F-A452-24DB776B3061@gmail.com> <57C3345230A4F94C9B2F5CFA05D7F2BD1D4EDB99@xmb-rcd-x01.cisco.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 Sender: mcr@sandelman.ca Cc: "radext@ietf.org" , "Bernie Volz \(volz\)" , Jouni Korhonen , "Roberta Maglione \(robmgl\)" , "dhcwg@ietf.org WG" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 14:08:49 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Athanasios Douitsis wrote: > 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 fi= eld is > sufficient.=C2=A0 > But if there is a mix of PD_EXCLUDE-capable and not capable requestin= g clients, > the situation becomes more complex. The fundamental problem is that P= refix > Delegation usually happens after the RADIUS exchange, so the RADIUS s= erver > cannot really know whether the customer is exclude-capable or not.=C2= =A0 Note that CPEs ought to be smart enough to exclude the subnet that their WAN link is in, but it's certainly the case that many are not yet that smart. (the dnsmasq PD implementation was missing related smarts at first) > If, for example, the client is not exclude-capable, then having the R= ADIUS > 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 *a= nd* at the > same time maintain backwards compatibility with old customers. If the CPE is not EXCLUDE capable, and not smart enough to avoid the WAN link, then it doesn't matter what the set of attributes returned is, does i= t? Assuming simple minded prefix assignment by CPEs, if they start at subnet "1", then using subnet "0" probably works. But, using subnet "ff" for the WAN link is perhaps simpler. =2D- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUozCZIqHRg3pndX9AQKwuwP/Vk46OamLVMsguoZ0tKgKOt54z7PagaUJ PSuqG6yx9UThAzyAfLnztYHZtv7A2XLrSKLsTAil99mQ/DrU2XJDWVfUCpfnfrgV TjVUaNP2+xYHzoiHQ2x7qwAbFmMqmI+d3pRSOceWpzkTztqKXBcyKjqjyVRjGlyX qSUrAGASCn0= =71Ei -----END PGP SIGNATURE----- --=-=-=-- From aduitsis@gmail.com Wed Nov 20 06:59:13 2013 Return-Path: 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 BA4901AE338; Wed, 20 Nov 2013 06:59:13 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 dElmJAF3d4qb; Wed, 20 Nov 2013 06:59:11 -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 7E5051ADFF5; Wed, 20 Nov 2013 06:59:11 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id at1so7722517iec.19 for ; Wed, 20 Nov 2013 06:59:05 -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=iSBe4EBGoMAlAaqRzs66aHCBQUmtr4XCSeQBkowbwfc=; b=kgJMaewIY1+O5Fec7hEcwYyVBw6dA5PeZj6vX5YMUeKqEfak+SLZdfOp74oDD1ofjV K34EvZAJX+JY8fCskK9j6sTtFMHp6V2FqpEmUYvxa23PUCtOAlX+XO0Umn4b1FuD7kY/ +GkHmIiO3W73hUyLKjNNp0As8idfoOIb8DxeDy/WZ9cL8uVTLfpsmhUpvPdcQTSajD3n FSBuogxsa6Y8hhwSdJyfGtJftKRZOwtx/mt4uf3TEeLOIQfIR2hSAbuGAAwSifYeDXXM YOJnCyb3I+NXuWY6CFwE8sOkc2NwWDpZU3/Hus+I+WRZLfAp3ZLWtkSbGr8CCMf96tv4 HIyA== MIME-Version: 1.0 X-Received: by 10.43.98.202 with SMTP id cp10mr732967icc.28.1384959544995; Wed, 20 Nov 2013 06:59:04 -0800 (PST) Received: by 10.64.227.168 with HTTP; Wed, 20 Nov 2013 06:59:04 -0800 (PST) In-Reply-To: <14253.1384956516@sandelman.ca> References: <11836.1384276281@sandelman.ca> <3673.1384528283@sandelman.ca> <70913413-2B68-4703-84E3-F7CC47E1A0E2@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AD9CDF7@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AD9D36C@xmb-rcd-x04.cisco.com> <57C3345230A4F94C9B2F5CFA05D7F2BD1D4ED850@xmb-rcd-x01.cisco.com> <659AA1B8-BA47-420F-A452-24DB776B3061@gmail.com> <57C3345230A4F94C9B2F5CFA05D7F2BD1D4EDB99@xmb-rcd-x01.cisco.com> <14253.1384956516@sandelman.ca> Date: Wed, 20 Nov 2013 16:59:04 +0200 Message-ID: From: Athanasios Douitsis To: Michael Richardson Content-Type: multipart/alternative; boundary=bcaec5171911b53e4d04eb9d0569 Cc: "radext@ietf.org" , "Bernie Volz \(volz\)" , Jouni Korhonen , "Roberta Maglione \(robmgl\)" , "dhcwg@ietf.org WG" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 14:59:14 -0000 --bcaec5171911b53e4d04eb9d0569 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 20, 2013 at 4:08 PM, Michael Richardson wrote: > Athanasios Douitsis wrote: > > 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. > > Note that CPEs ought to be smart enough to exclude the subnet that their > WAN > link is in, but it's certainly the case that many are not yet that smart. > (the dnsmasq PD implementation was missing related smarts at first) > > > 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. > > If the CPE is not EXCLUDE capable, and not smart enough to avoid the WAN > link, then it doesn't matter what the set of attributes returned is, does > it? > Assuming simple minded prefix assignment by CPEs, if they start at subnet > "1", then using subnet "0" probably works. But, using subnet "ff" for the > WAN link is perhaps simpler. Hello Michael, When I said "problematic" yesterday, I meant problematic for the delegating router. If the other side (requesting router - CPE) is not exclude-capable then is it not illegal for the delegating router to delegate a prefix and at the same time use part of it to enumerate one its interfaces? So a set of attributes where the Framed-IPv6-Prefix is contained in the Delegated-IPv6-Prefix may result in error. Apologies if I didn't understand correctly what you are saying. Kind regards, -- Athanasios Douitsis --bcaec5171911b53e4d04eb9d0569 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Nov 20, 2013 at 4:08 PM, Michael R= ichardson <mcr+ietf@sandelman.ca> wrote:
Athanasios Douitsis <aduitsis@gmail.com> wrote:
=A0 =A0 > Indeed in a scenario where all the requesting routers connecti= ng to a
=A0 =A0 > delegating router (BNG) would have PD_EXCLUDE capability, usin= g the
=A0 =A0 > Framed-IPv6-Prefix to infer what to put into the OPTION_PD_EXC= LUDE field is
=A0 =A0 > sufficient.=A0

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

Note that CPEs ought to be smart enough to exclude the subnet that th= eir WAN
link is in, but it's certainly the case that many are not yet that smar= t.
(the dnsmasq PD implementation was missing related smarts at first)

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

If the CPE is not EXCLUDE capable, and not smart enough to avoid the = WAN
link, then it doesn't matter what the set of attributes returned is, do= es it?
Assuming simple minded prefix assignment by CPEs, if they start at subnet "1", then using subnet "0" probably works. =A0But, usin= g subnet "ff" for the
WAN link is perhaps simpler.


Hello Michael,

<= div class=3D"gmail_extra">When I said "problematic" yesterday, I = meant problematic for the delegating router. If the other side (requesting = router - CPE) is not exclude-capable then is it not illegal for the delegat= ing router to delegate a prefix and at the same time use part of it to enum= erate one its interfaces? So a set of attributes where the Framed-IPv6-Pref= ix is contained in the Delegated-IPv6-Prefix may result in error.

Apologies if I didn't understand c= orrectly what you are saying.

Kind= regards,
--
Athanasios Douitsis

--bcaec5171911b53e4d04eb9d0569-- From mcr@sandelman.ca Wed Nov 20 08:04:02 2013 Return-Path: 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 E5FBC1AE45F; Wed, 20 Nov 2013 08:04:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.932 X-Spam-Level: X-Spam-Status: No, score=-0.932 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FRT_ADULT2=1.474, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, T_FRT_ADULT2=0.01, T_TVD_MIME_NO_HEADERS=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 Li7E2DaUFKmo; Wed, 20 Nov 2013 08:04:01 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB811AE436; Wed, 20 Nov 2013 08:04:01 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 96D6B20049; Wed, 20 Nov 2013 12:16:23 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 975C663B87; Wed, 20 Nov 2013 11:03:49 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8A8A563848; Wed, 20 Nov 2013 11:03:49 -0500 (EST) From: Michael Richardson To: Athanasios Douitsis In-Reply-To: References: <11836.1384276281@sandelman.ca> <3673.1384528283@sandelman.ca> <70913413-2B68-4703-84E3-F7CC47E1A0E2@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AD9CDF7@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AD9D36C@xmb-rcd-x04.cisco.com> <57C3345230A4F94C9B2F5CFA05D7F2BD1D4ED850@xmb-rcd-x01.cisco.com> <659AA1B8-BA47-420F-A452-24DB776B3061@gmail.com> <57C3345230A4F94C9B2F5CFA05D7F2BD1D4EDB99@xmb-rcd-x01.cisco.com> <14253.1384956516@sandelman.ca> 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 Sender: mcr@sandelman.ca Cc: "radext@ietf.org" , "Bernie Volz \(volz\)" , Jouni Korhonen , "Roberta Maglione \(robmgl\)" , "dhcwg@ietf.org WG" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 16:04:03 -0000 --=-=-= Athanasios Douitsis wrote: > Hello Michael, > When I said "problematic" yesterday, I meant problematic for the delegating > router. If the other side (requesting router - CPE) is not exclude-capable then > is it not illegal for the delegating router to delegate a prefix and at the > same time use part of it to enumerate one its interfaces? So a set of > attributes where the Framed-IPv6-Prefix is contained in the > Delegated-IPv6-Prefix may result in error. How could a BNG know if the requesting router is exclude capable? Would this by having the option in the DHCPv6 Request list? If the WAN was numbered by RA, then I guess the DHCPv6 server would have to do the split prefix in half trick. -- Michael Richardson , Sandelman Software Works --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUozdZYqHRg3pndX9AQKSCAQAyp5y8FDjT2y04LSfb2Lv7K8E1Ay32kYU +3wttYsLQSFnPNIxsVpN4SroGv8QsYiEruLOyCg1IzxhMIJqNI1lFKTdOuwuu9TJ YZZpF3DoRHx+Y4dpysPIpkANYJUynIYRPg7gBr0k4KntHyoZtk2V4IX+utBOaNIj bokAiuSkfbs= =Gpt7 -----END PGP SIGNATURE----- --=-=-=-- From aduitsis@gmail.com Wed Nov 20 09:07:50 2013 Return-Path: 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 703B11AE493; Wed, 20 Nov 2013 09:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.889 X-Spam-Level: X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_PASS=-0.001, T_DKIM_INVALID=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 kZ6FS7bv6qWx; Wed, 20 Nov 2013 09:07:49 -0800 (PST) Received: from mail-ea0-x235.google.com (mail-ea0-x235.google.com [IPv6:2a00:1450:4013:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id BA5D51AE491; Wed, 20 Nov 2013 09:07:48 -0800 (PST) Received: by mail-ea0-f181.google.com with SMTP id m10so1806852eaj.26 for ; Wed, 20 Nov 2013 09:07:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=4SqieVkaOmxNyvHs5zt3lH4sOQLOndMgOq2FRt1CvDg=; b=feAs9ZBhy/UMy8bJsngOuhO4LF7waDqVi/aPM5dYyP8bIPJu1+PdX1XMwrzOr8T4Uh hqeqcqRIZ8ibezYx++gRiUznh6ZmPSvFQG61Cpm8LAGrrpYdtLYJWmvwlaPZUxnuXMso vRnjnz50m3akeEvBpXg3byU4i2KMaDdkrKXbFFdeFa5pW6Lco6iMkrzouqWrKDK4jo1w QDZchfgP5WYTDxOSs2Mgio7Fp0JeVTyrgkxkSaPq92zULlvaapmTKvQGSKyWdZGUP1E2 3+pLESVqs/xzQXf0FqvLLCI+o2K7a3cyU8lpVOmiOJUVu1agRQnGojXWepRW9TPQqzn/ hawA== X-Received: by 10.15.26.131 with SMTP id n3mr2254074eeu.21.1384967261940; Wed, 20 Nov 2013 09:07:41 -0800 (PST) Received: from [192.168.2.205] (dsl-aausbo.dyn.edudsl.gr. [37.32.156.228]) by mx.google.com with ESMTPSA id 8sm61971100eem.15.2013.11.20.09.07.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 20 Nov 2013 09:07:40 -0800 (PST) References: <11836.1384276281@sandelman.ca> <3673.1384528283@sandelman.ca> <70913413-2B68-4703-84E3-F7CC47E1A0E2@cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AD9CDF7@xmb-rcd-x04.cisco.com> <489D13FBFA9B3E41812EA89F188F018E1AD9D36C@xmb-rcd-x04.cisco.com> <57C3345230A4F94C9B2F5CFA05D7F2BD1D4ED850@xmb-rcd-x01.cisco.com> <659AA1B8-BA47-420F-A452-24DB776B3061@gmail.com> <57C3345230A4F94C9B2F5CFA05D7F2BD1D4EDB99@xmb-rcd-x01.cisco.com> <14253.1384956516@sandelman.ca> <11482.1384963429@sandelman.ca> Mime-Version: 1.0 (1.0) In-Reply-To: <11482.1384963429@sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPad Mail (11B554a) From: Athanasios Douitsis Date: Wed, 20 Nov 2013 19:07:38 +0200 To: Michael Richardson Cc: "radext@ietf.org" , "Bernie Volz \(volz\)" , Jouni Korhonen , "Roberta Maglione \(robmgl\)" , "dhcwg@ietf.org WG" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 17:07:50 -0000 20 =CE=9D=CE=BF=CE=B5 2013, 6:03 =CE=BC.=CE=BC., =CE=BF/=CE=B7 Michael Richa= rdson =CE=AD=CE=B3=CF=81=CE=B1=CF=88=CE=B5: >=20 > Athanasios Douitsis wrote: >> Hello Michael, >=20 >> When I said "problematic" yesterday, I meant problematic for the delegati= ng >> router. If the other side (requesting router - CPE) is not exclude-capabl= e then >> is it not illegal for the delegating router to delegate a prefix and at t= he >> same time use part of it to enumerate one its interfaces? So a set of >> attributes where the Framed-IPv6-Prefix is contained in the >> Delegated-IPv6-Prefix may result in error. >=20 > How could a BNG know if the requesting router is exclude capable? >=20 > Would this by having the option in the DHCPv6 Request list? Yes.=20 >=20 > If the WAN was numbered by RA, then I guess the DHCPv6 server would have t= o > do the split prefix in half trick. >=20 Yes, that was suggested by Jouni previously.=20 >=20 > -- > Michael Richardson , Sandelman Software Works >=20 >=20 From internet-drafts@ietf.org Wed Nov 20 23:17:22 2013 Return-Path: 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 842CA1AE0FA; Wed, 20 Nov 2013 23:17:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 f73GuLmwSmI2; Wed, 20 Nov 2013 23:17:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B43F1AE0CF; Wed, 20 Nov 2013 23:17:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131121071721.9544.67558.idtracker@ietfa.amsl.com> Date: Wed, 20 Nov 2013 23:17:21 -0800 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-radius-fragmentation-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 07:17:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of the IE= TF. Title : Support of fragmentation of RADIUS packets Author(s) : Alejandro Perez-Mendez Rafa Marin-Lopez Fernando Pereniguez-Garcia Gabriel Lopez-Millan Diego R. Lopez Alan DeKok Filename : draft-ietf-radext-radius-fragmentation-02.txt Pages : 28 Date : 2013-11-20 Abstract: The Remote Authentication Dial-In User Service (RADIUS) protocol is limited to a total packet size of 4096 octets. Provisions exist for fragmenting large amounts of authentication data across multiple packets, via Access-Challenge. No similar provisions exist for fragmenting large amounts of authorization data. This document specifies how existing RADIUS mechanisms can be leveraged to provide that functionality. These mechanisms are largely compatible with existing implementations, and are designed to be invisible to proxies, and "fail-safe" to legacy clients and servers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-radius-fragmentation-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-radius-fragmentation-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From alex@um.es Wed Nov 20 23:25:01 2013 Return-Path: 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 CE2181AE107 for ; Wed, 20 Nov 2013 23:25:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.725 X-Spam-Level: X-Spam-Status: No, score=-4.725 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham 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 2nBS0BWBglHX for ; Wed, 20 Nov 2013 23:24:59 -0800 (PST) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id AC4751AE105 for ; Wed, 20 Nov 2013 23:24:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 948824BF08 for ; Thu, 21 Nov 2013 08:24:50 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 0gxvSKHQCQ0e for ; Thu, 21 Nov 2013 08:24:50 +0100 (CET) Received: from [10.42.0.18] (84.124.131.72.dyn.user.ono.com [84.124.131.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon12.um.es (Postfix) with ESMTPSA id 11FEA4BD90 for ; Thu, 21 Nov 2013 08:24:47 +0100 (CET) Message-ID: <528DB53D.3070502@um.es> Date: Thu, 21 Nov 2013 08:24:45 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "radext@ietf.org" References: <20131121071721.9544.67558.idtracker@ietfa.amsl.com> In-Reply-To: <20131121071721.9544.67558.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------060408000802080007080502" Subject: Re: [radext] I-D Action: draft-ietf-radext-radius-fragmentation-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 07:25:02 -0000 This is a multi-part message in MIME format. --------------060408000802080007080502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Dear WG members, we've uploaded a new version of the RADIUS fragmentation draft. This version addresses what was discussed during the last IETF meeting: 1. Reintroduce 2 missing paragraphs that were deleted by mistake at the end of section 2. 2. Establish a stronger statement forbidding the transmission of more than 100K of data, to avoid turning RADIUS into a stream-oriented transport protocol, such as TCP or SCTP. As discussed in the meeting, we think this document is now ready for Last Call. Regards, Alejandro El 21/11/13 08:17, internet-drafts@ietf.org escribió: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the RADIUS EXTensions Working Group of the IETF. > > Title : Support of fragmentation of RADIUS packets > Author(s) : Alejandro Perez-Mendez > Rafa Marin-Lopez > Fernando Pereniguez-Garcia > Gabriel Lopez-Millan > Diego R. Lopez > Alan DeKok > Filename : draft-ietf-radext-radius-fragmentation-02.txt > Pages : 28 > Date : 2013-11-20 > > Abstract: > The Remote Authentication Dial-In User Service (RADIUS) protocol is > limited to a total packet size of 4096 octets. Provisions exist for > fragmenting large amounts of authentication data across multiple > packets, via Access-Challenge. No similar provisions exist for > fragmenting large amounts of authorization data. This document > specifies how existing RADIUS mechanisms can be leveraged to provide > that functionality. These mechanisms are largely compatible with > existing implementations, and are designed to be invisible to > proxies, and "fail-safe" to legacy clients and servers. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-radext-radius-fragmentation-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-radius-fragmentation-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --------------060408000802080007080502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear WG members,

we've uploaded a new version of the RADIUS fragmentation draft. This version addresses what was discussed during the last IETF meeting:
  1. Reintroduce 2 missing paragraphs that were deleted by mistake at the end of section 2.
  2. Establish a stronger statement forbidding the transmission of more than 100K of data, to avoid turning RADIUS into a stream-oriented transport protocol, such as TCP or SCTP.

As discussed in the meeting, we think this document is now ready for Last Call.

Regards,
Alejandro

El 21/11/13 08:17, internet-drafts@ietf.org escribió:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the RADIUS EXTensions Working Group of the IETF.

	Title           : Support of fragmentation of RADIUS packets
	Author(s)       : Alejandro Perez-Mendez
                          Rafa Marin-Lopez
                          Fernando Pereniguez-Garcia
                          Gabriel Lopez-Millan
                          Diego R. Lopez
                          Alan DeKok
	Filename        : draft-ietf-radext-radius-fragmentation-02.txt
	Pages           : 28
	Date            : 2013-11-20

Abstract:
   The Remote Authentication Dial-In User Service (RADIUS) protocol is
   limited to a total packet size of 4096 octets.  Provisions exist for
   fragmenting large amounts of authentication data across multiple
   packets, via Access-Challenge.  No similar provisions exist for
   fragmenting large amounts of authorization data.  This document
   specifies how existing RADIUS mechanisms can be leveraged to provide
   that functionality.  These mechanisms are largely compatible with
   existing implementations, and are designed to be invisible to
   proxies, and "fail-safe" to legacy clients and servers.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-radext-radius-fragmentation-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-radius-fragmentation-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext

--------------060408000802080007080502--