From tjc@ecs.soton.ac.uk Mon Nov 4 16:51:41 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 169D121F9CFB; Mon, 4 Nov 2013 16:51:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HTML_MESSAGE=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 z9YATGwEFqpR; Mon, 4 Nov 2013 16:51:39 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id D5A5121F9CED; Mon, 4 Nov 2013 16:49:44 -0800 (PST) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rA50nFiF006677; Tue, 5 Nov 2013 00:49:15 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk rA50nFiF006677 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1383612556; bh=kD1Mnhpch31U63iJDnFlMekat0k=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=4EZcnskNgXLA6JW/u9KOe/j3+/QB3eT4xmH1PHTlfS6zQp14jiTR4Wnoxu+L2fDjl /FI7i5zQMx8RssaIyI5WfRwmUasug+wVAAnqXBwDqajvs4Hyf0AZlAX/ynJODvmvZd UBZ2RG1e/wdlnA2fyKaiwM2iOUlNbixuEVPli7EU= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id pA40nF09596347704z ret-id none; Tue, 05 Nov 2013 00:49:15 +0000 Received: from wireless-v6.meeting.ietf.org (wireless-v6.meeting.ietf.org [IPv6:2001:67c:370:160:dc36:f9fb:865b:22c5] (may be forged)) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id rA50l6Lw007907 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 5 Nov 2013 00:48:55 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_DE41C7E7-E82D-40D8-86C2-FAF1DD5DAE2E" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Tim Chown In-Reply-To: Date: Tue, 5 Nov 2013 00:48:54 +0000 Message-ID: References: <6A3161F9-AD16-4305-8690-D530511DCFE8@ecs.soton.ac.uk> To: Dave Cridland X-Mailer: Apple Mail (2.1816) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=pA40nF095963477000; tid=pA40nF09596347704z; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=7:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: rA50nFiF006677 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "" , S Moonesamy , The IESG , draft-ietf-homenet-arch.all@tools.ietf.org, "homenet@ietf.org Group" , Ted Lemon Subject: Re: [homenet] APPSDIR review of draft-ietf-homenet-arch-10 X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 00:51:41 -0000 --Apple-Mail=_DE41C7E7-E82D-40D8-86C2-FAF1DD5DAE2E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 19 Sep 2013, at 14:24, Dave Cridland wrote: > Ted Lemon wrote: >> On Sep 19, 2013, at 6:59 AM, S Moonesamy = wrote: >> > The Chairs have already agreed about the five topics to be = covered. It's not a problem. The next step would be to take these = topics, make them accessible to the average reader, and organize = them. This may require avoiding too many details if it is doable. >>=20 >> I think that you are interpreting this document to be something that = it is not, and cannot yet be. What this document is is an architecture = for the homenet working group=97a crib sheet that tells us what we are = trying to accomplish. I don't think it's intended to be something that = a random person who is not implementing home gateways would find useful. = The working group is hoping that subsequent versions of this document = will evolve over time, and I think it would be good for the working = group to evolve the document into something that meets the goals that = you've set out above. >>=20 >> However, I think that if the working group attempts to do that now, = two things will happen. First, the working group won't actually get to = the work it's supposed to be doing, because completing the architecture = document will continue to be an all-consuming effort. Second, the = document that is produced will be purely theoretical, not based on = actual practice, and probably useless. >>=20 >> So I would like you to consider whether you can accept this = restatement of the purpose of the document. Do you feel that this = document cannot be of use until it meets the goals you've set out above, = or does the different purpose I've expressed here make sense to you? = If the latter, can you reconsider your review in light of this new = stated purpose for the document? Is part of the problem that the goals = of the document are poorly expressed in the document? Given the goals = I've stated, do all of your comments still apply, or would you have = responded differently to the document if you'd been evaluating it on the = basis I'm proposing? >>=20 > Then the title ought to call itself Requirements, or Proposed, or = something. >=20 > Actually, I genuinely struggle to understand the purpose of publishing = documents which are intended as working documents for a particular = Working Group as an RFC, but on the basis that it's required for some = reason I don't understand, then calling it the "Home Networking = Architecture for IPv6" is confusing - I read that, perhaps terribly = naively, as being a document defining the Home Networking Architecture = for IPv6. Partly because, right at the top, it says "The goal of this = document is to define a general architecture for IPv6-based home = networking". It really had me fooled. >=20 > I appreciate I'm obviously foolish and easily mislead, but perhaps = calling entitling it "Architectural Requirements for IPv6 Home = Networking", or "Proposals and Considerations for Home Networking = Architecture for IPv6", might give the reader the hint that it's not = defining an architecture as such. >=20 > Dave. The title was amended slightly for -11: The diff for the -11 is available here: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-homenet-arch-11.txt Tim= --Apple-Mail=_DE41C7E7-E82D-40D8-86C2-FAF1DD5DAE2E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 19 Sep 2013, at 14:24, Dave = Cridland <dave@cridland.net> = wrote:

Ted Lemon wrote:
On Sep 19, = 2013, at 6:59 AM, S Moonesamy <sm+ietf@elandsys.com> = wrote:
   > The Chairs have already agreed about = the five topics to be covered.     It's not a = problem.  The next step would be to take these topics, make =     them accessible to the average reader, and = organize them.  This may     require avoiding = too many details if it is doable.

I think that you are = interpreting this document to be something that it is not, and cannot = yet be.   What this document is is an architecture for the = homenet working group=97a crib sheet that tells us what we are trying to = accomplish.   I don't think it's intended to be something that = a random person who is not implementing home gateways would find useful. =   The working group is hoping that subsequent versions of this = document will evolve over time, and I think it would be good for the = working group to evolve the document into something that meets the goals = that you've set out above.

However, I think that if the working = group attempts to do that now, two things will happen.  First, the = working group won't actually get to the work it's supposed to be doing, = because completing the architecture document will continue to be an = all-consuming effort.   Second, the document that is produced = will be purely theoretical, not based on actual practice, and probably = useless.

So I would like you to consider whether you can accept = this restatement of the purpose of the document.   Do you feel = that this document cannot be of use until it meets the goals you've set = out above, or does the different purpose I've expressed here make sense = to you?   If the latter, can you reconsider your review in = light of this new stated purpose for the document? Is part of the = problem that the goals of the document are poorly expressed in the = document?   Given the goals I've stated, do all of your = comments still apply, or would you have responded differently to the = document if you'd been evaluating it on the basis I'm = proposing?

Then the title ought to call itself = Requirements, or Proposed, or something.

Actually, I genuinely = struggle to understand the purpose of publishing documents which are = intended as working documents for a particular Working Group as an RFC, = but on the basis that it's required for some reason I don't understand, = then calling it the "Home Networking Architecture for IPv6" is confusing = - I read that, perhaps terribly naively, as being a document defining = the Home Networking Architecture for IPv6. Partly because, right at the = top, it says "The goal of this document is to define a general = architecture for IPv6-based home networking". It really had me = fooled.

I appreciate I'm obviously foolish and easily mislead, = but perhaps calling entitling it "Architectural Requirements for IPv6 = Home Networking", or "Proposals and Considerations for Home Networking = Architecture for IPv6", might give the reader the hint that it's not = defining an architecture as = such.

Dave.

The title was amended = slightly for -11:

Tim
= --Apple-Mail=_DE41C7E7-E82D-40D8-86C2-FAF1DD5DAE2E-- From mark@townsley.net Mon Nov 4 23:05:57 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97A811E8178 for ; Mon, 4 Nov 2013 23:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 SVUu0XUmndRJ for ; Mon, 4 Nov 2013 23:05:50 -0800 (PST) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by ietfa.amsl.com (Postfix) with ESMTP id C5FFE21F9E00 for ; Mon, 4 Nov 2013 23:05:50 -0800 (PST) Received: by mail-pa0-f46.google.com with SMTP id rd3so8196213pab.19 for ; Mon, 04 Nov 2013 23:05:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version; bh=1elREj2uopNZJN0iaTDG1lzFdGVlVEW+VajQj2jBR9g=; b=I5bn2Wu4mx62r+w0KkOpgZg8ox8cck7uG9rVNd6gHTrFth982KWv+IbsqJPjuGb6F6 hrZ/yJtZTy1utO5KV+4h5Z1Eb2Dvpl2qnitVxISWdcPkCNvQJufQyse7zuNXz5nhG6Np VijRmGels2w/84CRV1ePTge/Kl20hkO5ULji+kAd+VtzXWiVovsTQdCGMl2l4vxxojrj TbaPrBhgV3spZ9r9+fBkYGg3ZQZ7Rio94KCNOk2Kbach1pRhhNleg73zDyo/biAqdSCi VpcvW5/YwrH2UBgqxwue4UQ480WpVMfxuq47KOIFUgq/oe0CQNYDrhdsYQ3kRGrGEBnf mkww== X-Gm-Message-State: ALoCoQk6+ph6ORI9GTSX0OmjwlYc49W9/8BNWJCDsoAujCerH5E5+48mP/6kr/dt1BUHDfmSmd3U X-Received: by 10.66.162.73 with SMTP id xy9mr203262pab.172.1383635148059; Mon, 04 Nov 2013 23:05:48 -0800 (PST) Received: from wmt.lan (99.173.119.66.static.metrobridge.net. [66.119.173.99]) by mx.google.com with ESMTPSA id ja5sm32570229pbc.14.2013.11.04.23.05.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Nov 2013 23:05:47 -0800 (PST) From: Mark Townsley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Nov 2013 23:05:46 -0800 Message-Id: To: "homenet@ietf.org Group" Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [homenet] draft-baker-rtgwg-src-dst-routing-use-cases-00 in the rtgwg today X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 07:05:57 -0000 Was anyone on this list able to attend the rtgwg meeting today where = Fred presented draft-baker-rtgwg-src-dst-routing-use-cases-00? I missed = it, and would be interested in the reaction, feedback, or next steps (if = any). Thanks, - Mark= From acee.lindem@ericsson.com Tue Nov 5 06:40:10 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9100E21E82C4; Tue, 5 Nov 2013 06:40:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=-0.047, 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 HHF8b4ElR2v9; Tue, 5 Nov 2013 06:39:57 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFAE21F9EF2; Tue, 5 Nov 2013 06:39:37 -0800 (PST) X-AuditID: c618062d-b7fd88e00000439f-9e-5279030e0e1c Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 70.D2.17311.E0309725; Tue, 5 Nov 2013 15:39:10 +0100 (CET) Received: from EUSAAMB106.ericsson.se ([147.117.188.123]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Tue, 5 Nov 2013 09:39:10 -0500 From: Acee Lindem To: Mark Townsley , "homenet@ietf.org Group" , "Fred Baker (fred)" Thread-Topic: [homenet] draft-baker-rtgwg-src-dst-routing-use-cases-00 in the rtgwg today Thread-Index: AQHO2jTJGWWoQUJXR0KPq+/59bDixA== Date: Tue, 5 Nov 2013 14:39:09 +0000 Message-ID: <94A203EA12AECE4BA92D42DBFFE0AE47030C88C1@eusaamb106.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.6.130613 x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <71C2100729DED442BE0CA125754DEC36@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUyuXRPrC4fc2WQwYfVNhbv151hs3i/6BCL xbQDD5gsLrz5zezA4jHl90ZWjyVLfjJ53J82kSmAOYrLJiU1J7MstUjfLoErY8a6IywFb9kr 7i0Wb2A8wNbFyMkhIWAicevvVXYIW0ziwr31QHEuDiGBI4wSM9/NYIRwljFK/N/yhhGkik1A R+L5o3/MILaIQJXEvp6NrCA2s4C8xNmrq8FqhAWiJPqWbYeqiZZYf/EAK4StJ3G18QALiM0i oCLx4vM5sBpeAV+J86+WgF3BKeAgsfTDMrAaRqCLvp9awwQxX1zi1pP5TBCXCkgs2XOeGcIW lXj5+B/YfFGg+d2zlrNCxJUlljzZzwLRqyOxYPcnoM84gGxribcNlhBhbYllC19DnSAocXLm E5YJjOKzkGybhaR7FkL3LCTds5B0L2BkXcXIUVqcWpabbmSwiREYb8ck2HR3MO55aXmIUZqD RUmc98tb5yAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjLqftTT0BAp5mqdJMue9undT9aDq o79+p7uzIn+xOZw54Kew8eyuMxstOY6edPhh2eEbOa9z8wO5FQIt/tmaMl9VZc/OF9q3o3zF 3Pk37uVWP9PZafSq69T7e14zFM7/cXBw5t0o/iMtK6+9Su1gKO+kia9PvhHb571lsouOMd/2 2QE1r5ZKeCmxFGckGmoxFxUnAgBqG2xXhQIAAA== Cc: Routing WG Subject: Re: [homenet] draft-baker-rtgwg-src-dst-routing-use-cases-00 in the rtgwg today X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 14:40:10 -0000 Hi Mark, I attended and the majority of the discussion centered on whether the problem could be solved with a simpler model such as a FIB per provider. Fred pointed out that this would not handle overlapping source subnets and the fact that it was possible to solve the general problem with a Patricia tree and the installation disambiguating routes. Alvaro also commented that there are use cases beyond homenet. As you'd expect, the next step was that there needs to be more discussion on the RTG WG list (copied). Thanks, Acee On 11/4/13 11:05 PM, "Mark Townsley" wrote: > >Was anyone on this list able to attend the rtgwg meeting today where Fred >presented draft-baker-rtgwg-src-dst-routing-use-cases-00? I missed it, >and would be interested in the reaction, feedback, or next steps (if any). > >Thanks, > >- Mark >_______________________________________________ >homenet mailing list >homenet@ietf.org >https://www.ietf.org/mailman/listinfo/homenet From fred@cisco.com Tue Nov 5 07:20:08 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F51C11E81FD; Tue, 5 Nov 2013 07:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.53 X-Spam-Level: X-Spam-Status: No, score=-110.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 H0Ets39VHFNk; Tue, 5 Nov 2013 07:20:03 -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 5771A11E80FB; Tue, 5 Nov 2013 07:20:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1973; q=dns/txt; s=iport; t=1383664803; x=1384874403; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DI2qAnMM2yNZQk7jPEyzo+5c9nXlm2MOcdtHRtAVVEM=; b=mmaT9l6zpfwlmQhGcCMhTp5x7Yqzs6io6zD/mUQUm/KilSXdSafju2WL uikuQZEtKFQvwx972t5zxn3omZBpv74b+FBhVWxEvxJBkgSUPwABs+sOP q0yIUMDjlppK6sBVmkeqmc2+lrYIXcseuKQxvyKTrNm0Yz/QrPviC7Qs5 k=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAEoLeVKtJXG8/2dsb2JhbABZgwc4U75sS4EsFnSCJQEBAQMBAQEBawsFCwIBCBguJwslAgQOBQ6HbQYNvlEEj1kHgyCBDwOQLoEwhiySCYMmgio X-IronPort-AV: E=Sophos;i="4.93,640,1378857600"; d="asc'?scan'208";a="277931861" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 05 Nov 2013 15:19:56 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rA5FJtao011820 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Nov 2013 15:19:55 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 09:19:55 -0600 From: "Fred Baker (fred)" To: Acee Lindem Thread-Topic: [homenet] draft-baker-rtgwg-src-dst-routing-use-cases-00 in the rtgwg today Thread-Index: AQHO2jp796+Fm6P3i0ymD2ohe6Z/Zw== Date: Tue, 5 Nov 2013 15:19:54 +0000 Message-ID: References: <94A203EA12AECE4BA92D42DBFFE0AE47030C88C1@eusaamb106.ericsson.se> In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE47030C88C1@eusaamb106.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.88.9] Content-Type: multipart/signed; boundary="Apple-Mail=_6E6AE095-AF91-4A34-A4B8-2A91287B3778"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "homenet@ietf.org Group" , Mark Townsley , Routing WG Subject: Re: [homenet] draft-baker-rtgwg-src-dst-routing-use-cases-00 in the rtgwg today X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 15:20:08 -0000 --Apple-Mail=_6E6AE095-AF91-4A34-A4B8-2A91287B3778 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Yes, pretty much. On Nov 5, 2013, at 6:39 AM, Acee Lindem wrote: > Hi Mark, > I attended and the majority of the discussion centered on whether the > problem could be solved with a simpler model such as a FIB per provider. > Fred pointed out that this would not handle overlapping source subnets and > the fact that it was possible to solve the general problem with a Patricia > tree and the installation disambiguating routes. Alvaro also commented > that there are use cases beyond homenet. As you'd expect, the next step > was that there needs to be more discussion on the RTG WG list (copied). > Thanks, > Acee > > On 11/4/13 11:05 PM, "Mark Townsley" wrote: > >> >> Was anyone on this list able to attend the rtgwg meeting today where Fred >> presented draft-baker-rtgwg-src-dst-routing-use-cases-00? I missed it, >> and would be interested in the reaction, feedback, or next steps (if any). >> >> Thanks, >> >> - Mark >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet > ---------------------------------------------------- The ignorance of how to use new knowledge stockpiles exponentially. - Marshall McLuhan --Apple-Mail=_6E6AE095-AF91-4A34-A4B8-2A91287B3778 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSeQyXbjEdbHIsm0MRArjzAJ0Ut/lSm8vJf57sqy9pxuYhDRAFzwCg6ED1 BrJkz7v/TCZaHuijN22m+PE= =fiZR -----END PGP SIGNATURE----- --Apple-Mail=_6E6AE095-AF91-4A34-A4B8-2A91287B3778-- From teco@inf-net.nl Tue Nov 5 07:48:23 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F2021E81AB for ; Tue, 5 Nov 2013 07:48:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 qBz9TFIvdnCK for ; Tue, 5 Nov 2013 07:48:10 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEF621E8157 for ; Tue, 5 Nov 2013 07:48:03 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id tp5so15300189ieb.31 for ; Tue, 05 Nov 2013 07:48:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=ShOBCkoLF6uigiHIV2ZRyTXCd4DRmxbTEvLv3rlimFk=; b=QzvY2x+PPFLmI9gGSWEG8uW+MlWsSvOiPaJeaCAzsm+2dKK0GysnfAEucgWnGhRwtG IMru3XK4CFU6TmYWLvnUdlCaFv49fy+TneraDYfJBu3soDEV8LHYth1ct1YY7H45Wihs C5guPDd3Gd+OQXQg405zVUJY/c9Hbhog1/ZrSOqOn/WdpAG29fgQr0degLRwc0464B3g VeFDesjmKjuPoHpn19c5XacMSO5ubXenAwmBjmSzqWmHkouc1NjEQNnG1I4AReygJYa/ VAOb+b2ZUwCj5bOLhfhdGgxFrfxO7xak0bDGnKPiYq4+9nzZGn6p3V4dQjw+80AhkAiY J2SQ== X-Gm-Message-State: ALoCoQmbmA1nS/G6QgF3ZDboaDK30THnzeXS4jeTbt7FTssT+1Qbm55qqFNI/rS/Rl85Lzaf3+qJ X-Received: by 10.50.61.179 with SMTP id q19mr16262512igr.33.1383666482414; Tue, 05 Nov 2013 07:48:02 -0800 (PST) Received: from [142.131.18.140] ([64.114.24.114]) by mx.google.com with ESMTPSA id v2sm2655351igz.3.2013.11.05.07.48.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 05 Nov 2013 07:48:01 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Teco Boot In-Reply-To: Date: Tue, 5 Nov 2013 07:47:58 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <48E7C224-3A50-42BD-AF02-3F98D17200CA@inf-net.nl> References: <94A203EA12AECE4BA92D42DBFFE0AE47030C88C1@eusaamb106.ericsson.se> To: "Fred Baker (fred)" X-Mailer: Apple Mail (2.1816) Cc: Acee Lindem , Mark Townsley , "homenet@ietf.org Group" , Routing WG Subject: Re: [homenet] draft-baker-rtgwg-src-dst-routing-use-cases-00 in the rtgwg today X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 15:48:23 -0000 I=92m happy to confirm recent stable Linux kernel IPv6 subtrees cache = problem is fixed. No need to do something special here, just give in = some ip -6 route add default from PREFIX [ via ADDRESS ] [ dev STRING ] = commands. Sure we need to have a distribution mechanism having all routers know = some form of (source_prefix, exit_link) mapping. If we take the = limitation to support only default routes, a simple border router = discovery and recursive FIB lookup will do. Select the route to the = border router, or, on the border router, use the right exit link. @Fred: I suggest you add my BRDP proposal in your list of efforts. No = code yet. It is the blueprint for MultiSmartGateway for v6 in olrsd2, to = replace SmartGateway tunnels which are used in current olsrd.org code. Teco=20 Op 5 nov. 2013, om 07:19 heeft Fred Baker (fred) het = volgende geschreven: > Yes, pretty much.=20 >=20 > On Nov 5, 2013, at 6:39 AM, Acee Lindem = wrote: >=20 >> Hi Mark, >> I attended and the majority of the discussion centered on whether the >> problem could be solved with a simpler model such as a FIB per = provider. >> Fred pointed out that this would not handle overlapping source = subnets and >> the fact that it was possible to solve the general problem with a = Patricia >> tree and the installation disambiguating routes. Alvaro also = commented >> that there are use cases beyond homenet. As you'd expect, the next = step >> was that there needs to be more discussion on the RTG WG list = (copied). >> Thanks, >> Acee >>=20 >> On 11/4/13 11:05 PM, "Mark Townsley" wrote: >>=20 >>>=20 >>> Was anyone on this list able to attend the rtgwg meeting today where = Fred >>> presented draft-baker-rtgwg-src-dst-routing-use-cases-00? I missed = it, >>> and would be interested in the reaction, feedback, or next steps (if = any). >>>=20 >>> Thanks, >>>=20 >>> - Mark >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >>=20 >=20 > ---------------------------------------------------- > The ignorance of how to use new knowledge stockpiles exponentially.=20 > - Marshall McLuhan >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From mark@townsley.net Wed Nov 6 15:27:05 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00B221E8064 for ; Wed, 6 Nov 2013 15:27:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[AWL=0.889, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 XQxSu3rE7D9u for ; Wed, 6 Nov 2013 15:27:03 -0800 (PST) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by ietfa.amsl.com (Postfix) with ESMTP id D3D2B21E8117 for ; Wed, 6 Nov 2013 15:26:49 -0800 (PST) Received: by mail-ie0-f180.google.com with SMTP id e14so373638iej.39 for ; Wed, 06 Nov 2013 15:26:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=QpZEKsiZs+yCT9nJfayHnVplSYexv3DopSi24q2cZZM=; b=RowYU9TJJAD0MetnaNevxOZ0ueDAk3d4TgZ43XL3+CLK5rAkBlNHgo78kbHpgru6fL tTJy4xuVJUUjSstK/XuWBnxZDd8/Z7tUIaLi9G77c9wro4DBpHQ+Nbj+VIbc4gs8uxF6 VK+DqZZoJPMyaU8cgx/BZOHIigulnxobitgcVF5ydK4HCFcENvqwwe18byiRj6cOYhfC faCYwIV7QzlPjEaI+BzACiq8zO8yaOvVHxHQEoxR4LJJGvanphxWfA3YqlpCeSLAfdJB 6rNT7qgvG7/d6seHZTYk8mFGjj+yAvrnKr5iNaDdwwS1ZucuFzBZa882ja5DxdtZUFF9 5vkg== X-Gm-Message-State: ALoCoQnIn/hovLFTBMZSKmxVPDtsBXg5DVNFEHw64ubNyG/4D3QSFznuY/1sKawpiji5tzXZvnBD X-Received: by 10.43.60.139 with SMTP id ws11mr3739170icb.12.1383780408829; Wed, 06 Nov 2013 15:26:48 -0800 (PST) Received: from dhcp-a4b2.meeting.ietf.org (dhcp-a4b2.meeting.ietf.org. [31.133.164.178]) by mx.google.com with ESMTPSA id l7sm814132igx.2.2013.11.06.15.26.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Nov 2013 15:26:48 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_E66CC528-5939-4BA5-8277-06CC7D6BA55A" From: Mark Townsley In-Reply-To: <48E7C224-3A50-42BD-AF02-3F98D17200CA@inf-net.nl> Date: Wed, 6 Nov 2013 15:26:45 -0800 Message-Id: References: <94A203EA12AECE4BA92D42DBFFE0AE47030C88C1@eusaamb106.ericsson.se> <48E7C224-3A50-42BD-AF02-3F98D17200CA@inf-net.nl> To: "Fred Baker (fred)" , Acee Lindem X-Mailer: Apple Mail (2.1283) Cc: "homenet@ietf.org Group" , Routing WG Subject: Re: [homenet] draft-baker-rtgwg-src-dst-routing-use-cases-00 in the rtgwg today X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 23:27:05 -0000 --Apple-Mail=_E66CC528-5939-4BA5-8277-06CC7D6BA55A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The derived requirements from = draft-baker-rtgwg-src-dst-routing-use-cases (copied below) were based = upon the outcome of a meeting at the last IETF in Berlin among the = various "source plus destination routing" draft authors. Fred will be = presenting this draft tomorrow in homenet. This functionality is = fundamental to the operation of a multihomed homenet, so I'd like to get = feedback (on list and during the meeting) on whether these are indeed = the agreed upon requirements between the two groups. o The routing protocol or mechanism includes a source prefix. It is acceptable that a default source prefix of ::/0 (all addresses) applies to routes that don't specify a prefix. o The routing protocol or mechanism includes a destination prefix, which may be a default route (::/0) or any more specific prefix up to and including a host route (/128). o The FIB lookup yields the route with the most specific (e.g. longest-match) destination prefix that also matches the source prefix constraint, or no match. Thanks, - Mark On Nov 5, 2013, at 7:47 AM, Teco Boot wrote: > I=92m happy to confirm recent stable Linux kernel IPv6 subtrees cache = problem is fixed. No need to do something special here, just give in = some ip -6 route add default from PREFIX [ via ADDRESS ] [ dev STRING ] = commands. > Sure we need to have a distribution mechanism having all routers know = some form of (source_prefix, exit_link) mapping. If we take the = limitation to support only default routes, a simple border router = discovery and recursive FIB lookup will do. Select the route to the = border router, or, on the border router, use the right exit link. > @Fred: I suggest you add my BRDP proposal in your list of efforts. No = code yet. It is the blueprint for MultiSmartGateway for v6 in olrsd2, to = replace SmartGateway tunnels which are used in current olsrd.org code. >=20 > Teco=20 >=20 > Op 5 nov. 2013, om 07:19 heeft Fred Baker (fred) het = volgende geschreven: >=20 >> Yes, pretty much.=20 >>=20 >> On Nov 5, 2013, at 6:39 AM, Acee Lindem = wrote: >>=20 >>> Hi Mark, >>> I attended and the majority of the discussion centered on whether = the >>> problem could be solved with a simpler model such as a FIB per = provider. >>> Fred pointed out that this would not handle overlapping source = subnets and >>> the fact that it was possible to solve the general problem with a = Patricia >>> tree and the installation disambiguating routes. Alvaro also = commented >>> that there are use cases beyond homenet. As you'd expect, the next = step >>> was that there needs to be more discussion on the RTG WG list = (copied). >>> Thanks, >>> Acee >>>=20 >>> On 11/4/13 11:05 PM, "Mark Townsley" wrote: >>>=20 >>>>=20 >>>> Was anyone on this list able to attend the rtgwg meeting today = where Fred >>>> presented draft-baker-rtgwg-src-dst-routing-use-cases-00? I missed = it, >>>> and would be interested in the reaction, feedback, or next steps = (if any). >>>>=20 >>>> Thanks, >>>>=20 >>>> - Mark >>>> _______________________________________________ >>>> homenet mailing list >>>> homenet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/homenet >>>=20 >>=20 >> ---------------------------------------------------- >> The ignorance of how to use new knowledge stockpiles exponentially.=20= >> - Marshall McLuhan >>=20 >> _______________________________________________ >> homenet mailing list >> homenet@ietf.org >> https://www.ietf.org/mailman/listinfo/homenet >=20 --Apple-Mail=_E66CC528-5939-4BA5-8277-06CC7D6BA55A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 


  o  =
The routing protocol or mechanism includes a source prefix.  It is
      acceptable that a default source prefix of ::/0 (all addresses)
      applies to routes that don't specify a prefix.

   o  The routing protocol or mechanism includes a destination prefix,
      which may be a default route (::/0) or any more specific prefix up
      to and including a host route (/128).

   o  The FIB lookup yields the route with the most specific (e.g.
      longest-match) destination prefix that also matches the source
      prefix constraint, or no =
match.

Thanks,

- = Mark

On Nov 5, 2013, at 7:47 AM, Teco Boot = wrote:

I=92m happy to confirm recent stable Linux kernel = IPv6 subtrees cache problem is fixed. No need to do something special = here, just give in some ip -6 route add default from PREFIX [ via = ADDRESS ] [ dev STRING ] commands.
Sure we need to have a = distribution mechanism having all routers know some form of = (source_prefix, exit_link) mapping. If we take the limitation to support = only default routes, a simple border router discovery and recursive FIB = lookup will do. Select the route to the border router, or, on the border = router, use the right exit link.
@Fred: I suggest you add my BRDP = proposal in your list of efforts. No code yet. It is the blueprint for = MultiSmartGateway for v6 in olrsd2, to replace SmartGateway tunnels = which are used in current olsrd.org = code.

Teco

Op 5 nov. 2013, om 07:19 heeft Fred Baker = (fred) <fred@cisco.com> het = volgende geschreven:

Yes, pretty much. =

On Nov 5, 2013, at 6:39 AM, Acee Lindem <acee.lindem@ericsson.com> = wrote:

Hi Mark,
I attended and the majority of = the discussion centered on whether = the
problem could be solved with a simpler model such as a FIB = per provider.
Fred pointed out that this would = not handle overlapping source subnets = and
the fact that it was possible to solve the general problem = with a Patricia
tree and the installation = disambiguating routes. Alvaro also = commented
that there are use cases beyond = homenet. As you'd expect, the next = step
was that there needs to be more discussion on the RTG WG = list (copied).
Thanks,
Acee

On 11/4/13 11:05 PM, "Mark = Townsley" <mark@townsley.net> = wrote:


Was = anyone on this list able to attend the rtgwg meeting today where = Fred
presented draft-baker-rtgwg-src-dst-routing-use-cases-00? = I missed it,
and = would be interested in the reaction, feedback, or next steps (if = any).

Thanks,

- = Mark
_______________________________________________
homenet mailing = list
homenet@ietf.org
https://www.ietf.or= g/mailman/listinfo/homenet
<= blockquote type=3D"cite">


----------------------------------------------------
The ignorance of how to use new = knowledge stockpiles exponentially.
 - Marshall McLuhan

_______________________________________________
homenet mailing = list
homenet@ietf.org
https://www.ietf.or= g/mailman/listinfo/homenet


= --Apple-Mail=_E66CC528-5939-4BA5-8277-06CC7D6BA55A-- From equinox@spaceboyz.net Wed Nov 6 15:51:44 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7069421F9EE1; Wed, 6 Nov 2013 15:51:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 ONuLk4CYSBzN; Wed, 6 Nov 2013 15:51:41 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:870:1000::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E23021F9ED2; Wed, 6 Nov 2013 15:51:40 -0800 (PST) Received: from equinox by spaceboyz.net with local (Exim 4.80.1) (envelope-from ) id 1VeCsr-0002e4-2c; Thu, 07 Nov 2013 00:51:37 +0100 Date: Thu, 7 Nov 2013 00:51:37 +0100 From: David Lamparter To: "homenet@ietf.org Group" , Routing WG Message-ID: <20131106235136.GI4891@spaceboyz.net> References: <94A203EA12AECE4BA92D42DBFFE0AE47030C88C1@eusaamb106.ericsson.se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <94A203EA12AECE4BA92D42DBFFE0AE47030C88C1@eusaamb106.ericsson.se> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Cc: Acee Lindem , Mark Townsley , "Fred Baker \(fred\)" Subject: Re: [homenet] draft-baker-rtgwg-src-dst-routing-use-cases-00 in the rtgwg today X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 23:51:44 -0000 On Tue, Nov 05, 2013 at 02:39:09PM +0000, Acee Lindem wrote: > Hi Mark, > I attended and the majority of the discussion centered on whether the > problem could be solved with a simpler model such as a FIB per provider. > Fred pointed out that this would not handle overlapping source subnets and > the fact that it was possible to solve the general problem with a Patricia > tree and the installation disambiguating routes. Alvaro also commented > that there are use cases beyond homenet. As you'd expect, the next step > was that there needs to be more discussion on the RTG WG list (copied). I disagree that it needs more discussion, at least on this particular item. It's an implementation detail. The way it's currently described does somewhat imply single-FIB, but it doesn't prescribe it, and in the end it *is* the match behaviour we want - so, I'd just interpret it as requirement on the _behaviour_ and if anyone wants to go with multiple FIBs in their implementation, feel free... (Yes, trying to put the "implementation detail" lid on the discussion here.) If anyone thinks we should have different match behaviour, that's a different discussion (but I haven't heard anything in that direction.) Describing the same match behaviour with multiple FIBs per source doesn't sound easier to me. I believe the current description is as simple and down to it as it gets. -David P.S.: I'm not even sure if a "FIB per provider" model is actually simpler, and I'm pretty certain the implementation is more complex. You'd have to copy most of the FIB content to each of the FIBs, dynamically create FIBs when upstreams appear/disappear (on remote routers even), and then there's also the case of an upstream going down => its addresses being deprecated => host still using them for old local connections => router should retain local connectivity for deprecated prefix => router needs to retain FIB with timer. Also needs to be done with routes, but I'd prefer doing it on routes only, and not on routes and FIBs. And I almost deleted that PS - really, implementation detail! > Thanks, > Acee > > On 11/4/13 11:05 PM, "Mark Townsley" wrote: > > >Was anyone on this list able to attend the rtgwg meeting today where Fred > >presented draft-baker-rtgwg-src-dst-routing-use-cases-00? I missed it, > >and would be interested in the reaction, feedback, or next steps (if any). From Ray.Bellis@nominet.org.uk Wed Nov 6 16:54:22 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A9811E8169 for ; Wed, 6 Nov 2013 16:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.506 X-Spam-Level: X-Spam-Status: No, score=-10.506 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 e5kHmwxk1noU for ; Wed, 6 Nov 2013 16:54:17 -0800 (PST) Received: from mx2.nominet.org.uk (mail.nominet.org.uk [213.248.242.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6508D21F9E44 for ; Wed, 6 Nov 2013 16:54:17 -0800 (PST) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To: Subject:Thread-Topic:Thread-Index:Date:Message-ID: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=KY2gG2oGBQeir+aEISOyBnmh5NxesSuy95RzS2rtpgyPnMi8G5g+Jcer giovFV5loXL2wBPXoUEHbk6gqujoxrb15MNVBI8pMpPjwzu9I0BQWs5vJ 0RUrFgNwcvoiSBbI2t4172nx9tDyj9Lk6UprOyg8KTG1pQwAUx995LM0z zjMbkeL0jzx9D+9drjoMqu3H9Y2YaLd/9n6iqSOLMavWJXMR9fBCU15zU DecGojQ7m708ugaATI+7xNplNkykc; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1383785657; x=1415321657; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=oLaLhe0v8BJrS+7N8TD4hHW840lVTQpiXCZjiE0suGA=; b=I35UGGnQJgQfZd08vDJ/wQVjqTPgUmTPqIRJXl3j1UYazYQCXdICWOXy T6oCd57XwU0/xtgZC5k+WvR97YXETQhrFMWRWmkjlegxmaueFZQiTFw/4 ClVDnLGbw4zORH0zNHQjVQJ6jRoiBGCW6VTL9F937+3CvRMq7cnZcumsO IWLFVqRZMkoPO6JHaIsd4zGX5S93K7pyuQdGLGkmX9/01gwLStrspGvh9 s1fSKHQBfKmJvhRwNKgzJJGg1+Kui; X-IronPort-AV: E=Sophos;i="4.93,647,1378854000"; d="scan'208";a="4138709" X-IPAS-Result: AhAFAMLjelLV+MWQ/2dsb2JhbABbgmYhOFO/LoEpFnSCJwU6GTgBKhRCJwQbAYd5AwmdQaFCjyiDWIEQA6oWgyaCKg Received: from wds-exc1.okna.nominet.org.uk ([213.248.197.144]) by mx2.nominet.org.uk with ESMTP; 07 Nov 2013 00:54:15 +0000 Received: from WDS-EXC2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4]) by wds-exc1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f%17]) with mapi id 14.02.0318.004; Thu, 7 Nov 2013 00:54:14 +0000 From: Ray Bellis To: "homenet@ietf.org Group" Thread-Topic: Homenet session administrivia Thread-Index: AQHO21PgHMbp/1MLS0STBrTW8NuVow== Date: Thu, 7 Nov 2013 00:54:14 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE7368565552@wds-exc2.okna.nominet.org.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <117F0DE85D0C2A4DAAD6DB1B6B622457@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [homenet] Homenet session administrivia X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 00:54:22 -0000 The (hopefully) final version of the agenda for tomorrow's meeting is at: We already have a volunteer note taker (thanks Thomas!) An advanced volunteer or two for relaying the jabber room would be much app= reciated! thanks, Ray and Mark From teco@inf-net.nl Wed Nov 6 17:19:39 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305D211E8205 for ; Wed, 6 Nov 2013 17:19:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.077 X-Spam-Level: X-Spam-Status: No, score=-3.077 tagged_above=-999 required=5 tests=[AWL=0.522, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 hW7TukDPhH+L for ; Wed, 6 Nov 2013 17:19:34 -0800 (PST) Received: from mail-bk0-f52.google.com (mail-bk0-f52.google.com [209.85.214.52]) by ietfa.amsl.com (Postfix) with ESMTP id 09BC511E81DB for ; Wed, 6 Nov 2013 17:19:32 -0800 (PST) Received: by mail-bk0-f52.google.com with SMTP id u14so99607bkz.11 for ; Wed, 06 Nov 2013 17:19:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=TarZnogPl+9E5DJ4B4CYlqH/vFqdo8PDyKMLjMUNQ2s=; b=mRJyMR/oAtMu/4zw1gbWmfpBcSVJve3rPwgLb+dpkDGp5eOXjqebbRoaZrzrgaE+Vl 4siNhpX0XxIzoPEGl9KxsJE64BzqT3A2OrKOHLVjVS2BCVU8Spyan3SUNysQX3mP+VB5 /ouS7ncf6/C2ZKUn7/UKKTz0nvULI3sec6K6pU1Wxq45INVca1BnOJRq/bENaKb//GxH EtPEJZFAfPqFNsA2Km7Po/FtthBmk5iLOZJ2dw15qRHgbDPykcmFu8HLRARS8/kxS6i0 lFrnwZkmOEKNuoW+dqfT//5OcKo6C4DiuOO5N9zlsFa5Zn+y76hLma7NWKL/FBTqPrFF AcIQ== X-Gm-Message-State: ALoCoQnS5ZEuqHJTo4VUhPgFQrTvFDDGx7QPDmavQXYvtxa3E5/0A+yN7UvphBa2WvsnXTbia1ze X-Received: by 10.204.247.71 with SMTP id mb7mr4159348bkb.7.1383787171205; Wed, 06 Nov 2013 17:19:31 -0800 (PST) Received: from dhcp-a43c.meeting.ietf.org (dhcp-a43c.meeting.ietf.org. [31.133.164.60]) by mx.google.com with ESMTPSA id b6sm526682bko.16.2013.11.06.17.19.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Nov 2013 17:19:30 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Teco Boot In-Reply-To: Date: Wed, 6 Nov 2013 17:19:27 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <94A203EA12AECE4BA92D42DBFFE0AE47030C88C1@eusaamb106.ericsson.se> <48E7C224-3A50-42BD-AF02-3F98D17200CA@inf-net.nl> To: Mark Townsley X-Mailer: Apple Mail (2.1816) Cc: Acee Lindem , "homenet@ietf.org Group" , "Fred Baker \(fred\)" , Routing WG Subject: Re: [homenet] draft-baker-rtgwg-src-dst-routing-use-cases-00 in the rtgwg today X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 01:19:39 -0000 Op 6 nov. 2013, om 15:26 heeft Mark Townsley het = volgende geschreven: >=20 > The derived requirements from = draft-baker-rtgwg-src-dst-routing-use-cases (copied below) were based = upon the outcome of a meeting at the last IETF in Berlin among the = various "source plus destination routing" draft authors. Fred will be = presenting this draft tomorrow in homenet. This functionality is = fundamental to the operation of a multihomed homenet, so I'd like to get = feedback (on list and during the meeting) on whether these are indeed = the agreed upon requirements between the two groups. >=20 >=20 > o The routing protocol or mechanism includes a source prefix. It = is > acceptable that a default source prefix of ::/0 (all addresses) > applies to routes that don't specify a prefix. >=20 > o The routing protocol or mechanism includes a destination prefix, > which may be a default route (::/0) or any more specific prefix = up > to and including a host route (/128). For homenets and having ingress filtering as BCP, I think ::/0 routes = with ::/0 source prefixes shall not be used. Also, for homenets I do not = see a use case for non-::0 destination prefixes with non-::/0 source = prefixes. >=20 >=20 > o The FIB lookup yields the route with the most specific (e.g. > longest-match) destination prefix that also matches the source > prefix constraint, or no match. I think this needs better specification. Something like: o The FIB lookup yields the route with the most specific (e.g. longest-match) destination prefix, and thereafter use the most=20 specific (e.g. longest-match) source prefix. Or from troan-homenet-sadr: First a longest match lookup is done in the routing table for the destination address, then for the resulting set a longest matching lookup is done for the source address. This is running code with recent Linux kernel, with enabled CONFIG_IPV6. Teco >=20 >=20 > Thanks, >=20 > - Mark >=20 > On Nov 5, 2013, at 7:47 AM, Teco Boot wrote: >=20 >> I=92m happy to confirm recent stable Linux kernel IPv6 subtrees cache = problem is fixed. No need to do something special here, just give in = some ip -6 route add default from PREFIX [ via ADDRESS ] [ dev STRING ] = commands. >> Sure we need to have a distribution mechanism having all routers know = some form of (source_prefix, exit_link) mapping. If we take the = limitation to support only default routes, a simple border router = discovery and recursive FIB lookup will do. Select the route to the = border router, or, on the border router, use the right exit link. >> @Fred: I suggest you add my BRDP proposal in your list of efforts. No = code yet. It is the blueprint for MultiSmartGateway for v6 in olrsd2, to = replace SmartGateway tunnels which are used in current olsrd.org code. >>=20 >> Teco=20 >>=20 >> Op 5 nov. 2013, om 07:19 heeft Fred Baker (fred) het = volgende geschreven: >>=20 >>> Yes, pretty much.=20 >>>=20 >>> On Nov 5, 2013, at 6:39 AM, Acee Lindem = wrote: >>>=20 >>>> Hi Mark, >>>> I attended and the majority of the discussion centered on whether = the >>>> problem could be solved with a simpler model such as a FIB per = provider. >>>> Fred pointed out that this would not handle overlapping source = subnets and >>>> the fact that it was possible to solve the general problem with a = Patricia >>>> tree and the installation disambiguating routes. Alvaro also = commented >>>> that there are use cases beyond homenet. As you'd expect, the next = step >>>> was that there needs to be more discussion on the RTG WG list = (copied). >>>> Thanks, >>>> Acee >>>>=20 >>>> On 11/4/13 11:05 PM, "Mark Townsley" wrote: >>>>=20 >>>>>=20 >>>>> Was anyone on this list able to attend the rtgwg meeting today = where Fred >>>>> presented draft-baker-rtgwg-src-dst-routing-use-cases-00? I missed = it, >>>>> and would be interested in the reaction, feedback, or next steps = (if any). >>>>>=20 >>>>> Thanks, >>>>>=20 >>>>> - Mark >>>>> _______________________________________________ >>>>> homenet mailing list >>>>> homenet@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/homenet >>>>=20 >>>=20 >>> ---------------------------------------------------- >>> The ignorance of how to use new knowledge stockpiles exponentially.=20= >>> - Marshall McLuhan >>>=20 >>> _______________________________________________ >>> homenet mailing list >>> homenet@ietf.org >>> https://www.ietf.org/mailman/listinfo/homenet >>=20 >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet From equinox@spaceboyz.net Wed Nov 6 18:06:58 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79AB711E8227; Wed, 6 Nov 2013 18:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 lS7x5HtLCj0P; Wed, 6 Nov 2013 18:06:57 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:870:1000::1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB5411E821D; Wed, 6 Nov 2013 18:06:50 -0800 (PST) Received: from equinox by spaceboyz.net with local (Exim 4.80.1) (envelope-from ) id 1VeEzg-0002JD-DM; Thu, 07 Nov 2013 03:06:48 +0100 Date: Thu, 7 Nov 2013 03:06:48 +0100 From: David Lamparter To: Teco Boot Message-ID: <20131107020648.GN4891@spaceboyz.net> References: <94A203EA12AECE4BA92D42DBFFE0AE47030C88C1@eusaamb106.ericsson.se> <48E7C224-3A50-42BD-AF02-3F98D17200CA@inf-net.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Cc: "homenet@ietf.org Group" , Routing WG Subject: Re: [homenet] draft-baker-rtgwg-src-dst-routing-use-cases-00 in the rtgwg today X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 02:06:58 -0000 On Wed, Nov 06, 2013 at 05:19:27PM -0800, Teco Boot wrote: > Op 6 nov. 2013, om 15:26 heeft Mark Townsley het volgende geschreven: > > o The routing protocol or mechanism includes a destination prefix, > > which may be a default route (::/0) or any more specific prefix up > > to and including a host route (/128). > > For homenets and having ingress filtering as BCP, I think ::/0 routes > with ::/0 source prefixes shall not be used. Also, for homenets I do > not see a use case for non-::0 destination prefixes with non-::/0 > source prefixes. The NTT video service mentioned several times (forgot the name) is a good example of non-::0 dst with non-::0 src. Admittedly, you could drop the source information without too much loss there, but I'm still hopeful that we can somehow feed that information up into the host to improve source address selection. That use case also presents a nice demo of the non-match behaviour because there will be no (dst ::0 src ) route, yielding an automatÑ–c unreachable should a host try to go on the internet with its video address. -David From teco@inf-net.nl Wed Nov 6 23:32:23 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3AE721E80AE for ; Wed, 6 Nov 2013 23:32:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 CTzBHdN4SSr6 for ; Wed, 6 Nov 2013 23:32:17 -0800 (PST) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by ietfa.amsl.com (Postfix) with ESMTP id CF66C21E8064 for ; Wed, 6 Nov 2013 23:32:16 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id aq17so226772iec.6 for ; Wed, 06 Nov 2013 23:32:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=wdP+OYv0r5wl3F5lNv6JMRgmdJZU2vP7eTCdUsX2juU=; b=UJBuG71EYlbU5sT3WKcEi1bIwfm2SkQc6LBcXcRBz8j9HFekoyI/1RenBzWxHOg9VU DsFDV2P+ZlTNJ3z6AylIMH2tNlI38M6BuMEsQvvXLt6oYYUwqc6g259Ed6jFhoucJEeI ACqb6jPVsLCpMD6g7L53zaAXlbHU68ynIYy3+xffPKn/D22oAQ0p79jAM1XcEvSaAcMy NH9hrbpoqU0b3qmvNkHOwaBZeZnkoQEH4U2yi3ySTXmKOUavHdmceMIuKVHeTHdLgITz Ay3tpRyrgatzKXBSVQhqtb3ss3qJp+N2XvNQ+Jg55dZdaQWJ6OafBgSYFKOwfm3KULts AVug== X-Gm-Message-State: ALoCoQkBKlOqul3c3ohDgCmLFv4g/MFzhbmdnBph51n6Q8oWAD4HjAfAN2V9R5mrokRPxrHZLjqL X-Received: by 10.50.61.35 with SMTP id m3mr1031053igr.56.1383809536262; Wed, 06 Nov 2013 23:32:16 -0800 (PST) Received: from [142.131.18.140] ([64.114.24.114]) by mx.google.com with ESMTPSA id k6sm2893881igx.8.2013.11.06.23.32.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Nov 2013 23:32:15 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Teco Boot In-Reply-To: <20131107020648.GN4891@spaceboyz.net> Date: Wed, 6 Nov 2013 23:32:13 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <706BB7CB-2165-4C46-B1F6-961662EA3E76@inf-net.nl> References: <94A203EA12AECE4BA92D42DBFFE0AE47030C88C1@eusaamb106.ericsson.se> <48E7C224-3A50-42BD-AF02-3F98D17200CA@inf-net.nl> <20131107020648.GN4891@spaceboyz.net> To: David Lamparter X-Mailer: Apple Mail (2.1816) Cc: "homenet@ietf.org Group" , Routing WG Subject: Re: [homenet] draft-baker-rtgwg-src-dst-routing-use-cases-00 in the rtgwg today X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 07:32:23 -0000 Op 6 nov. 2013, om 18:06 heeft David Lamparter het = volgende geschreven: > On Wed, Nov 06, 2013 at 05:19:27PM -0800, Teco Boot wrote: >> Op 6 nov. 2013, om 15:26 heeft Mark Townsley het = volgende geschreven: >>> o The routing protocol or mechanism includes a destination = prefix, >>> which may be a default route (::/0) or any more specific prefix = up >>> to and including a host route (/128). >>=20 >> For homenets and having ingress filtering as BCP, I think ::/0 routes >> with ::/0 source prefixes shall not be used. Also, for homenets I do >> not see a use case for non-::0 destination prefixes with non-::/0 >> source prefixes. >=20 > The NTT video service mentioned several times (forgot the name) is a > good example of non-::0 dst with non-::0 src. =20 Why would ::/0 from SOURCE_PREFIX not work? It enables access to = whatever prefix of the video service infrastructure. Same model applies to VPN tunnel to enterprise network. It is a waste of = energy to flood enterprise prefixes to VPN client. Sinking traffic with = source VPN prefix will do. Teco > Admittedly, you could > drop the source information without too much loss there, but I'm still > hopeful that we can somehow feed that information up into the host to > improve source address selection. >=20 > That use case also presents a nice demo of the non-match behaviour > because there will be no (dst ::0 src ) route, yielding = an > automat=D1=96c unreachable should a host try to go on the internet = with its > video address. >=20 >=20 > -David From fred@cisco.com Thu Nov 7 08:46:29 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F74321E81D7; Thu, 7 Nov 2013 08:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.406 X-Spam-Level: X-Spam-Status: No, score=-110.406 tagged_above=-999 required=5 tests=[AWL=0.193, 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 GfIFJp75IRmf; Thu, 7 Nov 2013 08:45:48 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 08ED321E81DA; Thu, 7 Nov 2013 08:45:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4082; q=dns/txt; s=iport; t=1383842711; x=1385052311; h=from:to:cc:subject:date:message-id:mime-version; bh=0fCRmUo2kyj0YZUSKGrF6CVkYbrAGNuWML0DY2sRDyQ=; b=NfOUmwcP+/OhaC1tiiXG7SAX/bZa2oYIGWvnzHLzSUHqi4oVzm5/hQJN ZksHptKQxuktbOuK02gTPuxSOr1Jiwz0auFmuG2zUCEx09t1RsS17nutl ncrr+pzDlTKdJ6UKALOTbmU1PN1uq0W+RRV1VppbJ8YPz0F9nEisWwPL/ 0=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAKXCe1KtJXG9/2dsb2JhbABagwc4U78OgSUWdIIseRIBgQAnBAENE4dzDbx0jg+BSoMngRADkC6BMIYugS+QW4Mmgio X-IronPort-AV: E=Sophos;i="4.93,652,1378857600"; d="asc'?scan'208";a="282091699" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 07 Nov 2013 16:45:08 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rA7Gj8uB006053 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Nov 2013 16:45:08 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 10:45:07 -0600 From: "Fred Baker (fred)" To: Routing WG , "ospf@ietf.org" , "isis-wg@ietf.org" Thread-Topic: Tsinghua work on source/destination routing Thread-Index: AQHO29i28SykYfa5/UyGL9QietHsLg== Date: Thu, 7 Nov 2013 16:45:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.75.25] Content-Type: multipart/signed; boundary="Apple-Mail=_065270AE-DA93-4FAF-A37D-E241100F61F2"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "homenet@ietf.org Group" , "v6ops@ietf.org WG" Subject: [homenet] Tsinghua work on source/destination routing X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 16:46:31 -0000 --Apple-Mail=_065270AE-DA93-4FAF-A37D-E241100F61F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'd like to draw your attention to a talk that will be given this = morning in homenet. The context is: = http://datatracker.ietf.org/doc/draft-baker-rtgwg-src-dst-routing-use-case= s http://tools.ietf.org/html/draft-baker-rtgwg-src-dst-routing-use-cases "Requirements and Use Cases for Source/Destination Routing", Fred = Baker, 2013-08-13 http://datatracker.ietf.org/doc/draft-xu-homenet-traffic-class http://tools.ietf.org/html/draft-xu-homenet-traffic-class "Traffic Class Routing Protocol in Home Networks", Mingwei Xu, Shu = Yang, Jianping Wu, Fred Baker, 2013-10-21 http://datatracker.ietf.org/doc/draft-xu-homenet-twod-ip-routing http://tools.ietf.org/html/draft-xu-homenet-twod-ip-routing "Two Dimensional-IP Routing Protocol in Home Networks", Mingwei Xu, = Shu Yang, Jianping Wu, Dan Wang, 2013-08-22 http://datatracker.ietf.org/doc/draft-baker-ipv6-ospf-dst-src-routing http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-src-routing "IPv6 Source/Destination Routing using OSPFv3", Fred Baker, 2013-08-28 http://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend http://tools.ietf.org/html/draft-ietf-ospf-ospfv3-lsa-extend "OSPFv3 LSA Extendibility", Acee Lindem, Sina Mirtorabi, Abhay Roy, = Fred Baker, 2013-10-15 I had breakfast this morning with Shu Yang, who has been writing Quagga = code for several years in the course of his PHd. He first implemented a = source/destination model, reported on in = draft-xu-homenet-twod-ip-routing, which was an MTR scheme. He tells me = he found that very complex. He also listened to my talk in homenet = around draft-baker-fun-routing-class, and has now implemented (if I = understand him correctly) draft-ietf-ospf-ospfv3-lsa-extend and = draft-baker-ipv6-ospf-dst-src-routing. The FIB implementation has a = limitation: the source prefixes must be disjoint. However, given that, = he has two FIB implementations, one of which has separate FIBs for each = source prefix in play including ::/0 (so if there are M prefixes in the = network, M+1 FIBs), and one of which is a single hierarchical M-Trie = that looks up the destination and then the source. He has tested the = code in simulation; the next step is testing in live networks. Examples of use cases are generally around multi-prefix campus networks. = There is a security use case that could be of value; at IETF 87, George = Michaelson of APNIC reported on ULAs seen in his darknet. The short = report is that he sees a fair bit of traffic with a ULA source address = on the backbone. An interesting potential use of source/destination = routing would counter that, and perhaps mitigate the need for ISP BCP 38 = if generally deployed; in a case where a network is using a ULA and a = global prefix (e.g., is not multihomed but has two prefixes, one of = which is intended to only be used within its network), the default route = to the network egress would use the global prefix as a source, and as a = result traffic sent outside the network with a ULA source prefix would = in effect have no route. The network could literally only emit traffic = from its correct prefix. I think this is relevant to the discussion of=20 draft-baker-rtgwg-src-dst-routing-use-cases draft-ietf-ospf-ospfv3-lsa-extend draft-baker-ipv6-ospf-dst-src-routing draft-baker-ipv6-isis-dst-src-routing --Apple-Mail=_065270AE-DA93-4FAF-A37D-E241100F61F2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSe8OSbjEdbHIsm0MRAo4JAKD1Gu32KozZNW+5Y1ee5sH14VA5XACg/9jZ h0LqlvvqSnEfhdffbQ568wA= =ofmZ -----END PGP SIGNATURE----- --Apple-Mail=_065270AE-DA93-4FAF-A37D-E241100F61F2-- From mcr@sandelman.ca Thu Nov 7 09:08:53 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5BA11E8188; Thu, 7 Nov 2013 09:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 Lqn3VzTOZH1r; Thu, 7 Nov 2013 09:08:38 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id BD9E921E81EB; Thu, 7 Nov 2013 09:08:16 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 495D920315; Thu, 7 Nov 2013 13:19:54 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id CFF9963B88; Thu, 7 Nov 2013 12:08:03 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BBB6063AED; Thu, 7 Nov 2013 12:08:03 -0500 (EST) From: Michael Richardson To: "homenet\@ietf.org Group" , Routing WG In-Reply-To: References: <94A203EA12AECE4BA92D42DBFFE0AE47030C88C1@eusaamb106.ericsson.se> <48E7C224-3A50-42BD-AF02-3F98D17200CA@inf-net.nl> 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 Subject: Re: [homenet] draft-baker-rtgwg-src-dst-routing-use-cases-00 in the rtgwg today X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 17:08:53 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Teco Boot wrote: > For homenets and having ingress filtering as BCP, I think ::/0 routes > with ::/0 source prefixes shall not be used. Also, for homenets I do > not see a use case for non-::0 destination prefixes with non-::/0 > source prefixes.=20 Access to the LLN in the home might only effectively work if you use the (right?) ULA.=20=20=20=20 =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUBUnvI8YqHRg3pndX9AQKr6AP+M9RXjvT5Jv/12OK4awSiLxVWw4HnfrMR 5dKiXCv+osokJN4EcR8IBMTYvKwJUwybfBZkQxGT8/Wl8lnk7dy2fP+C02sAk4LQ I8ZB2yD41ipHG916acmsajy7K8KXjZYb5BP66t3gu7iGakD7Q3q6/1v3hbariWMy le5S19wbQwI= =hzeN -----END PGP SIGNATURE----- --=-=-=-- From brian@innovationslab.net Thu Nov 7 10:08:09 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 927EA21E81D0 for ; Thu, 7 Nov 2013 10:08:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 z3XlOAdks7mZ for ; Thu, 7 Nov 2013 10:07:36 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 334F111E825F for ; Thu, 7 Nov 2013 10:05:56 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 7D2828816E for ; Thu, 7 Nov 2013 10:05:56 -0800 (PST) Received: from dhcp-b20e.meeting.ietf.org (dhcp-b20e.meeting.ietf.org [31.133.178.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 51B67130003 for ; Thu, 7 Nov 2013 10:05:56 -0800 (PST) Message-ID: <527BD67D.8070906@innovationslab.net> Date: Thu, 07 Nov 2013 13:05:49 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: homenet@ietf.org X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="M2TfqMVMPpH8P3d3tidArXUS42Xqexaag" Subject: [homenet] Multicast scoping X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 18:08:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --M2TfqMVMPpH8P3d3tidArXUS42Xqexaag Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All, I seem to be the bane of homenet given my stance on multicast scope zones. Probably because I am a co-author on RFC 4007. :) After some discussions, it seems there is a reasonable way to allow the homenet arch to use the admin-scope multicast range. My original concern, as documented in my DISCUSS, is that RFC 4291 requires scope 4 and larger be administratively configured. I will contend that *if* all the homenet boundary routers can automatically set a boundary based on getting a prefix delegation from an ISP, that satisfies the administratively configured rule 4291. If the WG is agreeable with that, there are a few things I would like to see in the arch doc: 1. References to site-local scope need to be changed to admin-scope 2. Some guidance on the setting of that boundary triggered by an administrative function like PD is needed Regards, Brian --M2TfqMVMPpH8P3d3tidArXUS42Xqexaag Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSe9aDAAoJEBOZRqCi7goqgYoH+wccMNGLsS83EywgnNYuN9U5 lkRhrLhorcvQyvikTf5DnD4GO3t6VgE/WQOqQNHox0t6uH60oTuZDiQvZs6fis4d ciZzcTsgPDDewmNtvQwwwCpmOi9of8D/bRzYlEqjXEbnfqu25NzZqxzwjMPLgxQq StL72Do3QtI53VcBbJ89Qs0uAuQdLRUD+rk9tMy6Tya/l3zfPaLXgOBrTusXd7um jsOfT7J0uFEFNBTvW/vbgiVWt60VY/xGcPLKVHlk+QD4BLvn2Cq/yjlJAla3psEc nHQZvtYQWHCO3r8ZBYoyGKww1y/W8eiOEPPCPPiKLv2jUw0wSQ7nNf4SiL/oRgY= =TSpx -----END PGP SIGNATURE----- --M2TfqMVMPpH8P3d3tidArXUS42Xqexaag-- From fred@cisco.com Thu Nov 7 10:11:47 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF42611E825C; Thu, 7 Nov 2013 10:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.459 X-Spam-Level: X-Spam-Status: No, score=-110.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 ygeKZ7PYErcU; Thu, 7 Nov 2013 10:11:18 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9D21B21E8133; Thu, 7 Nov 2013 10:08:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=986; q=dns/txt; s=iport; t=1383847720; x=1385057320; h=from:to:cc:subject:date:message-id:mime-version; bh=rNK/n9rCVGgdrWVK7lKOh7zvyVM9B+Sud2AlGra6Uaw=; b=lSACkgCflrnEgvSZ6XicZvtQWUzA5vHJ4qOXZkXA+scHXeUsa3oVoBrw 8pmR4c69r60q/R4lGzpUQnAkdxdEMXmZ9k+eU4dLcgmXBsChloERdD3Cp 4TaVrgeT5+eBo0n0+LcRJkn5cePGdUiRuVoaxwOsBHK2bX48p/SRjodZY 8=; X-Files: signature.asc : 195 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAJfWe1KtJV2Y/2dsb2JhbABagwc4U78PgSUWdIIseRIBFmonBA4Th3MNvFWPWYMngRADkC6BMIYugS+QW4Mmgio X-IronPort-AV: E=Sophos;i="4.93,653,1378857600"; d="asc'?scan'208";a="282060211" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 07 Nov 2013 18:08:28 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rA7I8Sw6007328 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Nov 2013 18:08:28 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.122]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 12:08:27 -0600 From: "Fred Baker (fred)" To: John Scudder Thread-Topic: Examples of ambiguous routes Thread-Index: AQHO2+RbrEyXDKtjRUG4o3lf57Melw== Date: Thu, 7 Nov 2013 18:08:26 +0000 Message-ID: <53454CA8-8DAA-4E33-A241-2EEE5EFBCC40@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.116.80] Content-Type: multipart/signed; boundary="Apple-Mail=_7E81D233-BFC4-43DD-A9B6-C252F79FEE64"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Cc: "homenet@ietf.org Group" , Routing WG Subject: [homenet] Examples of ambiguous routes X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 18:11:47 -0000 --Apple-Mail=_7E81D233-BFC4-43DD-A9B6-C252F79FEE64 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I looked at draft-baker-rtgwg-src-dst-routing-use-cases for the text I = mentioned, and you are correct: it's not there. It is in: = http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-src-routing-03#sectio= n-2.2 and its is-is counterpart. I'll copy that example into the use case = draft. --Apple-Mail=_7E81D233-BFC4-43DD-A9B6-C252F79FEE64 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFSe9cZbjEdbHIsm0MRAiX/AJ48GVS36orIjvqME18X3CP2WtpnKwCgpQY5 mtpNKngfz666EzLro+F9RDQ= =CDH2 -----END PGP SIGNATURE----- --Apple-Mail=_7E81D233-BFC4-43DD-A9B6-C252F79FEE64-- From brian@innovationslab.net Thu Nov 7 10:12:53 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B316521E8224 for ; Thu, 7 Nov 2013 10:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 vS0BHQcCADoQ for ; Thu, 7 Nov 2013 10:12:45 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id DF45E11E81B6 for ; Thu, 7 Nov 2013 10:10:42 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 7E0008816E for ; Thu, 7 Nov 2013 10:10:20 -0800 (PST) Received: from dhcp-b20e.meeting.ietf.org (dhcp-b20e.meeting.ietf.org [31.133.178.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id DFA31130003 for ; Thu, 7 Nov 2013 10:10:19 -0800 (PST) Message-ID: <527BD78A.1030403@innovationslab.net> Date: Thu, 07 Nov 2013 13:10:18 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: homenet@ietf.org References: <527BD67D.8070906@innovationslab.net> In-Reply-To: <527BD67D.8070906@innovationslab.net> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="R31lEEaxsbNqGmaR0bA2o4fOBJvdjsJow" Subject: Re: [homenet] Multicast scoping X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 18:12:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --R31lEEaxsbNqGmaR0bA2o4fOBJvdjsJow Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable One more point... On 11/7/13 1:05 PM, Brian Haberman wrote: > All, > I seem to be the bane of homenet given my stance on multicast scop= e > zones. Probably because I am a co-author on RFC 4007. :) >=20 > After some discussions, it seems there is a reasonable way to allo= w > the homenet arch to use the admin-scope multicast range. My original > concern, as documented in my DISCUSS, is that RFC 4291 requires scope 4= > and larger be administratively configured. I will contend that *if* al= l > the homenet boundary routers can automatically set a boundary based on > getting a prefix delegation from an ISP, that satisfies the > administratively configured rule 4291. >=20 > If the WG is agreeable with that, there are a few things I would like t= o > see in the arch doc: >=20 > 1. References to site-local scope need to be changed to admin-scope >=20 > 2. Some guidance on the setting of that boundary triggered by an > administrative function like PD is needed >=20 This same approach could be used to contain any ULA prefixes generated as well. Regards, Brian --R31lEEaxsbNqGmaR0bA2o4fOBJvdjsJow Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJSe9eKAAoJEBOZRqCi7goqXrYH/2Fi9TwOEDieCxrXVHUQ++GX T0tRKMtMEtpBd9+Y3wd2HG0dLn8lwAdeTzHOqkAr+gZ8vQUegmabUhyjyplOd7pj Rx0d7DBS3dFMRz42uBNipRtjxFo6yrbs1ZJGjo+5FNDxDfYyZHywDyGI/+dds5x8 T8IlqWE9d3HQsCSF7yv2fcAWdAe4D0XLl5P35J7ETDwkswu05bGUw+5WTTSO5s0D G5RbUnDMQTOZwlv672yVV5wtk4jCizwGBMvGyVpUOjKHYtiaJSo4q7NCDJ4/ps36 ZH3z4CTyFvYE7WiF1orGBpL4TIc0Cms8BtTy3IibQ9HCNpyJuNn4qYkj0BSbmVk= =GpDt -----END PGP SIGNATURE----- --R31lEEaxsbNqGmaR0bA2o4fOBJvdjsJow-- From mark@townsley.net Thu Nov 7 10:14:55 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D72CD11E81C4 for ; Thu, 7 Nov 2013 10:14:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.153 X-Spam-Level: X-Spam-Status: No, score=-3.153 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] 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 whxPKPqkZyVO for ; Thu, 7 Nov 2013 10:14:50 -0800 (PST) Received: from mail-bk0-f47.google.com (mail-bk0-f47.google.com [209.85.214.47]) by ietfa.amsl.com (Postfix) with ESMTP id 182EF11E822F for ; Thu, 7 Nov 2013 10:12:43 -0800 (PST) Received: by mail-bk0-f47.google.com with SMTP id d7so372516bkh.6 for ; Thu, 07 Nov 2013 10:12:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=j65FS/G2Us9RRJo9kTLstTGyWcNUC6hYlFj8e1uWka8=; b=Z3WYLHq7jPs+4+HEBYPiBgXFVgUs/0wR8T7C3XNV9y2yw4DjC6VOokr3Aiad+v3pxK jkSkcb5mxWNa4llFSLN28fhq9FRN9wdZZkKNSorklj7DkQtpMk8ysCSZIH4ONsRR2rum tCtWbbq4fUxa63HOoSwMEhjuTjQgNcTHvwfs/ta2jNgSJ1+lxxDuqQUmuNAdPOVPfhfN omFf61O9b2+LbylwegD7BXtc0n+v16vHFN3+dHHypA2HJ/M0oX0FXHjxt1U8GTNVBzXa v5wyHkwTrUkqIestS5FNGyzvPP0OeQBRXkkS6KVFGOgo/rZAepQYOYQGh0rNSgTrifZE sUjw== X-Gm-Message-State: ALoCoQkE8k2jVlhD0crnAXMNaoiTiUk4wWzE50cGJkBdQBpMdbC/kYxold8QjXMPuy02nFuXjmkl X-Received: by 10.204.68.3 with SMTP id t3mr7422152bki.33.1383847949291; Thu, 07 Nov 2013 10:12:29 -0800 (PST) Received: from dhcp-a4b2.meeting.ietf.org (dhcp-a4b2.meeting.ietf.org. [31.133.164.178]) by mx.google.com with ESMTPSA id qe6sm3171981bkb.5.2013.11.07.10.12.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Nov 2013 10:12:28 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_936B8953-B9CE-4D95-B8A0-EB225837AC5F" From: Mark Townsley In-Reply-To: <527BD67D.8070906@innovationslab.net> Date: Thu, 7 Nov 2013 10:12:25 -0800 Message-Id: References: <527BD67D.8070906@innovationslab.net> To: Brian Haberman X-Mailer: Apple Mail (2.1283) Cc: homenet@ietf.org Subject: Re: [homenet] Multicast scoping X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 18:14:55 -0000 --Apple-Mail=_936B8953-B9CE-4D95-B8A0-EB225837AC5F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 This part of the agenda today includes quite a bit on the thorny problem = of Border Discovery, you are more the welcome to join if you can! Security 1040 Michael Behringer, draft-behringer-homenet-trust-bootstrap-01 (10 = min) 1050 Markus Stenberg and Erik Kline, = draft-kline-homenet-default-perimeter-00 (implementation report) (15 min) Homenet / HIPnet Design Team Results 1105 Timothy Winters, draft-winters-homenet-sper-interaction-00 (20 = min) On Nov 7, 2013, at 10:05 AM, Brian Haberman wrote: > All, > I seem to be the bane of homenet given my stance on multicast = scope > zones. Probably because I am a co-author on RFC 4007. :) >=20 > After some discussions, it seems there is a reasonable way to = allow > the homenet arch to use the admin-scope multicast range. My original > concern, as documented in my DISCUSS, is that RFC 4291 requires scope = 4 > and larger be administratively configured. I will contend that *if* = all > the homenet boundary routers can automatically set a boundary based on > getting a prefix delegation from an ISP, that satisfies the > administratively configured rule 4291. >=20 > If the WG is agreeable with that, there are a few things I would like = to > see in the arch doc: >=20 > 1. References to site-local scope need to be changed to admin-scope >=20 > 2. Some guidance on the setting of that boundary triggered by an > administrative function like PD is needed >=20 > Regards, > Brian >=20 > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet --Apple-Mail=_936B8953-B9CE-4D95-B8A0-EB225837AC5F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Security

  1040 Michael = Behringer= , draft= -behringer-homenet-trust-bootstrap-= 01 (10 min)

  = 1050 Markus Stenberg and Erik = Kline, = draft-kline-homenet-default-perimeter-00

  = (implementation report) (15 min)

Homenet / HIPnet Design Team Results

  1105=   Timothy Winters, draft= -winters-homenet-sper-interaction-= 00 (20 min)


On Nov 7, 2013, at 10:05 AM, Brian = Haberman wrote:

All,
    I seem to be the = bane of homenet given my stance on multicast scope
zones. =  Probably because I am a co-author on RFC 4007. :)

=     After some discussions, it seems there is a = reasonable way to allow
the homenet arch to use the admin-scope = multicast range.  My original
concern, as documented in my = DISCUSS, is that RFC 4291 requires scope 4
and larger be = administratively configured.  I will contend that *if* all
the = homenet boundary routers can automatically set a boundary based = on
getting a prefix delegation from an ISP, that satisfies = the
administratively configured rule 4291.

If the WG is = agreeable with that, there are a few things I would like to
see in = the arch doc:

1. References to site-local scope need to be = changed to admin-scope

2. Some guidance on the setting of that = boundary triggered by an
administrative function like PD is = needed

Regards,
Brian

___________________________________= ____________
homenet mailing list
homenet@ietf.org
https://www.ietf.= org/mailman/listinfo/homenet

= --Apple-Mail=_936B8953-B9CE-4D95-B8A0-EB225837AC5F-- From jch@pps.univ-paris-diderot.fr Fri Nov 8 04:24:05 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F8A11E8177; Fri, 8 Nov 2013 04:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 dPxEdgWx+ekd; Fri, 8 Nov 2013 04:24:01 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 503A111E8122; Fri, 8 Nov 2013 04:24:00 -0800 (PST) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id rA8CNuoF008925; Fri, 8 Nov 2013 13:23:56 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 9B2D45AD5F; Fri, 8 Nov 2013 13:23:56 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id lB5yMqrCzFxY; Fri, 8 Nov 2013 13:23:55 +0100 (CET) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 0E5FB5AD5E; Fri, 8 Nov 2013 13:23:54 +0100 (CET) Received: from localhost ([::1] helo=lanthane.pps.univ-paris-diderot.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.80) (envelope-from ) id 1Vel6Q-0008Om-Lx; Fri, 08 Nov 2013 13:23:54 +0100 Date: Fri, 08 Nov 2013 13:23:54 +0100 Message-ID: <7ivc0313qd.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: "Fred Baker (fred)" In-Reply-To: References: User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Fri, 08 Nov 2013 13:23:56 +0100 (CET) X-Miltered: at korolev with ID 527CD7DC.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 527CD7DC.002 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 527CD7DC.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Cc: "v6ops@ietf.org WG" , "ospf@ietf.org" , "homenet@ietf.org Group" , "isis-wg@ietf.org" , Routing WG Subject: Re: [homenet] Tsinghua work on source/destination routing X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 12:24:05 -0000 > The context is: A pity you didn't cite any of the previous work on the subject: http://tools.ietf.org/html/draft-troan-homenet-sadr-01 https://github.com/fingon/hnet-core http://tools.ietf.org/html/draft-boutier-homenet-source-specific-routing http://git.wifi.pps.univ-paris-diderot.fr/?p=babels.git > I had breakfast this morning with Shu Yang, who has been writing > Quagga code for several years in the course of his PHd. [...] and > has now implemented (if I understand him correctly) > draft-ietf-ospf-ospfv3-lsa-extend and > draft-baker-ipv6-ospf-dst-src-routing. Excellent. Could we please have a look at the source code ? (It was already promised in Berlin, if memory serves.) Regards, -- Juliusz From yangshu1988@gmail.com Fri Nov 8 04:51:47 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E4511E80EE; Fri, 8 Nov 2013 04:51:47 -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 zmr2sIJ7Asjf; Fri, 8 Nov 2013 04:51:46 -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 C600621F9F3D; Fri, 8 Nov 2013 04:51:45 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id ez12so2109967wid.17 for ; Fri, 08 Nov 2013 04:51:45 -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=w9+Jksh257ryDWT6JsZcR2sdObTNDhDJiMxLs2U5ZfQ=; b=f89r88L2kWPUJuyeJ8dFIDEuexwSsZnsgMEujWgT5vsb3tryyLnpKzy+4vP/PluMH7 +hWcL2sO317uzW9+MQcMIEGz8c8qJqlEgk9Ew0B7giGhJThxPgRtUckEKMMSUXyOJ/l/ NnExU+m72S0CEsA5WB+ntFPz0JX8OlTyctath451/Opz4eStVT9+lXg3HeDtF2Y6eQTI DkvYpsw1XeiDtRqfxuz5tv9yymxvnnrGSTJErgDttzzEYwZOjmA1orbTqV8XTlwsbUWo w5FHBOL53sXFVGWn2x7IWxmbq10fcI9XSlOep3NfsCgaWaVBS/lFxDqlMTexLSYKSAV3 lR4w== MIME-Version: 1.0 X-Received: by 10.180.37.67 with SMTP id w3mr2274557wij.56.1383915104978; Fri, 08 Nov 2013 04:51:44 -0800 (PST) Received: by 10.194.36.196 with HTTP; Fri, 8 Nov 2013 04:51:44 -0800 (PST) In-Reply-To: <7ivc0313qd.wl%jch@pps.univ-paris-diderot.fr> References: <7ivc0313qd.wl%jch@pps.univ-paris-diderot.fr> Date: Fri, 8 Nov 2013 20:51:44 +0800 Message-ID: From: Shu Yang To: Juliusz Chroboczek Content-Type: multipart/alternative; boundary=e89a8f502cfa3b4f0f04eaa9d83b Cc: "v6ops@ietf.org WG" , "isis-wg@ietf.org" , "ospf@ietf.org" , "Fred Baker \(fred\)" , "homenet@ietf.org Group" , Routing WG Subject: Re: [homenet] Tsinghua work on source/destination routing X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 12:51:47 -0000 --e89a8f502cfa3b4f0f04eaa9d83b Content-Type: text/plain; charset=ISO-8859-1 > Excellent. Could we please have a look at the source code ? (It was > already promised in Berlin, if memory serves.) We will make it public after testing it in live networks (we are still implementing the Click code, and combining quagga and click together). If you want, I can send you the current version privately at this moment. Shu Yang Tsinghua University --e89a8f502cfa3b4f0f04eaa9d83b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> Excellent. =A0Could we please have a look at the sour= ce code ? =A0(It was
> already promised in Berlin, if memory serves.)=
We will make it public after testing it in live networks (we are s= till
implementing the Click code, and combining quagga and click
= together).

If you want, I can send you the current= version privately at this moment.

Shu Yang
Tsinghua University
--e89a8f502cfa3b4f0f04eaa9d83b-- From jch@pps.univ-paris-diderot.fr Sun Nov 10 05:37:31 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A80711E8190; Sun, 10 Nov 2013 05:37:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.505 X-Spam-Level: X-Spam-Status: No, score=-1.505 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, HELO_EQ_FR=0.35] 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 PQeQEEH1gsbp; Sun, 10 Nov 2013 05:37:19 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 0333D21F9E4F; Sun, 10 Nov 2013 05:37:07 -0800 (PST) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id rAADb3SM032731; Sun, 10 Nov 2013 14:37:03 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 0B0255AE60; Sun, 10 Nov 2013 14:37:03 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id uQAuzS8TC55g; Sun, 10 Nov 2013 14:37:02 +0100 (CET) Received: from ijon.pps.jussieu.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 1245A5AE5C; Sun, 10 Nov 2013 14:37:01 +0100 (CET) Received: from localhost ([127.0.0.1] helo=ijon.pps.jussieu.fr) by ijon.pps.jussieu.fr with esmtp (Exim 4.80) (envelope-from ) id 1VfVCI-0002DH-Ln; Sun, 10 Nov 2013 14:37:02 +0100 Date: Sun, 10 Nov 2013 14:37:02 +0100 Message-ID: <87mwlcnzsx.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Shu Yang In-Reply-To: References: <7ivc0313qd.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sun, 10 Nov 2013 14:37:03 +0100 (CET) X-Miltered: at korolev with ID 527F8BFF.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 527F8BFF.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 527F8BFF.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Cc: "v6ops@ietf.org WG" , "isis-wg@ietf.org" , "ospf@ietf.org" , "Fred Baker \(fred\)" , "homenet@ietf.org Group" , Routing WG Subject: Re: [homenet] Tsinghua work on source/destination routing X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 13:37:32 -0000 > > Excellent. Could we please have a look at the source code ? (It was > > already promised in Berlin, if memory serves.) > We will make it public after testing it in live networks Ah, I see. > If you want, I can send you the current version privately at this moment. I'd much prefer a public repository, something I can discuss freely with people (and eventually cite) without worrying whether I'm disclosing anything confidential. -- Juliusz From hrogge@googlemail.com Sun Nov 10 06:24:37 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7016121E808F; Sun, 10 Nov 2013 06:24:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 7F69NisDODam; Sun, 10 Nov 2013 06:24:36 -0800 (PST) Received: from mail-qe0-x233.google.com (mail-qe0-x233.google.com [IPv6:2607:f8b0:400d:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 4017811E80EA; Sun, 10 Nov 2013 06:24:36 -0800 (PST) Received: by mail-qe0-f51.google.com with SMTP id t7so454854qeb.24 for ; Sun, 10 Nov 2013 06:24:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Cx2jX8ap06xyOckh1Gs6MpCl1Kg/Q9NmtMYJ6WC1Kvw=; b=hgOBrYyFlklgxdCbAuwgL9t0GCKHEdHXykBPxx54uLlbNP+EgQNKmDVHm3wTI6uhvr MGT0d2Kdhb/uXCSgDGxA6ddrjjVxOih41/B4Yql2cCBsRf3eL9QH+6/8E4AYVm6Kk8XH XODz5svhSigCRfWs3TOSoyAoSxTjD6hiFeT5kpO7rYU2dDxlxOU6XxKBCZJnh57F8s4C XGX8BW8Drl6G8G+WAWqp4cQTOS2LopvWOKWKlPwPkZDEDO10lEneFFoKPIMY7kTXU/HV FI/504jvZMGSelmViqT3Pz1ZoG7u4ta8jzW+Uk+5ybcoHkOXIBrIjzrpko+xw+6J2xh6 XJng== X-Received: by 10.224.171.196 with SMTP id i4mr41052709qaz.38.1384093475813; Sun, 10 Nov 2013 06:24:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.36.200 with HTTP; Sun, 10 Nov 2013 06:24:15 -0800 (PST) In-Reply-To: <87mwlcnzsx.wl%jch@pps.univ-paris-diderot.fr> References: <7ivc0313qd.wl%jch@pps.univ-paris-diderot.fr> <87mwlcnzsx.wl%jch@pps.univ-paris-diderot.fr> From: Henning Rogge Date: Sun, 10 Nov 2013 15:24:15 +0100 Message-ID: To: Juliusz Chroboczek Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org WG" , "isis-wg@ietf.org" , "ospf@ietf.org" , "Fred Baker \(fred\)" , "homenet@ietf.org Group" , Routing WG , Shu Yang Subject: Re: [homenet] Tsinghua work on source/destination routing X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 14:24:37 -0000 On Sun, Nov 10, 2013 at 2:37 PM, Juliusz Chroboczek wrote: >> > Excellent. Could we please have a look at the source code ? (It was >> > already promised in Berlin, if memory serves.) >> >> If you want, I can send you the current version privately at this moment. > > I'd much prefer a public repository, something I can discuss freely > with people (and eventually cite) without worrying whether I'm disclosing > anything confidential. I agree with Juliusz, a public repository would be much better, even if it only contains "in development" code. If the code will be open sourced in the end anyways I don't see any drawbacks. Henning Rogge -- We began as wanderers, and we are wanderers still. We have lingered long enough on the shores of the cosmic ocean. We are ready at last to set sail for the stars - Carl Sagan From hermin.anggawijaya@gmail.com Sun Nov 10 10:09:30 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86FD311E8146; Sun, 10 Nov 2013 10:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.932 X-Spam-Level: X-Spam-Status: No, score=-1.932 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 wHS5L7WFejO3; Sun, 10 Nov 2013 10:09:29 -0800 (PST) Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 3191A11E80E6; Sun, 10 Nov 2013 10:09:29 -0800 (PST) Received: by mail-vb0-f46.google.com with SMTP id 10so2646151vbe.33 for ; Sun, 10 Nov 2013 10:09:28 -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=zt2DnudiU+2cmNXFhvBjYwTX1+AL8PDS0Z1/nyUgE6k=; b=VP9u2GiBDteepBwT3GgkDjxd/5X66Nla2wpLpTKPaQsp2tTNq2u8ukfBoAcTT5vQ5Q 9g5L/Zem5QOjkEAiCehecKiFln2CfHHXA7eoWxQ/Qi00Wi3WyP82yoIoHRd60KG5XDm/ TgrQgYiNOf2qgN5g3y1k3HT6S845cfGAzMxx4xSjeWCNk/6eXUwGlCn+vq8Hvnsh3404 so1vZir4A4/xal8DReUbP5zZq+faVkBKsCXM0hQ8EMfMKMDlDCLlecIHZkJPAyik2GJr +S1iy6VGtZSOBxjbqGIN+1fOl6d1sD/XWK/RCFZ1pASiVGfjC4R/en6dWqkvOIG3mlT9 MWUA== MIME-Version: 1.0 X-Received: by 10.52.111.161 with SMTP id ij1mr76560vdb.33.1384106968582; Sun, 10 Nov 2013 10:09:28 -0800 (PST) Received: by 10.58.188.72 with HTTP; Sun, 10 Nov 2013 10:09:28 -0800 (PST) In-Reply-To: References: <7ivc0313qd.wl%jch@pps.univ-paris-diderot.fr> <87mwlcnzsx.wl%jch@pps.univ-paris-diderot.fr> Date: Sun, 10 Nov 2013 10:09:28 -0800 Message-ID: From: Hermin Anggawijaya To: Shu Yang Content-Type: multipart/alternative; boundary=bcaec54863463192eb04ead68457 Cc: "ospf@ietf.org" , "v6ops@ietf.org WG" , "homenet@ietf.org Group" , Routing WG Subject: Re: [homenet] [v6ops] Tsinghua work on source/destination routing X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Nov 2013 18:09:30 -0000 --bcaec54863463192eb04ead68457 Content-Type: text/plain; charset=ISO-8859-1 I too would be interested in seeing the code if it's available in a public repo. cheers Angga On Sun, Nov 10, 2013 at 6:24 AM, Henning Rogge wrote: > On Sun, Nov 10, 2013 at 2:37 PM, Juliusz Chroboczek > wrote: > >> > Excellent. Could we please have a look at the source code ? (It was > >> > already promised in Berlin, if memory serves.) > >> > >> If you want, I can send you the current version privately at this > moment. > > > > I'd much prefer a public repository, something I can discuss freely > > with people (and eventually cite) without worrying whether I'm disclosing > > anything confidential. > > I agree with Juliusz, a public repository would be much better, even > if it only contains "in development" code. > > If the code will be open sourced in the end anyways I don't see any > drawbacks. > > Henning Rogge > > -- > We began as wanderers, and we are wanderers still. We have lingered > long enough on the shores of the cosmic ocean. We are ready at last to > set sail for the stars - Carl Sagan > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --bcaec54863463192eb04ead68457 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I too would be interested in seeing the code if = it's available in a public repo.

cheers

Angga=


On Sun, Nov 10, 2013 at 6:24 AM, Henning Rogge <hrogge@googlemail.com<= /a>> wrote:
On Sun, Nov 10, 2013 at 2:37 PM, Juliusz Chroboczek
<jch@pps.univ-paris-did= erot.fr> wrote:
>> > Excellent. =A0Could we please have a look at the source code = ? =A0(It was
>> > already promised in Berlin, if memory serves.)
>>
>> If you want, I can send you the current ve= rsion privately at this moment.
>
> I'd much prefer a public repository, something I can discuss freel= y
> with people (and eventually cite) without worrying whether I'm dis= closing
> anything confidential.

I agree with Juliusz, a public repository would be much better, even<= br> if it only contains "in development" code.

If the code will be open sourced in the end anyways I don't see any dra= wbacks.

Henning Rogge

--
We began as wanderers, and we are wanderers still. We have lingered
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan
_____________________= __________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--bcaec54863463192eb04ead68457-- From yangshu1988@gmail.com Sun Nov 10 23:06:29 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B8F21E8127; Sun, 10 Nov 2013 23:06:29 -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=[AWL=0.000, BAYES_00=-2.599, 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 57C5UHb85BLv; Sun, 10 Nov 2013 23:06:27 -0800 (PST) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA2C21E811A; Sun, 10 Nov 2013 23:06:06 -0800 (PST) Received: by mail-we0-f180.google.com with SMTP id q59so4247042wes.11 for ; Sun, 10 Nov 2013 23:06: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=5hidhRXKtLkFr2S1fTOLEVwKv0AQKter4JziILQkFOc=; b=fvrB88Uwe2WO+a+bWmjBRpAoQuS1Nk656ePHi1WSOzcTfajdntNgSUQaFjx2fBPY4M UeLhIe0/fjrWHSUyIbeZ2iB9eiNgjoFwOAMEUEZpoTGxuUhPYT87WKn3InqqPcBEoX/j QZIdGfWHinwCmfYNMGamOH6+dpOQcNJ7fUZeiAikV5SkveA2FfDyk/QPK9kbBh5nlEqL SdpeJ2TtLpm554dbv7w7Rs5fSwusC5iFC3cdYxM2pONqn8JW0skgvmlPQZknZxcNjELJ wcYXqg7qrLf2crOWvugNL0dYW7Q7uSsk9z8dRrZEotSrsfQcqXouhIaidGYeYwEGU/vI gy0A== MIME-Version: 1.0 X-Received: by 10.180.85.226 with SMTP id k2mr11178775wiz.31.1384153566060; Sun, 10 Nov 2013 23:06:06 -0800 (PST) Received: by 10.194.36.196 with HTTP; Sun, 10 Nov 2013 23:06:05 -0800 (PST) In-Reply-To: References: <7ivc0313qd.wl%jch@pps.univ-paris-diderot.fr> <87mwlcnzsx.wl%jch@pps.univ-paris-diderot.fr> Date: Mon, 11 Nov 2013 15:06:05 +0800 Message-ID: From: Shu Yang To: Henning Rogge Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org WG" , "isis-wg@ietf.org" , Juliusz Chroboczek , "ospf@ietf.org" , "Fred Baker \(fred\)" , "homenet@ietf.org Group" , Routing WG Subject: Re: [homenet] Tsinghua work on source/destination routing X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 07:06:29 -0000 > I agree with Juliusz, a public repository would be much better, even > if it only contains "in development" code. > > If the code will be open sourced in the end anyways I don't see any drawbacks. > > Henning Rogge Ok, we will make it public in this week. Shu Yang From Fred.L.Templin@boeing.com Thu Nov 7 09:08:24 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4D321E81D8; Thu, 7 Nov 2013 09:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.527 X-Spam-Level: X-Spam-Status: No, score=-6.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, 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 6U-OQ+jAgEBU; Thu, 7 Nov 2013 09:08:02 -0800 (PST) Received: from slb-mbsout-02.boeing.com (slb-mbsout-02.boeing.com [130.76.64.129]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB3C11E8188; Thu, 7 Nov 2013 09:07:38 -0800 (PST) Received: from slb-mbsout-02.boeing.com (localhost.localdomain [127.0.0.1]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id rA7H7bgd012939; Thu, 7 Nov 2013 09:07:37 -0800 Received: from XCH-NWHT-11.nw.nos.boeing.com (xch-nwht-11.nw.nos.boeing.com [130.247.25.114]) by slb-mbsout-02.boeing.com (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id rA7H7aMq012929 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Thu, 7 Nov 2013 09:07:37 -0800 Received: from XCH-BLV-406.nw.nos.boeing.com (130.247.25.162) by XCH-NWHT-11.nw.nos.boeing.com (130.247.25.114) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 7 Nov 2013 09:07:36 -0800 Received: from XCH-BLV-504.nw.nos.boeing.com ([169.254.4.85]) by XCH-BLV-406.nw.nos.boeing.com ([169.254.6.190]) with mapi id 14.03.0158.001; Thu, 7 Nov 2013 09:07:34 -0800 From: "Templin, Fred L" To: "Fred Baker (fred)" , Routing WG , "ospf@ietf.org" , "isis-wg@ietf.org" Thread-Topic: Tsinghua work on source/destination routing Thread-Index: AQHO29i28SykYfa5/UyGL9QietHsLpoZ/WGA Date: Thu, 7 Nov 2013 17:07:34 +0000 Message-ID: <2134F8430051B64F815C691A62D9831814AE3D@XCH-BLV-504.nw.nos.boeing.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.247.104.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-Mailman-Approved-At: Mon, 11 Nov 2013 01:11:11 -0800 Cc: "homenet@ietf.org Group" , "v6ops@ietf.org WG" Subject: Re: [homenet] Tsinghua work on source/destination routing X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 17:08:24 -0000 Hi Fred, It is good to see this discussion, but an alternative approach that should also be considered is tunneling. In the IRON approach at least, the end user network gets a stable IPv6 prefix that is independent of the access network IP addresses it gets from its ISPs. So, there is no need for source address-based forwarding to ensure that packets sent via ISP A will not have a source address from ISP B. The use cases for tunneling are very broad, and probably overlap with the ones you are considering in this approach. The relevant documents are here: http://tools.ietf.org/html/draft-templin-ironbis http://tools.ietf.org/html/draft-templin-intarea-vet http://tools.ietf.org/html/draft-templin-intarea-seal =20 Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= Fred Baker (fred) > Sent: Thursday, November 07, 2013 8:45 AM > To: Routing WG; ospf@ietf.org; isis-wg@ietf.org > Cc: homenet@ietf.org Group; v6ops@ietf.org WG > Subject: [v6ops] Tsinghua work on source/destination routing >=20 > I'd like to draw your attention to a talk that will be given this morning= in homenet. The context is: >=20 > http://datatracker.ietf.org/doc/draft-baker-rtgwg-src-dst-routing-use-cas= es > http://tools.ietf.org/html/draft-baker-rtgwg-src-dst-routing-use-cases > "Requirements and Use Cases for Source/Destination Routing", Fred Baker= , > 2013-08-13 >=20 > http://datatracker.ietf.org/doc/draft-xu-homenet-traffic-class > http://tools.ietf.org/html/draft-xu-homenet-traffic-class > "Traffic Class Routing Protocol in Home Networks", Mingwei Xu, Shu Yang= , > Jianping Wu, Fred Baker, 2013-10-21 >=20 > http://datatracker.ietf.org/doc/draft-xu-homenet-twod-ip-routing > http://tools.ietf.org/html/draft-xu-homenet-twod-ip-routing > "Two Dimensional-IP Routing Protocol in Home Networks", Mingwei Xu, Shu > Yang, Jianping Wu, Dan Wang, 2013-08-22 >=20 > http://datatracker.ietf.org/doc/draft-baker-ipv6-ospf-dst-src-routing > http://tools.ietf.org/html/draft-baker-ipv6-ospf-dst-src-routing > "IPv6 Source/Destination Routing using OSPFv3", Fred Baker, 2013-08-28 >=20 > http://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv3-lsa-extend > http://tools.ietf.org/html/draft-ietf-ospf-ospfv3-lsa-extend > "OSPFv3 LSA Extendibility", Acee Lindem, Sina Mirtorabi, Abhay Roy, Fre= d > Baker, 2013-10-15 >=20 > I had breakfast this morning with Shu Yang, who has been writing Quagga c= ode for several years in the > course of his PHd. He first implemented a source/destination model, repor= ted on in draft-xu-homenet- > twod-ip-routing, which was an MTR scheme. He tells me he found that very = complex. He also listened to > my talk in homenet around draft-baker-fun-routing-class, and has now impl= emented (if I understand him > correctly) draft-ietf-ospf-ospfv3-lsa-extend and draft-baker-ipv6-ospf-ds= t-src-routing. The FIB > implementation has a limitation: the source prefixes must be disjoint. Ho= wever, given that, he has two > FIB implementations, one of which has separate FIBs for each source prefi= x in play including ::/0 (so > if there are M prefixes in the network, M+1 FIBs), and one of which is a = single hierarchical M-Trie > that looks up the destination and then the source. He has tested the code= in simulation; the next step > is testing in live networks. >=20 > Examples of use cases are generally around multi-prefix campus networks. = There is a security use case > that could be of value; at IETF 87, George Michaelson of APNIC reported o= n ULAs seen in his darknet. > The short report is that he sees a fair bit of traffic with a ULA source = address on the backbone. An > interesting potential use of source/destination routing would counter tha= t, and perhaps mitigate the > need for ISP BCP 38 if generally deployed; in a case where a network is u= sing a ULA and a global > prefix (e.g., is not multihomed but has two prefixes, one of which is int= ended to only be used within > its network), the default route to the network egress would use the globa= l prefix as a source, and as > a result traffic sent outside the network with a ULA source prefix would = in effect have no route. The > network could literally only emit traffic from its correct prefix. >=20 > I think this is relevant to the discussion of > draft-baker-rtgwg-src-dst-routing-use-cases > draft-ietf-ospf-ospfv3-lsa-extend > draft-baker-ipv6-ospf-dst-src-routing > draft-baker-ipv6-isis-dst-src-routing From mcr@sandelman.ca Tue Nov 12 09:11:55 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@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 Subject: [homenet] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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: homenet@ietfa.amsl.com Delivered-To: homenet@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) Cc: "dhcwg@ietf.org WG" , "homenet@ietf.org Group" , "" Subject: Re: [homenet] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 mcr@sandelman.ca Tue Nov 12 10:31:26 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@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: [homenet] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 Ray.Bellis@nominet.org.uk Thu Nov 14 02:48:30 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7633121E81F5 for ; Thu, 14 Nov 2013 02:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.512 X-Spam-Level: X-Spam-Status: No, score=-10.512 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 DW8u9zIY7+ng for ; Thu, 14 Nov 2013 02:48:26 -0800 (PST) Received: from mx2.nominet.org.uk (mail.nominet.org.uk [213.248.242.49]) by ietfa.amsl.com (Postfix) with ESMTP id C8A8321E81F2 for ; Thu, 14 Nov 2013 02:48:25 -0800 (PST) DomainKey-Signature: s=main2.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:X-IPAS-Result:Received:Received:From:To: Subject:Thread-Topic:Thread-Index:Date:Message-ID: Accept-Language:Content-Language:X-MS-Has-Attach: X-MS-TNEF-Correlator:x-originating-ip:Content-Type: MIME-Version; b=zyUpM/H7yDjIvp1NL9nNJpHroXIAq590ex4uKMVhsYBrrvPLsJgo+f/8 2eNrxW/RhI0F4uHjIcYFHiApEdEzFDNLMZ/8PGDiwDFSjW19y9fwc1ZjD NuWI6Rm1MLoJChQzaBxXobuVjSoiexSLkUcDwRxBpYCX1uZf63RloToMm bkUbzvRu98gGTB6XmCNCo+V54FpNbebQP0AQqzZJAoDMIcPT7h16xFsJ+ QoCOsWYBmYJ46vhI/Ug976PprOTvM; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=@nominet.org.uk; q=dns/txt; s=main2.dkim.nominet.selector; t=1384426105; x=1415962105; h=from:to:subject:date:message-id:mime-version; bh=CKPd68gz75nkI1X1xOB6HNIChKdT1CRTwCQsN1zhQR8=; b=fb8gyTrHpIMM39l2+AAZZLT1UmpdHcKh9fzADSz7KWketLhJSaFiafRM csLPaKtNDTLY+LLy0uBWaXOrzQkqjs8l98Nsj57GieY4qFfsaX3ivwrQm U8LLhdgZxIAcdQHatBNnaRzyv235C/PB3XZcwcZT8GUaFLvGOwYDyJJZC ggCc/vYzKME29f9MuRNqpxmXmeQU70ra+/HGYVm3ruCvQ9jP7dVg1B9zf iInWPNDbL4xQ5zM1gpJ5Qe0spSg0+; X-IronPort-AV: E=Sophos;i="4.93,699,1378854000"; d="scan'208,217";a="4292032" X-IPAS-Result: Aj0IAEOphFLV+MWQ/2dsb2JhbABQCoJmIThTtmuILgeBIRZ0ghwLBVM4AQsBHlYnBBsBh3kDCZ18oX6OHIESg1iBEQOqHIMogio Received: from wds-exc1.okna.nominet.org.uk ([213.248.197.144]) by mx2.nominet.org.uk with ESMTP; 14 Nov 2013 10:48:24 +0000 Received: from WDS-EXC2.okna.nominet.org.uk ([fe80::7577:eaca:5241:25d4]) by wds-exc1.okna.nominet.org.uk ([fe80::1593:1394:a91f:8f5f%17]) with mapi id 14.02.0318.004; Thu, 14 Nov 2013 10:48:23 +0000 From: Ray Bellis To: "homenet@ietf.org Group" Thread-Topic: IETF88 minutes Thread-Index: AQHO4ScJcrUeylnMCEKqKCpFqbUVFg== Date: Thu, 14 Nov 2013 10:48:22 +0000 Message-ID: <53F00E5CD8B2E34C81C0C89EB0B4FE7368571862@wds-exc2.okna.nominet.org.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] Content-Type: multipart/alternative; boundary="_000_53F00E5CD8B2E34C81C0C89EB0B4FE7368571862wdsexc2oknanomi_" MIME-Version: 1.0 Subject: [homenet] IETF88 minutes X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 10:48:30 -0000 --_000_53F00E5CD8B2E34C81C0C89EB0B4FE7368571862wdsexc2oknanomi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thomas' transcript of our session is now online at: There's a couple of unidentified speakers - if you're able to identify any = of them please let me know! Ray --_000_53F00E5CD8B2E34C81C0C89EB0B4FE7368571862wdsexc2oknanomi_ Content-Type: text/html; charset="us-ascii" Content-ID: <11117A49BE3A164282E030AC84DA6750@okna.nominet.org.uk> Content-Transfer-Encoding: quoted-printable Thomas' transcript of our session is now online at:


There's a couple of unidentified speakers - if you're able to identify= any of them please let me know!

Ray

--_000_53F00E5CD8B2E34C81C0C89EB0B4FE7368571862wdsexc2oknanomi_-- From robmgl.ietf@gmail.com Thu Nov 14 19:08:59 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@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: Fri, 15 Nov 2013 01:00:03 -0800 Cc: "dhcwg@ietf.org WG" , homenet@ietf.org, robmgl@cisco.com, radext@ietf.org Subject: Re: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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: homenet@ietfa.amsl.com Delivered-To: homenet@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: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 Carl.Wuyts@technicolor.com Fri Nov 15 07:30:25 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@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 Cc: "dhcwg@ietf.org WG" , "homenet@ietf.org" , "robmgl@cisco.com" , "radext@ietf.org" Subject: Re: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 09:57:32 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@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 Cc: "dhcwg@ietf.org WG" , homenet@ietf.org, robmgl@cisco.com, radext@ietf.org Subject: Re: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 robmgl.ietf@gmail.com Fri Nov 15 10:32:49 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@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 Cc: Michael Richardson , "homenet@ietf.org" , "robmgl@cisco.com" , "radext@ietf.org" , "dhcwg@ietf.org WG" Subject: Re: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 mcr@sandelman.ca Fri Nov 15 11:19:27 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@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: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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: homenet@ietfa.amsl.com Delivered-To: homenet@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: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 aduitsis@gmail.com Fri Nov 15 12:59:16 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@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 Cc: Michael Richardson , homenet@ietf.org, robmgl@cisco.com, radext@ietf.org, "dhcwg@ietf.org WG" Subject: Re: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: 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 yangshu1988@gmail.com Tue Nov 19 00:10:27 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09AB71ACC85; Tue, 19 Nov 2013 00:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 X_PdXOrqIuQh; Tue, 19 Nov 2013 00:10:25 -0800 (PST) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id EA8501ACC82; Tue, 19 Nov 2013 00:10:24 -0800 (PST) Received: by mail-we0-f177.google.com with SMTP id p61so2604651wes.22 for ; Tue, 19 Nov 2013 00:10:18 -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=Ul8+qQpxkayDnb1bwSaehMZBdpQ7F9SZO/ZWdoshbdA=; b=e8LJRttNBhJjjeO9YydI4LA/YAJXcxGV24AiTglNXsc0QJ9HL+Z/I3rVuLnXggUbgP CcMPCeyoR0SpL96i6C02mt8KAcR4kvE5UV2xjrqtyu1k7zpyqHdTKD35OSJfoSc7YzdG kEhWtPYmz88i+RcWnSu4ZCXfPbETY/S+7QWZW/z9OLmkv4Dd1hVZu49QACO+s7YyK2bP N4hU2CEwj+SXTkfWjxXp8tzG1htbuIO147xCRe3O1qx21Q2kh0wmgUcVnVQNlHz6RiQy RrkvM4+qjA6q4OQAZX41ZY3vBjMKzL8U7SULjlZxPadCcb5mov+U7EJqXqqfSp45xevG mUgw== MIME-Version: 1.0 X-Received: by 10.194.200.100 with SMTP id jr4mr5102157wjc.37.1384848618423; Tue, 19 Nov 2013 00:10:18 -0800 (PST) Received: by 10.194.36.196 with HTTP; Tue, 19 Nov 2013 00:10:18 -0800 (PST) In-Reply-To: References: <7ivc0313qd.wl%jch@pps.univ-paris-diderot.fr> <87mwlcnzsx.wl%jch@pps.univ-paris-diderot.fr> Date: Tue, 19 Nov 2013 16:10:18 +0800 Message-ID: From: Shu Yang To: Henning Rogge Content-Type: multipart/alternative; boundary=047d7bb03e1ef80e9104eb83316c Cc: "v6ops@ietf.org WG" , "isis-wg@ietf.org" , Juliusz Chroboczek , "ospf@ietf.org" , "Fred Baker \(fred\)" , "homenet@ietf.org Group" , Routing WG Subject: Re: [homenet] Tsinghua work on source/destination routing X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 08:10:27 -0000 --047d7bb03e1ef80e9104eb83316c Content-Type: text/plain; charset=ISO-8859-1 > Ok, we will make it public in this week. The page for the project is here: https://github.com/t-routing/traffic-class-routing-system-based-on-OSPFv3 It's still in development status, and we will keep improving it. Shu Yang On Mon, Nov 11, 2013 at 3:06 PM, Shu Yang wrote: > > I agree with Juliusz, a public repository would be much better, even > > if it only contains "in development" code. > > > > If the code will be open sourced in the end anyways I don't see any > drawbacks. > > > > Henning Rogge > > Ok, we will make it public in this week. > > Shu Yang > --047d7bb03e1ef80e9104eb83316c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> Ok, we will make it public in this week.
<= div>The page for the project is here:=A0https://github.com/t-routing/traffic-class-routing-system-= based-on-OSPFv3
It's still in development status,= and we will keep improving it.

Shu Yang


On Mon,= Nov 11, 2013 at 3:06 PM, Shu Yang <yangshu1988@gmail.com> wrote:
> I agree with Juliusz,= a public repository would be much better, even
> if it only contains "in development" code.
>
> If the code will be open sourced in the end anyways I don't see an= y drawbacks.
>
> Henning Rogge

Ok, we will make it public in this week.

Shu Yang

--047d7bb03e1ef80e9104eb83316c-- From jch@pps.univ-paris-diderot.fr Tue Nov 19 02:22:49 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6700D1AD8CD; Tue, 19 Nov 2013 02:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_FR=0.35] 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 F9We4TGlFZnZ; Tue, 19 Nov 2013 02:22:47 -0800 (PST) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5121AD8F4; Tue, 19 Nov 2013 02:22:47 -0800 (PST) Received: from potemkin.univ-paris7.fr (potemkin.univ-paris7.fr [IPv6:2001:660:3301:8000::1:1]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/46573) with ESMTP id rAJAMafL003582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Nov 2013 11:22:36 +0100 Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by potemkin.univ-paris7.fr (8.14.4/8.14.4/relay2/46573) with ESMTP id rAJAMaI5004749; Tue, 19 Nov 2013 11:22:36 +0100 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 1D97F5B449; Tue, 19 Nov 2013 11:22:36 +0100 (CET) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id ucBultFNswwi; Tue, 19 Nov 2013 11:22:34 +0100 (CET) Received: from lanthane.pps.univ-paris-diderot.fr (unknown [172.23.36.54]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 817C45B446; Tue, 19 Nov 2013 11:22:34 +0100 (CET) Received: from localhost ([::1] helo=lanthane.pps.univ-paris-diderot.fr) by lanthane.pps.univ-paris-diderot.fr with esmtp (Exim 4.80) (envelope-from ) id 1ViiS2-0007SV-9s; Tue, 19 Nov 2013 11:22:34 +0100 Date: Tue, 19 Nov 2013 11:22:34 +0100 Message-ID: <7i8uwky9lh.wl%jch@pps.univ-paris-diderot.fr> From: Juliusz Chroboczek To: Shu Yang In-Reply-To: References: <7ivc0313qd.wl%jch@pps.univ-paris-diderot.fr> <87mwlcnzsx.wl%jch@pps.univ-paris-diderot.fr> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]); Tue, 19 Nov 2013 11:22:36 +0100 (CET) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (potemkin.univ-paris7.fr [194.254.61.141]); Tue, 19 Nov 2013 11:22:36 +0100 (CET) X-Miltered: at korolev with ID 528B3BEC.002 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-Miltered: at potemkin with ID 528B3BEC.001 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 528B3BEC.002 from potemkin.univ-paris7.fr/potemkin.univ-paris7.fr/null/potemkin.univ-paris7.fr/ X-j-chkmail-Enveloppe: 528B3BEC.001 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 528B3BEC.002 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Score: MSGID : 528B3BEC.001 on potemkin.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham X-j-chkmail-Status: Ham Cc: "v6ops@ietf.org WG" , "isis-wg@ietf.org" , Henning Rogge , "ospf@ietf.org" , "Fred Baker \(fred\)" , "homenet@ietf.org Group" , Routing WG Subject: Re: [homenet] Tsinghua work on source/destination routing X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 10:22:49 -0000 > > Ok, we will make it public in this week. > The page for the project is here: https://github.com/t-routing/ > traffic-class-routing-system-based-on-OSPFv3 Thanks, but could you please point us at your code? That's a full Quagga tree merged with a full Click tree, with no development history. (I've quickly checked the Quagga-FIB interface, and haven't found anything new in there, but then perhaps I haven't looked hard enough.) -- Juliusz From markus.stenberg@iki.fi Tue Nov 19 02:31:20 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FF51ADBE8; Tue, 19 Nov 2013 02:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 c7WCcTnc7CxG; Tue, 19 Nov 2013 02:31:18 -0800 (PST) Received: from kirsi1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id EEAD81ADBF7; Tue, 19 Nov 2013 02:31:17 -0800 (PST) Received: from kosame.lan (80.220.67.193) by kirsi1.inet.fi (8.5.140.03) (authenticated as stenma-47) id 526FA42301E20C0F; Tue, 19 Nov 2013 12:31:09 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Markus Stenberg In-Reply-To: <7i8uwky9lh.wl%jch@pps.univ-paris-diderot.fr> Date: Tue, 19 Nov 2013 12:30:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7ivc0313qd.wl%jch@pps.univ-paris-diderot.fr> <87mwlcnzsx.wl%jch@pps.univ-paris-diderot.fr> <7i8uwky9lh.wl%jch@pps.univ-paris-diderot.fr> To: Juliusz Chroboczek X-Mailer: Apple Mail (2.1822) Cc: "v6ops@ietf.org WG" , "isis-wg@ietf.org" , Henning Rogge , Markus Stenberg , "ospf@ietf.org" , "Fred Baker \(fred\)" , "homenet@ietf.org Group" , Routing WG , Shu Yang Subject: Re: [homenet] Tsinghua work on source/destination routing X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 10:31:20 -0000 On 19.11.2013, at 12.22, Juliusz Chroboczek = wrote: >>> Ok, we will make it public in this week. >=20 >> The page for the project is here: https://github.com/t-routing/ >> traffic-class-routing-system-based-on-OSPFv3 >=20 > Thanks, but could you please point us at your code? That's a full > Quagga tree merged with a full Click tree, with no development = history. >=20 > (I've quickly checked the Quagga-FIB interface, and haven't found > anything new in there, but then perhaps I haven=92t looked hard = enough.) Looks like the integration with click is done right from ospf6d and it = never even goes to zebra.=20 Two tips for next github export: - save history so it=92s more convenient to compare with baseline (now I = needed to do fairly arcane diff due to non-clean tree + no history) - put cleaned tree (no *~, no binaries such as *.o) Kind of sad, I was hoping for general src+dst aware Quagga code :) Cheers, -Markus= From aduitsis@gmail.com Tue Nov 19 03:16:02 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@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: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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 volz@cisco.com Tue Nov 19 04:07:49 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@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 Cc: "radext@ietf.org" , Michael Richardson , "Roberta Maglione \(robmgl\)" , "dhcwg@ietf.org WG" , Roberta Maglione , "homenet@ietf.org" Subject: Re: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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 aduitsis@gmail.com Tue Nov 19 04:39:40 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@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: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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: homenet@ietfa.amsl.com Delivered-To: homenet@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: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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 Carl.Wuyts@technicolor.com Tue Nov 19 04:46:36 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@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 Cc: "radext@ietf.org" , "homenet@ietf.org" , "Roberta Maglione \(robmgl\)" , "dhcwg@ietf.org WG" , Michael Richardson Subject: Re: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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 volz@cisco.com Tue Nov 19 05:20:09 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@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 Cc: "radext@ietf.org" , "homenet@ietf.org" , "Roberta Maglione \(robmgl\)" , "dhcwg@ietf.org WG" , Michael Richardson Subject: Re: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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 aduitsis@gmail.com Tue Nov 19 07:00:46 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@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: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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 Carl.Wuyts@technicolor.com Tue Nov 19 07:22:22 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@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 Cc: "radext@ietf.org" , "homenet@ietf.org" , "dhcwg@ietf.org WG" , Michael Richardson Subject: Re: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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:07:54 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@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: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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: homenet@ietfa.amsl.com Delivered-To: homenet@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: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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 aduitsis@gmail.com Tue Nov 19 08:38:37 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@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: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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: homenet@ietfa.amsl.com Delivered-To: homenet@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: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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: homenet@ietfa.amsl.com Delivered-To: homenet@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: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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 jouni.nospam@gmail.com Tue Nov 19 09:36:58 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@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: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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: homenet@ietfa.amsl.com Delivered-To: homenet@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: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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 aduitsis@gmail.com Tue Nov 19 11:27:44 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@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: [homenet] [radext] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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 yangshu1988@gmail.com Wed Nov 20 00:20:34 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0835E1AE38F; Wed, 20 Nov 2013 00:20:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, 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 FlrAax9nT3vv; Wed, 20 Nov 2013 00:20:32 -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 D12701AE38E; Wed, 20 Nov 2013 00:20:29 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id u56so1588096wes.9 for ; Wed, 20 Nov 2013 00:20: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=wcXBKNUKBXMb/WisJ+FdIaRXRDpe0diY8Zc8y9Y6ets=; b=EcuZOs2Z65NyTre0dhSSTx/0vV5DnMz1XJWcmB6LqF6HcNr2LsAGABYsO5XLtDigqU mGg+LlSOJurFYo4459kct+4NvrW9Z/29jn4QIgoRY6WMiOSECLm7VysujEf4KTcivWgD dZt4PqcbQAZLcwTF6XaBhxOVBZUhAsLWJ6sEPNXVrw9jkBMuKdj9Vt15l3OUUoSEF7dM UyPcr3dkpYeTrSwXej/YAi57WdK0l+FyiN2OuNR1fsM6HrKaC+PEtzLiRsrHjnBeWZfl tA6dhln8Xwb+QtbpwI2MEwdU34Dvux/rhq/0u+1iY2TPVYojJTv/DoiGyMTyP4mKwfqc QMTQ== MIME-Version: 1.0 X-Received: by 10.194.78.51 with SMTP id y19mr65093wjw.62.1384935623177; Wed, 20 Nov 2013 00:20:23 -0800 (PST) Received: by 10.194.36.196 with HTTP; Wed, 20 Nov 2013 00:20:23 -0800 (PST) In-Reply-To: References: <7ivc0313qd.wl%jch@pps.univ-paris-diderot.fr> <87mwlcnzsx.wl%jch@pps.univ-paris-diderot.fr> <7i8uwky9lh.wl%jch@pps.univ-paris-diderot.fr> Date: Wed, 20 Nov 2013 16:20:23 +0800 Message-ID: From: Shu Yang To: Markus Stenberg Content-Type: multipart/alternative; boundary=047d7beb9b5cdb3c0f04eb97738c Cc: "v6ops@ietf.org WG" , "isis-wg@ietf.org" , Juliusz Chroboczek , Henning Rogge , "ospf@ietf.org" , liu zheng , "Fred Baker \(fred\)" , "homenet@ietf.org Group" , Routing WG Subject: Re: [homenet] Tsinghua work on source/destination routing X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 08:20:34 -0000 --047d7beb9b5cdb3c0f04eb97738c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, Markus, Sorry for uploading a version without any baseline, we have changed it. We are using Click router, which can also be integrated with Quagga easily, i.e., Quagga generates the src+dst routing entries and updates Click through pre-defined interfaces (we will write a detailed Readme file). We use it because 1) Click is quite modularized (we only need to modify the two related modules); 2) we have such experiences before. Shu Yang Tsinghua University On Tue, Nov 19, 2013 at 6:30 PM, Markus Stenberg wr= ote: > On 19.11.2013, at 12.22, Juliusz Chroboczek > wrote: > > >>> Ok, we will make it public in this week. > > > >> The page for the project is here: https://github.com/t-routing/ > >> traffic-class-routing-system-based-on-OSPFv3 > > > > Thanks, but could you please point us at your code? That's a full > > Quagga tree merged with a full Click tree, with no development history. > > > > (I've quickly checked the Quagga-FIB interface, and haven't found > > anything new in there, but then perhaps I haven=92t looked hard enough.= ) > > Looks like the integration with click is done right from ospf6d and it > never even goes to zebra. > > Two tips for next github export: > > - save history so it=92s more convenient to compare with baseline (now I > needed to do fairly arcane diff due to non-clean tree + no history) > > - put cleaned tree (no *~, no binaries such as *.o) > > Kind of sad, I was hoping for general src+dst aware Quagga code :) > > Cheers, > > -Markus --047d7beb9b5cdb3c0f04eb97738c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi, Markus,

Sorry for uploading a versi= on without any baseline, we have changed it.

We ar= e using Click router, which can also be integrated with Quagga easily, i.e.= , Quagga generates the src+dst routing entries and updates Click through pr= e-defined interfaces (we will write a detailed Readme file). We use it beca= use 1) Click is quite modularized (we only need to modify the two related m= odules); 2) we have such experiences before.

Shu Yang
Tsinghua University

=A0


On Tue, Nov 19, 2013 at 6:30 PM, Markus Stenberg <markus.s= tenberg@iki.fi> wrote:
On 1= 9.11.2013, at 12.22, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> wrote:

>>> Ok, we will make it public in this week.
>
>> The page for the project is here: https://github.com/t-routing/
>> traffic-class-routing-system-based-on-OSPFv3
>
> Thanks, but could you please point us at your code? =A0That's a fu= ll
> Quagga tree merged with a full Click tree, with no development history= .
>
> (I've quickly checked the Quagga-FIB interface, and haven't fo= und
> anything new in there, but then perhaps I haven=92t looked hard enough= .)

Looks like the integration with click is done right from ospf6d= and it never even goes to zebra.

Two tips for next github export:

- save history so it=92s more convenient to compare with baseline (now I ne= eded to do fairly arcane diff due to non-clean tree + no history)

- put cleaned tree (no *~, no binaries such as *.o)

Kind of sad, I was hoping for general src+dst aware Quagga code :)

Cheers,

-Markus

--047d7beb9b5cdb3c0f04eb97738c-- From jouni.nospam@gmail.com Wed Nov 20 00:55:16 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@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: [homenet] [radext] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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 robmgl@cisco.com Tue Nov 19 07:16:57 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@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 X-Mailman-Approved-At: Wed, 20 Nov 2013 01:07:30 -0800 Cc: "radext@ietf.org" , "homenet@ietf.org" , "dhcwg@ietf.org WG" , Michael Richardson Subject: Re: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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: homenet@ietfa.amsl.com Delivered-To: homenet@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 X-Mailman-Approved-At: Wed, 20 Nov 2013 01:07:30 -0800 Cc: "radext@ietf.org" , "homenet@ietf.org" , "dhcwg@ietf.org WG" , Michael Richardson Subject: Re: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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 robmgl@cisco.com Tue Nov 19 09:10:53 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@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 X-Mailman-Approved-At: Wed, 20 Nov 2013 01:07:31 -0800 Cc: Michael Richardson , "radext@ietf.org" , Jouni Korhonen , "homenet@ietf.org" , "dhcwg@ietf.org WG" Subject: Re: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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 robmgl@cisco.com Tue Nov 19 09:47:55 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@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 X-Mailman-Approved-At: Wed, 20 Nov 2013 01:07:31 -0800 Cc: "radext@ietf.org" , Athanasios Douitsis , "Bernie Volz \(volz\)" , Michael Richardson , "dhcwg@ietf.org WG" , "homenet@ietf.org" Subject: Re: [homenet] [radext] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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 Wed Nov 20 01:59:09 2013 Return-Path: X-Original-To: homenet@ietfa.amsl.com Delivered-To: homenet@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: [homenet] [radext] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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: homenet@ietfa.amsl.com Delivered-To: homenet@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: [homenet] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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: homenet@ietfa.amsl.com Delivered-To: homenet@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: [homenet] [radext] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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: homenet@ietfa.amsl.com Delivered-To: homenet@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: [homenet] [radext] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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: homenet@ietfa.amsl.com Delivered-To: homenet@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: [homenet] [radext] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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: homenet@ietfa.amsl.com Delivered-To: homenet@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: [homenet] [radext] [dhcwg] PPP, DHCPv6 and Prefix Delegation X-BeenThere: homenet@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: 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