From joelja@bogus.com Thu Mar 1 00:37:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BACA21F85D8 for ; Thu, 1 Mar 2012 00:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 szK0WX6xrC-i for ; Thu, 1 Mar 2012 00:37:02 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 8D65121F85D7 for ; Thu, 1 Mar 2012 00:37:02 -0800 (PST) Received: from Joels-MacBook-Pro.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q218aYmn040083 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 1 Mar 2012 08:36:34 GMT (envelope-from joelja@bogus.com) Message-ID: <4F4F3511.8010307@bogus.com> Date: Thu, 01 Mar 2012 00:36:33 -0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Brian E Carpenter References: <4F4EE80D.6000106@gmail.com> In-Reply-To: <4F4EE80D.6000106@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 01 Mar 2012 08:36:35 +0000 (UTC) Cc: IPv6 Operations , Willy Tarreau Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 08:37:03 -0000 On 2/29/12 19:07 , Brian E Carpenter wrote: >> >> => Yes but they don't use flow labels for that. They use a unique >> application-specific identifier. >> flow label != cookie. The cookie is not created by the client. > > Correct, and it's a fairly horrible solution, isn't it? It forces > you into DPI for every packet in order to recognise the session. > That's *exactly* what needs to change. This is a fundamental misrepresentation of how load balancers work... If you're doing l3+l4 there's nothing to "DPI" because you have to dispatch a new TCP connection request on the basis of a SYN only, there's literally nothing to inspect. If you are doing L7 termination, for example with http(s), imap or even sip there's no packet inspection involved in plucking out a cookie, or login credentials or the like. From warren@kumari.net Thu Mar 1 07:02:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4A821E810D for ; Thu, 1 Mar 2012 07:02:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.166 X-Spam-Level: X-Spam-Status: No, score=-106.166 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, 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 5aIVL9ShPH-x for ; Thu, 1 Mar 2012 07:02:09 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 1743121E80BE for ; Thu, 1 Mar 2012 07:02:08 -0800 (PST) Received: from dhcp-172-19-119-93.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 570871B4003C; Thu, 1 Mar 2012 10:02:07 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <4F4EE80D.6000106@gmail.com> Date: Thu, 1 Mar 2012 10:02:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F4EE80D.6000106@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations , Willy Tarreau Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 15:02:10 -0000 Apologies for the top post -- this response isn't specific to this mail = (and is more of a meta-comment), so I am not responding inline... My initial response to this draft was fairly negative -- I latched onto = a shortcoming (mainly the fact that the flow label is client generated) = and didn't really give the whole idea the thought that it deserved -- I = apologize for this. What occurs to me is that load-balancers support all sorts of algorithms = and methods for mapping (session|flow|stream-o-bits) to a backend. If = this proposal / draft flies and gets adopted by the vendors, I (and you) = don't *have* to use it.... This will likely be implemented as yet another knob that can be enabled = or disabled as inout to the decision process -- if operators want to = turn the knob on, who am I to say no?=20 We all have different requirements, views, applications and traffic = distributions -- I don't see a downside to this idea, and it may have = utility, so I officially withdraw my earlier grumpy face :-) W On Feb 29, 2012, at 10:07 PM, Brian E Carpenter wrote: > Hesham, >=20 > On 2012-03-01 13:53, Hesham Soliman wrote: >>>=20 >>>>> Basically a browser would pick a random 20-bit number when opening = a >>>>> page and would assign this 20-bit random number to all outgoing >>>>> connections >>>>> to the same site, whether they're HTTP or HTTPS btw. >>>>=20 >>>> =3D> Is it safe enough to rely on the browser's 20 bit RNG and = ignore IP >>>> addresses?=20 >>> I'd say it differently. It's safe to rely on anything but the IP = address. >>=20 >> =3D> No one suggested that you rely on the address alone. >>=20 >>> One user !=3D one IP address. It's only an approximation which is = valid >>> enough where it's only used for optimization, but not where user = session >>> stickiness is required. >>=20 >> =3D> And the flow label can ensure that stickiness by itself? That's = a >> contradiction of what you're trying to do. >> If you want proper stickiness then you need unique application >> identifiers. If you think the user's IP address is not stable enough = and >> you want stronger stickiness then I'd say the flow label is much = worse. >> More below >>=20 >>> For instance, hashing a source IP address is fine >>> to load-balance an SSL farm, because most of the users will remain = on the >>> same SSL endpoint, and the small part of those who will constantly = change >>> will just experience a minor degradation which is not a show = stopper. But >>> it's totally different when you want to ensure that once you log = into a >>> server you need to remain on this one until you click the "logout" = button, >>> because this time you cannot accept to drop connections for even 1% = of >>> your >>> visitors. That's why LBs mostly rely on cookies and have to ignore = IP >>> addresses for this task. >>=20 >> =3D> Ok, but my point is that you can't compare flow labels and = cookies >> because you'll end up with either incorrect load distribution = (because the >> flow label doesn't tell you enough about the connection, or with = users >> being distributed onto different servers, depending on which side = your >> load distribution algorithm favours. What am I missing? >=20 > As the draft explains, you don't use the flow label to take the > initial decision about which server gets which new session. That > must be done by looking at much more of the first packet, exactly > as today. You use the flow label to accelerate treatment of the > subsequent packets. Please tell us where in the draft we need > to make this more clear. >=20 >> If you LB flow label 27 on server 1 blindly=20 >=20 > You don't do that. >=20 >> then you can very well end up >> with server 1 being busier than others. If you split flow label 27 = between >> servers 1 and 2 without any other considerations then you'll end up = where >> you don't want to be now. >=20 > Indeed, so you don't do that either. >=20 > You do accept the 1 in 2^20 chance that two unrelated sessions have = the > same flow label; in that case they will need to be redirected to the = same > server. In any case the LB is going to need a hash table to look up = current > flow labels, but it certainly contains a monstrous hash table today = for > other reasons. Server LBs are stateful beasts, unfortunately. >=20 > (In contrast to ECMP/LAG, which should be stateless.) >=20 >> Relying on applications to do the right thing (use a good RNG) for = your >> infrastructure to work seems like a proposition that could lead to >> unreliable results. >=20 > It can only be better than today, where there is zero entropy > in the flow label. The draft also discusses the case where the > source doesn't set the label. >=20 > As for choice of RNG, yes, it needs to be reasonable. I have some > results on this coming very soon. >=20 >>=20 >>> With a flow label, we have a lower layer alternative to stickiness >>> cookies. >>>=20 >>>> The discussion was related to the change in IP address and whether = the >>>> flow label helps in that case. >>> Yes precisely it does help. If you make it possible for the client = to set >>> the flow label on purpose on outgoing connections, and you make the = LBs >>> only rely on the flow label, then you're not sensitive to IP address >>> changes >>> anymore. These ones happen at enterprise proxies and in the mobile = world >>> where it's very common to lose access after some idle time. >>=20 >> =3D> Yes but they don't use flow labels for that. They use a unique >> application-specific identifier. >> flow label !=3D cookie. The cookie is not created by the client. >=20 > Correct, and it's a fairly horrible solution, isn't it? It forces > you into DPI for every packet in order to recognise the session. > That's *exactly* what needs to change. >=20 >>=20 >>>> Aside from the fact that this case is rare and probably not worth = the >>>> optimisation, my contention is that the flow label doesn't help = because >>>> it's not unique. >>> We don't need unicity (and we don't even want it). We need a large = enough >>> value so that not everyone goes to the same server. >>=20 >> =3D> Large enough numbers of clients producing a uniform distribution = of >> flow label values. What happens when the clients don't behave that = way? >=20 > The worst case is that the LB has to drop back to today's solutions. >=20 >>=20 >>> Some L3 load balancers >>> are still hashing on the lower 8 bits of IPv4 addresses right now. = It's >>> far from being unique and still it works for most purposes, provided = that >>> the number of servers is much less than 256. With 20 bits of = randomness, >>> you can have a fair distribution up to 1 million servers, or a bit = less >>> if you want to apply smooth weighting. >>>=20 >>>>> The LB would then >>>>> either hash this flow label or load-balance + stick on it, at the >>>> admin's >>>>> option. The general idea is to insert a session identifier in the >>>> packets >>>>> so that all packets related to a same user session can be = processed >>>>> equally >>>>> and directed to the same place, which is the hardest thing to do = right >>>> now >>>>> in load-balancing. >>>> =3D> I don't know if this is a sound idea to be honest. I can = understand >>>> the >>>> use of the flow label instead of port numbers when combined with IP >>>> addresses for load balancing. I think that's a fine thing to do. I = just >>>> don't think using the flow label alone as a session id is such a = good >>>> idea >>>> given the reliance on its uniqueness. It seems to optimise for a = rare >>>> case >>>> and for a small benefit. >>> It's not the rare case, it's the main case. Look at how load = balancing is >>> performed everywhere. IP address is never used when you need to = guarantee >>> user stickiness (eg: HTTP, RDP, ...). >>=20 >> =3D> Changing IP address is a rare case,=20 >=20 > I'll let Willy comment on that, but he tells me that it's a very = common > case, viewed from a server site. >=20 > I wasn't saying that identifying >> users is a rare case, lets not mix things. And yes of course user >> identification happens but this is done with a *unique* identifier. = You >> keep using *user* stickiness as a reason while ignoring that to = achieve >> *user* stickiness you need a unique identifier. The combination of >> unreliable number generators and load balancing based on those = numbers >> alone can end up with an undesirable effect. Do you disagree with = this >> statement?=20 >=20 > Again: that is not the model we describe in the draft. >=20 >>=20 >>=20 >>> That's even why LB vendors claim to >>> support a wide variety of protocols. In fact what they have to do is = to >>> pick the relevant part in the protocol to find the server associated = with >>> the session. For instance, in HTTP you have to parse L7 to find = cookies, >>> in HTTPS you first have to decipher SSL then to extract HTTP = cookies. In >>> RDP you have to either find the user ID or the server's address = which are >>> hashed in RDP cookies, etc... >>=20 >> =3D> Right, all about finding user-specific credentials that are = unique on >> the server side. You're replacing that with arbitrary numbers = generated by >> the client and claiming that it will have the same effect. In an = ideal >> world where clients behave, I think you have a good point, but if = clients >> don't behave, what will you do? >=20 > The worst case is that the LB has to drop back to today's solutions. > Also, there's an incentive for client stacks to do the right thing: > improved average application response time. >=20 > Regards > Brian > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 From w@1wt.eu Thu Mar 1 07:36:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C163621E81BF for ; Thu, 1 Mar 2012 07:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.441 X-Spam-Level: X-Spam-Status: No, score=-5.441 tagged_above=-999 required=5 tests=[AWL=-3.398, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] 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 0s6ycjlf8Ggt for ; Thu, 1 Mar 2012 07:36:02 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id CDBE421E80B8 for ; Thu, 1 Mar 2012 07:36:01 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q21FZmbl010838; Thu, 1 Mar 2012 16:35:48 +0100 Date: Thu, 1 Mar 2012 16:35:48 +0100 From: Willy Tarreau To: Warren Kumari Message-ID: <20120301153548.GF9937@1wt.eu> References: <4F4EE80D.6000106@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 15:36:03 -0000 Hi Warren, On Thu, Mar 01, 2012 at 10:02:05AM -0500, Warren Kumari wrote: > Apologies for the top post -- this response isn't specific to this mail (and > is more of a meta-comment), so I am not responding inline... > > My initial response to this draft was fairly negative -- I latched onto a > shortcoming (mainly the fact that the flow label is client generated) and > didn't really give the whole idea the thought that it deserved -- I apologize > for this. > > What occurs to me is that load-balancers support all sorts of algorithms and > methods for mapping (session|flow|stream-o-bits) to a backend. If this > proposal / draft flies and gets adopted by the vendors, I (and you) don't > *have* to use it.... > This will likely be implemented as yet another knob that can be enabled or > disabled as inout to the decision process -- if operators want to turn the > knob on, who am I to say no? > We all have different requirements, views, applications and traffic > distributions -- I don't see a downside to this idea, and it may have > utility, so I officially withdraw my earlier grumpy face :-) You're welcome, having people like you who ask for clarifying what we wrote is extremely important because it forces us to structure our ideas a bit more. The simple fact that people ask questions means we need to clarify our explanations :-) Regards, Willy From brian.e.carpenter@gmail.com Thu Mar 1 12:01:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E75C21E81E9 for ; Thu, 1 Mar 2012 12:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.509 X-Spam-Level: X-Spam-Status: No, score=-103.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 ntOsLemyCJZU for ; Thu, 1 Mar 2012 12:01:48 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC7221E81BB for ; Thu, 1 Mar 2012 12:01:48 -0800 (PST) Received: by eaaq11 with SMTP id q11so361271eaa.31 for ; Thu, 01 Mar 2012 12:01:47 -0800 (PST) Received-SPF: pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.14.28.205 as permitted sender) client-ip=10.14.28.205; Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.14.28.205 as permitted sender) smtp.mail=brian.e.carpenter@gmail.com; dkim=pass header.i=brian.e.carpenter@gmail.com Received: from mr.google.com ([10.14.28.205]) by 10.14.28.205 with SMTP id g53mr3771192eea.130.1330632107591 (num_hops = 1); Thu, 01 Mar 2012 12:01:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=SBCNDcANq/sw9nG/0F3WilN8eKFZGbyeD+X34icL8bA=; b=yRrY4NZn3jUaG3Erzpihogejyj5UagY1S/DQkSTUtPb5oZlAEbJBtxGYLwH1DOMAjo oVP7LgPmCjLPqElzOzJWsiyjWgEYljtD/2ky8X6SugBnLbow/HOeX9bdOWHLJfSKZhTi zqkpdPZtB1iih5vX9EjOjcC1Jc0wr4Nquda3y1l8S+MzR3IL9nplsaHcTd+Y4MyOPRgk BdRn4rzuBdvbgV1eTFfVtYsFHQpIFqGcPMN6PQTeJY1KkN56mmI3uhJojKqZJ4VtX58s 2UmEvb9WmPqf6SOtwU+sG1FLTq5fMDOww+v9fg3HuyQquWZu/y3T11nvxACnVTLvDWvq qmSw== Received: by 10.14.28.205 with SMTP id g53mr2896927eea.130.1330632107465; Thu, 01 Mar 2012 12:01:47 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id y14sm10850127eef.10.2012.03.01.12.01.43 (version=SSLv3 cipher=OTHER); Thu, 01 Mar 2012 12:01:46 -0800 (PST) Message-ID: <4F4FD5A2.5080602@gmail.com> Date: Fri, 02 Mar 2012 09:01:38 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joel jaeggli References: <4F4EE80D.6000106@gmail.com> <4F4F3511.8010307@bogus.com> In-Reply-To: <4F4F3511.8010307@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Willy Tarreau Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 20:01:49 -0000 On 2012-03-01 21:36, Joel jaeggli wrote: > On 2/29/12 19:07 , Brian E Carpenter wrote: > >>> => Yes but they don't use flow labels for that. They use a unique >>> application-specific identifier. >>> flow label != cookie. The cookie is not created by the client. >> Correct, and it's a fairly horrible solution, isn't it? It forces >> you into DPI for every packet in order to recognise the session. >> That's *exactly* what needs to change. > > This is a fundamental misrepresentation of how load balancers work... > > If you're doing l3+l4 there's nothing to "DPI" because you have to > dispatch a new TCP connection request on the basis of a SYN only, > there's literally nothing to inspect. If you are doing L7 termination, > for example with http(s), imap or even sip there's no packet inspection > involved in plucking out a cookie, or login credentials or the like. If you are mixing the two approaches, which I understand is common, it isn't that simple. When you see a new L4 flow starting, you have to check whether it is in fact part of an existing L7 flow but using a different address/port. I guess you are correct that once you have done this for the first full L7 packet (not the SYN packet), you can revert to only looking at the L3/L4 bits. But with IPv6 extension headers present, looking for L4 is extra work; the flow label is in a fixed place in the L3 header. Brian From hesham@elevatemobile.com Thu Mar 1 16:27:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1A9221E830F for ; Thu, 1 Mar 2012 16:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 2lI04h8yMNCz for ; Thu, 1 Mar 2012 16:27:32 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE1521E81B2 for ; Thu, 1 Mar 2012 16:27:31 -0800 (PST) Received: from [120.144.187.119] (helo=[10.0.0.67]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1S3GKr-0007tW-KE; Fri, 02 Mar 2012 11:27:03 +1100 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Fri, 02 Mar 2012 11:26:56 +1100 From: Hesham Soliman To: Brian E Carpenter Message-ID: Thread-Topic: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] In-Reply-To: <4F4EE80D.6000106@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: IPv6 Operations , Willy Tarreau Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 00:27:33 -0000 Thanks for the clarification Brian. I feel more comfortable with those answers below and I'm glad you're not relying on the flow label to make the initial decision, which makes it better. One other minor comment to make, I noticed, at least on email, references to "browsers" setting the flow label. I'm going to be a bit picky and say that we are really talking about (in the case of HTTP anyway) the HTTP lib picking the flow label. Browsers are just one of the many apps that use http nowadays and the less we rely on the app developers the more likely we are to get something behaving uniformly. Hesham -----Original Message----- From: Brian E Carpenter Organization: University of Auckland Date: Thu, 01 Mar 2012 16:07:57 +1300 To: Hesham Soliman Cc: Willy Tarreau , IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] >Hesham, > >On 2012-03-01 13:53, Hesham Soliman wrote: >>> >>>>> Basically a browser would pick a random 20-bit number when opening a >>>>> page and would assign this 20-bit random number to all outgoing >>>>> connections >>>>> to the same site, whether they're HTTP or HTTPS btw. >>>> >>>> => Is it safe enough to rely on the browser's 20 bit RNG and ignore IP >>>> addresses? >>> I'd say it differently. It's safe to rely on anything but the IP >>>address. >> >> => No one suggested that you rely on the address alone. >> >>> One user != one IP address. It's only an approximation which is valid >>> enough where it's only used for optimization, but not where user >>>session >>> stickiness is required. >> >> => And the flow label can ensure that stickiness by itself? That's a >> contradiction of what you're trying to do. >> If you want proper stickiness then you need unique application >> identifiers. If you think the user's IP address is not stable enough and >> you want stronger stickiness then I'd say the flow label is much worse. >> More below >> >>> For instance, hashing a source IP address is fine >>> to load-balance an SSL farm, because most of the users will remain on >>>the >>> same SSL endpoint, and the small part of those who will constantly >>>change >>> will just experience a minor degradation which is not a show stopper. >>>But >>> it's totally different when you want to ensure that once you log into a >>> server you need to remain on this one until you click the "logout" >>>button, >>> because this time you cannot accept to drop connections for even 1% of >>> your >>> visitors. That's why LBs mostly rely on cookies and have to ignore IP >>> addresses for this task. >> >> => Ok, but my point is that you can't compare flow labels and cookies >> because you'll end up with either incorrect load distribution (because >>the >> flow label doesn't tell you enough about the connection, or with users >> being distributed onto different servers, depending on which side your >> load distribution algorithm favours. What am I missing? > >As the draft explains, you don't use the flow label to take the >initial decision about which server gets which new session. That >must be done by looking at much more of the first packet, exactly >as today. You use the flow label to accelerate treatment of the >subsequent packets. Please tell us where in the draft we need >to make this more clear. > >> If you LB flow label 27 on server 1 blindly > >You don't do that. > >> then you can very well end up >> with server 1 being busier than others. If you split flow label 27 >>between >> servers 1 and 2 without any other considerations then you'll end up >>where >> you don't want to be now. > >Indeed, so you don't do that either. > >You do accept the 1 in 2^20 chance that two unrelated sessions have the >same flow label; in that case they will need to be redirected to the same >server. In any case the LB is going to need a hash table to look up >current >flow labels, but it certainly contains a monstrous hash table today for >other reasons. Server LBs are stateful beasts, unfortunately. > >(In contrast to ECMP/LAG, which should be stateless.) > >> Relying on applications to do the right thing (use a good RNG) for your >> infrastructure to work seems like a proposition that could lead to >> unreliable results. > >It can only be better than today, where there is zero entropy >in the flow label. The draft also discusses the case where the >source doesn't set the label. > >As for choice of RNG, yes, it needs to be reasonable. I have some >results on this coming very soon. > >> >>> With a flow label, we have a lower layer alternative to stickiness >>> cookies. >>> >>>> The discussion was related to the change in IP address and whether the >>>> flow label helps in that case. >>> Yes precisely it does help. If you make it possible for the client to >>>set >>> the flow label on purpose on outgoing connections, and you make the LBs >>> only rely on the flow label, then you're not sensitive to IP address >>> changes >>> anymore. These ones happen at enterprise proxies and in the mobile >>>world >>> where it's very common to lose access after some idle time. >> >> => Yes but they don't use flow labels for that. They use a unique >> application-specific identifier. >> flow label != cookie. The cookie is not created by the client. > >Correct, and it's a fairly horrible solution, isn't it? It forces >you into DPI for every packet in order to recognise the session. >That's *exactly* what needs to change. > >> >>>> Aside from the fact that this case is rare and probably not worth the >>>> optimisation, my contention is that the flow label doesn't help >>>>because >>>> it's not unique. >>> We don't need unicity (and we don't even want it). We need a large >>>enough >>> value so that not everyone goes to the same server. >> >> => Large enough numbers of clients producing a uniform distribution of >> flow label values. What happens when the clients don't behave that way? > >The worst case is that the LB has to drop back to today's solutions. > >> >>> Some L3 load balancers >>> are still hashing on the lower 8 bits of IPv4 addresses right now. It's >>> far from being unique and still it works for most purposes, provided >>>that >>> the number of servers is much less than 256. With 20 bits of >>>randomness, >>> you can have a fair distribution up to 1 million servers, or a bit less >>> if you want to apply smooth weighting. >>> >>>>> The LB would then >>>>> either hash this flow label or load-balance + stick on it, at the >>>> admin's >>>>> option. The general idea is to insert a session identifier in the >>>> packets >>>>> so that all packets related to a same user session can be processed >>>>> equally >>>>> and directed to the same place, which is the hardest thing to do >>>>>right >>>> now >>>>> in load-balancing. >>>> => I don't know if this is a sound idea to be honest. I can understand >>>> the >>>> use of the flow label instead of port numbers when combined with IP >>>> addresses for load balancing. I think that's a fine thing to do. I >>>>just >>>> don't think using the flow label alone as a session id is such a good >>>> idea >>>> given the reliance on its uniqueness. It seems to optimise for a rare >>>> case >>>> and for a small benefit. >>> It's not the rare case, it's the main case. Look at how load balancing >>>is >>> performed everywhere. IP address is never used when you need to >>>guarantee >>> user stickiness (eg: HTTP, RDP, ...). >> >> => Changing IP address is a rare case, > >I'll let Willy comment on that, but he tells me that it's a very common >case, viewed from a server site. > >I wasn't saying that identifying >> users is a rare case, lets not mix things. And yes of course user >> identification happens but this is done with a *unique* identifier. You >> keep using *user* stickiness as a reason while ignoring that to achieve >> *user* stickiness you need a unique identifier. The combination of >> unreliable number generators and load balancing based on those numbers >> alone can end up with an undesirable effect. Do you disagree with this >> statement? > >Again: that is not the model we describe in the draft. > >> >> >>> That's even why LB vendors claim to >>> support a wide variety of protocols. In fact what they have to do is to >>> pick the relevant part in the protocol to find the server associated >>>with >>> the session. For instance, in HTTP you have to parse L7 to find >>>cookies, >>> in HTTPS you first have to decipher SSL then to extract HTTP cookies. >>>In >>> RDP you have to either find the user ID or the server's address which >>>are >>> hashed in RDP cookies, etc... >> >> => Right, all about finding user-specific credentials that are unique on >> the server side. You're replacing that with arbitrary numbers generated >>by >> the client and claiming that it will have the same effect. In an ideal >> world where clients behave, I think you have a good point, but if >>clients >> don't behave, what will you do? > >The worst case is that the LB has to drop back to today's solutions. >Also, there's an incentive for client stacks to do the right thing: >improved average application response time. > >Regards > Brian From w@1wt.eu Thu Mar 1 17:08:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45DDE21E8108 for ; Thu, 1 Mar 2012 17:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.429 X-Spam-Level: X-Spam-Status: No, score=-3.429 tagged_above=-999 required=5 tests=[AWL=-5.374, BAYES_00=-2.599, FRT_STOCK2=3.988, HELO_IS_SMALL6=0.556] 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 2og7nEDCoofC for ; Thu, 1 Mar 2012 17:08:30 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 559B721E8187 for ; Thu, 1 Mar 2012 17:08:30 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q22185eB013994; Fri, 2 Mar 2012 02:08:05 +0100 Date: Fri, 2 Mar 2012 02:08:05 +0100 From: Willy Tarreau To: Hesham Soliman Message-ID: <20120302010805.GA13959@1wt.eu> References: <4F4EE80D.6000106@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 01:08:31 -0000 On Fri, Mar 02, 2012 at 11:26:56AM +1100, Hesham Soliman wrote: > Thanks for the clarification Brian. I feel more comfortable with those > answers below and I'm glad you're not relying on the flow label to make > the initial decision, which makes it better. > > One other minor comment to make, I noticed, at least on email, references > to "browsers" setting the flow label. I'm going to be a bit picky and say > that we are really talking about (in the case of HTTP anyway) the HTTP lib > picking the flow label. Browsers are just one of the many apps that use > http nowadays and the less we rely on the app developers the more likely > we are to get something behaving uniformly. You're perfectly right Hesham. I did personally use the term "browser" to illustrate what I meant but the process should happen at a lower layer, ideally in the lib handling the sockets. I've been thinking about using a couple of getsockopt() + setsockopt() to retrieve and set the flow label on a connection, so that's definitely where it ought to be. Regards, Willy From hesham@elevatemobile.com Thu Mar 1 17:15:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 258AE21E8370 for ; Thu, 1 Mar 2012 17:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.505 X-Spam-Level: X-Spam-Status: No, score=-0.505 tagged_above=-999 required=5 tests=[AWL=-1.894, BAYES_00=-2.599, FRT_STOCK2=3.988] 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 f6VPTwRlI9eR for ; Thu, 1 Mar 2012 17:15:09 -0800 (PST) Received: from smtp-1.servers.netregistry.net (smtp.netregistry.net [202.124.241.204]) by ietfa.amsl.com (Postfix) with ESMTP id D73E721E836E for ; Thu, 1 Mar 2012 17:15:08 -0800 (PST) Received: from [120.144.187.119] (helo=[10.0.0.67]) by smtp-1.servers.netregistry.net protocol: esmtpa (Exim 4.69 #1 (Debian)) id 1S3H5M-0007ZN-C7; Fri, 02 Mar 2012 12:15:05 +1100 User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Fri, 02 Mar 2012 12:14:55 +1100 From: Hesham Soliman To: Willy Tarreau Message-ID: Thread-Topic: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] In-Reply-To: <20120302010805.GA13959@1wt.eu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-User: hesham@elevatemobile.com Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 01:15:10 -0000 >On Fri, Mar 02, 2012 at 11:26:56AM +1100, Hesham Soliman wrote: >> Thanks for the clarification Brian. I feel more comfortable with those >> answers below and I'm glad you're not relying on the flow label to make >> the initial decision, which makes it better. >> >> One other minor comment to make, I noticed, at least on email, >>references >> to "browsers" setting the flow label. I'm going to be a bit picky and >>say >> that we are really talking about (in the case of HTTP anyway) the HTTP >>lib >> picking the flow label. Browsers are just one of the many apps that use >> http nowadays and the less we rely on the app developers the more likely >> we are to get something behaving uniformly. > >You're perfectly right Hesham. I did personally use the term "browser" to >illustrate what I meant but the process should happen at a lower layer, >ideally in the lib handling the sockets. I've been thinking about using a >couple of getsockopt() + setsockopt() to retrieve and set the flow label >on a connection, so that's definitely where it ought to be. => Cool, then we're on the same page. thanks, Hesham > >Regards, >Willy > From brian.e.carpenter@gmail.com Thu Mar 1 18:55:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B707521E801F for ; Thu, 1 Mar 2012 18:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.517 X-Spam-Level: X-Spam-Status: No, score=-101.517 tagged_above=-999 required=5 tests=[AWL=-1.906, BAYES_00=-2.599, FRT_STOCK2=3.988, RCVD_IN_DNSWL_LOW=-1, 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 cjYjuHcxQOOU for ; Thu, 1 Mar 2012 18:55:08 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id D981A21E800E for ; Thu, 1 Mar 2012 18:55:07 -0800 (PST) Received: by eaaq11 with SMTP id q11so439839eaa.31 for ; Thu, 01 Mar 2012 18:55:07 -0800 (PST) Received-SPF: pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.213.104.140 as permitted sender) client-ip=10.213.104.140; Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.213.104.140 as permitted sender) smtp.mail=brian.e.carpenter@gmail.com; dkim=pass header.i=brian.e.carpenter@gmail.com Received: from mr.google.com ([10.213.104.140]) by 10.213.104.140 with SMTP id p12mr152788ebo.111.1330656907159 (num_hops = 1); Thu, 01 Mar 2012 18:55:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Ebt3hwc9cz96Htc2l/fLYJFyAsI4+kq8EMTpujCKLdw=; b=GWzbYrhtprTA99+q0Uqpwzb8x/cx/n6G+8McFVVPqGQewaXriooOnqKAKEDPX3mTYV ZA5xfzA6EhffzrZ4+cLNWuHWk5R9TFZ0+cONmOfuob/JPmtD8reGFJkEyWg56Mf5FUNI Jx/nNyZkj3jMWnWarIbI/yRwwRt3RvPjrXkaFjvuvdrkIhydo7F3akNPans4FD17ZW3Z WIt8Bcl8etRDcETYN29GmvuwjqkcNNk4vKSzTRT7NKOdd9KkZkYLdpJKgE+nz2l+A6LZ Lstis6WNKh/8tkjqT2oOt52DQlEwKVVzzIkm7/mu4wDNBWLgDmdm+9x70wO8uTdt3miA 3bmA== Received: by 10.213.104.140 with SMTP id p12mr122519ebo.111.1330656907057; Thu, 01 Mar 2012 18:55:07 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id u9sm14670211eem.11.2012.03.01.18.55.03 (version=SSLv3 cipher=OTHER); Thu, 01 Mar 2012 18:55:06 -0800 (PST) Message-ID: <4F503681.1010607@gmail.com> Date: Fri, 02 Mar 2012 15:54:57 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Willy Tarreau References: <4F4EE80D.6000106@gmail.com> <20120302010805.GA13959@1wt.eu> In-Reply-To: <20120302010805.GA13959@1wt.eu> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 02:55:08 -0000 On 2012-03-02 14:08, Willy Tarreau wrote: > On Fri, Mar 02, 2012 at 11:26:56AM +1100, Hesham Soliman wrote: >> Thanks for the clarification Brian. I feel more comfortable with those >> answers below and I'm glad you're not relying on the flow label to make >> the initial decision, which makes it better. >> >> One other minor comment to make, I noticed, at least on email, references >> to "browsers" setting the flow label. I'm going to be a bit picky and say >> that we are really talking about (in the case of HTTP anyway) the HTTP lib >> picking the flow label. Browsers are just one of the many apps that use >> http nowadays and the less we rely on the app developers the more likely >> we are to get something behaving uniformly. > > You're perfectly right Hesham. I did personally use the term "browser" to > illustrate what I meant but the process should happen at a lower layer, > ideally in the lib handling the sockets. I've been thinking about using a > couple of getsockopt() + setsockopt() to retrieve and set the flow label > on a connection, so that's definitely where it ought to be. Yes. The advanced socket API (RFC 3542) left this as future work. It does define it in the header structure uint32_t ip6_un1_flow; /* 4 bits version, 8 bits TC, 20 bits flow-ID */ but doesn't use it. Maybe it's time to fix that. Brian From washam.fan@gmail.com Thu Mar 1 21:12:14 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA09F21F8941 for ; Thu, 1 Mar 2012 21:12:14 -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 LleaDH7TSweQ for ; Thu, 1 Mar 2012 21:12:14 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id CBDBC21F893F for ; Thu, 1 Mar 2012 21:12:13 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so837645wgb.13 for ; Thu, 01 Mar 2012 21:12:13 -0800 (PST) Received-SPF: pass (google.com: domain of washam.fan@gmail.com designates 10.180.103.97 as permitted sender) client-ip=10.180.103.97; Authentication-Results: mr.google.com; spf=pass (google.com: domain of washam.fan@gmail.com designates 10.180.103.97 as permitted sender) smtp.mail=washam.fan@gmail.com; dkim=pass header.i=washam.fan@gmail.com Received: from mr.google.com ([10.180.103.97]) by 10.180.103.97 with SMTP id fv1mr1605894wib.17.1330665133084 (num_hops = 1); Thu, 01 Mar 2012 21:12:13 -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:content-transfer-encoding; bh=8IW7F6wEQcBngU5lFGD5UYuN7OdmOOz9qbWUULbAIBs=; b=KPy6y7es75szCjPZ/Z/KuGF2rM3qN6DneQsmT+KMSWfKAvV8+wnxQtIA3ThJCtonHU Si1joDs/KL9tXzMRhNmW6q4s9vNq2LeG+XRm/50l615lGQPN/6DIWx9eCGEma+rjJItR bf6Bol23FrehVf1+ok34CgEUz/2igZuH3c3DbkIvi11BFdPuZIG51kV50kVNFO++UvAa Qk8KxoMJXMvr969ApNTIy6wTEWuDZRSMvX0I9uXqTTmMazjfH312py84yE3GxJdaes/i y9UY96SF24Op5pOt65TneqngfdywQF3H/dxpyz00gPgSIJlhoLBsZWfDBLxKsdgAwEzQ lNcw== MIME-Version: 1.0 Received: by 10.180.103.97 with SMTP id fv1mr1300935wib.17.1330665133010; Thu, 01 Mar 2012 21:12:13 -0800 (PST) Received: by 10.216.1.6 with HTTP; Thu, 1 Mar 2012 21:12:12 -0800 (PST) In-Reply-To: <4F4FD5A2.5080602@gmail.com> References: <4F4EE80D.6000106@gmail.com> <4F4F3511.8010307@bogus.com> <4F4FD5A2.5080602@gmail.com> Date: Fri, 2 Mar 2012 13:12:12 +0800 Message-ID: From: Washam Fan To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , Willy Tarreau Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 05:12:14 -0000 Hi Brian, 2012/3/2 Brian E Carpenter : > On 2012-03-01 21:36, Joel jaeggli wrote: >> On 2/29/12 19:07 , Brian E Carpenter wrote: >> >>>> =3D> Yes but they don't use flow labels for that. They use a unique >>>> application-specific identifier. >>>> flow label !=3D cookie. The cookie is not created by the client. >>> Correct, and it's a fairly horrible solution, isn't it? It forces >>> you into DPI for every packet in order to recognise the session. >>> That's *exactly* what needs to change. >> >> This is a fundamental misrepresentation of how load balancers work... >> >> If you're doing l3+l4 there's nothing to "DPI" because you have to >> dispatch a new TCP connection request on the basis of a SYN only, >> there's literally nothing to inspect. If you are doing L7 termination, >> for =A0example with http(s), imap or even sip there's no packet inspecti= on >> involved in plucking out a cookie, or login credentials or the like. > > If you are mixing the two approaches, which I understand is common, > it isn't that simple. When you see a new L4 flow starting, you have to > check whether it is in fact part of an existing L7 flow but using > a different address/port. > > I guess you are correct that once you have done this for the first full > L7 packet (not the SYN packet), you can revert to only looking at the > L3/L4 bits. But with IPv6 extension headers present, looking for L4 > is extra work; the flow label is in a fixed place in the L3 header. > What you said above is for the case where flow label is used to identify the 'transport layer' session (5 tuples) the packet is belonging to (although the load distribution algorithm is based on L7 identifer). I think everyone should OK with this. But in the section 3, it mentions flow label is used to identify the 'application layer' session the packet is belonging to. there are also two sub-case here: one is, for all 'transport layer' sessions between a given src IP and a given dest IP, flow label could be used to bind multiple such 'transport layer' sessions to a same 'application layer' session by setting the same value for the flow label field. Persionally i think it is OK as far as the application software is trusted to do this. the other is, for all 'transport layer' sessions between a given host with changing IPs and a given dest IP. flow label could be used to bind multiple such 'transport layer' sessions to a same 'application layer' session by setting the same value for the flow label field. Persionally I think it is not OK. And some other people have raised security concerns about this. in the flow label spec, it suggests flow label should be used with other fields like srcIP and destIP to identify a session, since the srcIP is changing, i don't think it would be compliant with the flow label spec if we allow this. Thanks, washam From w@1wt.eu Thu Mar 1 23:06:07 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69A1521F8B3A for ; Thu, 1 Mar 2012 23:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.373 X-Spam-Level: X-Spam-Status: No, score=-5.373 tagged_above=-999 required=5 tests=[AWL=-3.330, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] 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 eDBzrGrl74n8 for ; Thu, 1 Mar 2012 23:06:06 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 9612221F8A4B for ; Thu, 1 Mar 2012 23:06:00 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q2275pOO015489; Fri, 2 Mar 2012 08:05:51 +0100 Date: Fri, 2 Mar 2012 08:05:51 +0100 From: Willy Tarreau To: Washam Fan Message-ID: <20120302070551.GB13959@1wt.eu> References: <4F4EE80D.6000106@gmail.com> <4F4F3511.8010307@bogus.com> <4F4FD5A2.5080602@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 07:06:07 -0000 Hi Washam, On Fri, Mar 02, 2012 at 01:12:12PM +0800, Washam Fan wrote: > the other is, for all 'transport layer' sessions between a given host > with changing IPs and a given dest IP. flow label could be used to > bind multiple such 'transport layer' sessions to a same 'application > layer' session by setting the same value for the flow label field. > Persionally I think it is not OK. And some other people have raised > security concerns about this. in the flow label spec, it suggests flow > label should be used with other fields like srcIP and destIP to > identify a session, since the srcIP is changing, i don't think it > would be compliant with the flow label spec if we allow this. The reasons for this have been explained in this thread. Basically, if the srcIP is used at all to consider the flow label, then there is no point using flow labels for this task since the main goal is to be able to do what is currently done at layer 7 because srcIP is not a reliable criterion for load balancing and stickiness. srcIP breaks stickiness by changing for a small but real percentage of users. So in short, if srcIP needs to be considered with flow label, then neither will be used (as it is today) and L7 only will continue to be used (as it is today too). The security concerns that were raised can be moderated in that they are the ones that currently affect all load balanced infrastructures working at layer 7 (eg: ~all). Regards, Willy From washam.fan@gmail.com Fri Mar 2 02:18:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B5721F89E5 for ; Fri, 2 Mar 2012 02:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 s+fJFPBuGl7t for ; Fri, 2 Mar 2012 02:18:36 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC9A21F89E4 for ; Fri, 2 Mar 2012 02:18:36 -0800 (PST) Received: by wicr5 with SMTP id r5so668267wic.31 for ; Fri, 02 Mar 2012 02:18:35 -0800 (PST) Received-SPF: pass (google.com: domain of washam.fan@gmail.com designates 10.180.80.8 as permitted sender) client-ip=10.180.80.8; Authentication-Results: mr.google.com; spf=pass (google.com: domain of washam.fan@gmail.com designates 10.180.80.8 as permitted sender) smtp.mail=washam.fan@gmail.com; dkim=pass header.i=washam.fan@gmail.com Received: from mr.google.com ([10.180.80.8]) by 10.180.80.8 with SMTP id n8mr3766387wix.14.1330683515833 (num_hops = 1); Fri, 02 Mar 2012 02:18: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=bs+qTXKHOQZV+bJqIoOzWsXdp/gjMw0qnFH+7nAeKJs=; b=njCKvzNvc+S95fSPtLZC1+EUkW7DpgmtYLNrtC0kiKiKuNmL2FamVyhr3APioSSKfu opYXN7gjJWOB0Lc3TUd0ToA/D4LQ4/wxNvTGt4ZBp0ILxRV72m6wYzTK4D4phrwBksdf j7ycAf5f7rKXfoRDdktky7tZIqQEdGEuSvmIW0kyKHeZwFCHS6OIHhY9v1J1IwEFDh9x VSHV9jnJ8ZccBB3FcPxqgN9fi+aJWZbsZb1MnL6hvFt8Q2HvBx+2jXHhVWx7VthNhM5j kJgHtDfbvkFp8/FBJovHH2yWNRu9oFaOL9dRdFO1XzzR8FGXLF7IQo6tHFl1oNPrb4c+ FnDQ== MIME-Version: 1.0 Received: by 10.180.80.8 with SMTP id n8mr3007441wix.14.1330683515737; Fri, 02 Mar 2012 02:18:35 -0800 (PST) Received: by 10.216.1.6 with HTTP; Fri, 2 Mar 2012 02:18:35 -0800 (PST) In-Reply-To: <20120302070551.GB13959@1wt.eu> References: <4F4EE80D.6000106@gmail.com> <4F4F3511.8010307@bogus.com> <4F4FD5A2.5080602@gmail.com> <20120302070551.GB13959@1wt.eu> Date: Fri, 2 Mar 2012 18:18:35 +0800 Message-ID: From: Washam Fan To: Willy Tarreau Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 10:18:37 -0000 Hi Willy, 2012/3/2 Willy Tarreau : > Hi Washam, > > On Fri, Mar 02, 2012 at 01:12:12PM +0800, Washam Fan wrote: >> the other is, for all 'transport layer' sessions between a given host >> with changing IPs and a given dest IP. flow label could be used to >> bind multiple such 'transport layer' sessions to a same 'application >> layer' session by setting the same value for the flow label field. >> Persionally I think it is not OK. And some other people have raised >> security concerns about this. in the flow label spec, it suggests flow >> label should be used with other fields like srcIP and destIP to >> identify a session, since the srcIP is changing, i don't think it >> would be compliant with the flow label spec if we allow this. > > The reasons for this have been explained in this thread. Basically, if > the srcIP is used at all to consider the flow label, then there is no > point using flow labels for this task since the main goal is to be able > to do what is currently done at layer 7 because srcIP is not a reliable > criterion for load balancing and stickiness. srcIP breaks stickiness by > changing for a small but real percentage of users. So in short, if srcIP > needs to be considered with flow label, then neither will be used (as it > is today) and L7 only will continue to be used (as it is today too). > > The security concerns that were raised can be moderated in that they are > the ones that currently affect all load balanced infrastructures working > at layer 7 (eg: ~all). I am not sure if i understand completely. My interpretation of the draft is, flow label is not used for choosing a backend server. L7 identifier is still used to choosing a backend server, but the {srcIP, flow label} can be used to identify all subsequent packets belonging to the same L4 or L7 session. If the srcIP changes, flow label alone can not be used to identify any session. I suggest to remove the scenario in section 3 where flow label is used across different srcIPs. Thanks, washam From w@1wt.eu Fri Mar 2 03:21:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58E921F8BED for ; Fri, 2 Mar 2012 03:21:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.342 X-Spam-Level: X-Spam-Status: No, score=-5.342 tagged_above=-999 required=5 tests=[AWL=-3.299, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] 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 ArXzx4cv6JzJ for ; Fri, 2 Mar 2012 03:21:39 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 8F33021F8BE0 for ; Fri, 2 Mar 2012 03:21:37 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q22BLUvO016914; Fri, 2 Mar 2012 12:21:30 +0100 Date: Fri, 2 Mar 2012 12:21:30 +0100 From: Willy Tarreau To: Washam Fan Message-ID: <20120302112130.GB16141@1wt.eu> References: <4F4EE80D.6000106@gmail.com> <4F4F3511.8010307@bogus.com> <4F4FD5A2.5080602@gmail.com> <20120302070551.GB13959@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 11:21:40 -0000 Hi Washam, On Fri, Mar 02, 2012 at 06:18:35PM +0800, Washam Fan wrote: > Hi Willy, > > 2012/3/2 Willy Tarreau : > > Hi Washam, > > > > On Fri, Mar 02, 2012 at 01:12:12PM +0800, Washam Fan wrote: > >> the other is, for all 'transport layer' sessions between a given host > >> with changing IPs and a given dest IP. flow label could be used to > >> bind multiple such 'transport layer' sessions to a same 'application > >> layer' session by setting the same value for the flow label field. > >> Persionally I think it is not OK. And some other people have raised > >> security concerns about this. in the flow label spec, it suggests flow > >> label should be used with other fields like srcIP and destIP to > >> identify a session, since the srcIP is changing, i don't think it > >> would be compliant with the flow label spec if we allow this. > > > > The reasons for this have been explained in this thread. Basically, if > > the srcIP is used at all to consider the flow label, then there is no > > point using flow labels for this task since the main goal is to be able > > to do what is currently done at layer 7 because srcIP is not a reliable > > criterion for load balancing and stickiness. srcIP breaks stickiness by > > changing for a small but real percentage of users. So in short, if srcIP > > needs to be considered with flow label, then neither will be used (as it > > is today) and L7 only will continue to be used (as it is today too). > > > > The security concerns that were raised can be moderated in that they are > > the ones that currently affect all load balanced infrastructures working > > at layer 7 (eg: ~all). > > I am not sure if i understand completely. My interpretation of the > draft is, flow label is not used for choosing a backend server. L7 > identifier is still used to choosing a backend server, but the {srcIP, > flow label} can be used to identify all subsequent packets belonging > to the same L4 or L7 session. No it's not what is suggested, so we'll probably need to rework it. The main algorithm is : - if flow label is not present, fall back to current methods (eg: L7 or srcIP) - if flow label is present and known, use it to select the proper server - if flow label is present and not known, apply the usual load balancing algorithm to select the server and remember the flow label <-> server mapping. It is *likely* that some admins will also prefer to apply a simple hash on flow labels the following way, though this is not what is suggested right now : - if flow label is not present, fall back to current methods (eg: L7 or srcIP) - if flow label is present, hash it and use the result as the server number. I think we'll have to discuss both methods in the draft separately to wipe any risk of misunderstanding. > If the srcIP changes, flow label alone can not be used to identify any > session. I suggest to remove the scenario in section 3 where flow > label is used across different srcIPs. On the opposite, flow label here makes it possible to perform load balancing across multiple srcIP which precisely is what saves the load balancer from having to perform L7 DPI. Otherwise the srcIP alone would be enough. Regards, Willy From evyncke@cisco.com Fri Mar 2 04:21:51 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F1321F8B76 for ; Fri, 2 Mar 2012 04:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.377 X-Spam-Level: X-Spam-Status: No, score=-10.377 tagged_above=-999 required=5 tests=[AWL=0.222, 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 MTZDdQLC6tRK for ; Fri, 2 Mar 2012 04:21:50 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id B4B9421F8B61 for ; Fri, 2 Mar 2012 04:21:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=evyncke@cisco.com; l=2414; q=dns/txt; s=iport; t=1330690909; x=1331900509; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=wfIidmZTO/ZdAsU4j3P5RITSSob16kHGEriDjQaUzL4=; b=J55F/LzmFqCJmfhkIlm8Y5Sdrt3nBNZJCHHWAVmgGgCoavboGnU1mSUa AdxPHgjy6tDCBYCZMhIrKt6C1HzsuG+2K0mcIMxMC2trRPjamQXxshKkm N7BCH94t3TL5EdscK+ao/o+eWAE1PhXy/5UgMm6+TuUf11qhjDn2RGs1d I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAM26UE+Q/khM/2dsb2JhbAApGoUyrX54gQeBfQEBAQQSARANBEMOBgECBhEEAQEDAgYGFwECAgMBHyUHAQEFBAEEEwgBGYdkCymZUYEnAYxlkhaBL4dxgyKCDDNjBKBUBYdY X-IronPort-AV: E=Sophos;i="4.73,517,1325462400"; d="scan'208";a="67537554" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 02 Mar 2012 12:21:48 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q22CLmq8017745 for ; Fri, 2 Mar 2012 12:21:48 GMT Received: from xmb-ams-110.cisco.com ([144.254.74.85]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 2 Mar 2012 13:21:48 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Fri, 2 Mar 2012 13:21:47 +0100 Message-ID: <317616CE96204D49B5A1811098BA895006B6DFDE@XMB-AMS-110.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-vyncke-ipv6-traffic-in-p2p-networks-01.txt Thread-Index: Acz4bpm9nQc8goYNSbSDqeHDzNCzbQAADabw X-Priority: 5 priority: Non-Urgent Importance: low From: "Eric Vyncke (evyncke)" To: X-OriginalArrivalTime: 02 Mar 2012 12:21:48.0760 (UTC) FILETIME=[0A780D80:01CCF86F] Subject: [v6ops] FW: New Version Notification for draft-vyncke-ipv6-traffic-in-p2p-networks-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 12:21:51 -0000 VXBkYXRlZCB2ZXJzaW9uIHdpdGggbW9yZSByZWNlbnQgc3RhdGlzdGljcyBhYm91dCBCaXRUb3Jy ZW50IHBlZXJzIHVzaW5nIG9yIG5vdCBJUHY2LiBGb3IgYSBtb3JlIGdyYXBoaWNhbCB2ZXJzaW9u Og0KaHR0cDovL3d3dy52eW5ja2Uub3JnL2lwdjZzdGF0dXMvcDJwLnBocA0KDQotw6lyaWMNCg0K LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9y ZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiB2ZW5kcmVkaSAyIG1h cnMgMjAxMiAxMzoxOA0KVG86IEVyaWMgVnluY2tlIChldnluY2tlKQ0KQ2M6IG1hcnRpbi5kZWZl Y2hlQGdtYWlsLmNvbQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcmRyYWZ0 LXZ5bmNrZS1pcHY2LXRyYWZmaWMtaW4tcDJwLW5ldHdvcmtzLTAxLnR4dA0KDQpBIG5ldyB2ZXJz aW9uIG9mIEktRCwgZHJhZnQtdnluY2tlLWlwdjYtdHJhZmZpYy1pbi1wMnAtbmV0d29ya3MtMDEu dHh0IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgRXJpYyBWeW5ja2UgYW5kIHBv c3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LXZ5bmNrZS1p cHY2LXRyYWZmaWMtaW4tcDJwLW5ldHdvcmtzDQpSZXZpc2lvbjoJIDAxDQpUaXRsZToJCSBNZWFz dXJpbmcgSVB2NiBUcmFmZmljIGluIEJpdFRvcnJlbnQgTmV0d29ya3MNCkNyZWF0aW9uIGRhdGU6 CSAyMDEyLTAzLTAyDQpXRyBJRDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBw YWdlczogMTINCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGlzIGEgZm9sbG93LXVwIG9m IGEgVW5pdmVyc2l0eSB0aGVzaXMgd2hpY2ggYWltcyB0bw0KICAgbWVhc3VyZSB0aGUgZXZvbHV0 aW9uIG92ZXIgdGltZSBvZiBJUHY2IHRyYWZmaWMgYW5kIHRvIGFuYWx5emUgdGhlDQogICBnZW9n cmFwaGljYWwgZGlzdHJpYnV0aW9uIG9mIElQdjYgbm9kZXMuICBUaGUgZmlyc3QgbWVhc3VyZW1l bnRzIHdlcmUNCiAgIGRvbmUgZHVyaW5nIHRoZSBTdW1tZXIgMjAwOSB1c2luZyBhIHNwZWNpZmlj LXB1cnBvc2UgcHJvZ3JhbSB3aGljaA0KICAgY29ubmVjdHMgdG8gdGhlIEJpdFRvcnJlbnQgcGVl ci10by1wZWVyIG5ldHdvcmsgYW5kIHRoaXMgZG9jdW1lbnQNCiAgIGFkZHMgbWVhc3VyZW1lbnRz IGRvbmUgd2l0aCB0aGUgc2FtZSBwcm9ncmFtIGJ1dCBpbiBPY3RvYmVyIDIwMTEgYW5kDQogICBG ZWJydWFyeSAyMDEyLg0KDQogICBUaGUgc3R1ZHkgd2FzIG1hZGUgaW4gUGVlci10by1QZWVyIChQ MlApIG5ldHdvcmtzIGJlY2F1c2UgdGhleSBhcmUNCiAgIHJlc3BvbnNpYmxlIGZvciBhIGJpZyBw YXJ0IG9mIEludGVybmV0IHRyYWZmaWMgYW5kIGJlY2F1c2UgdGhlaXINCiAgIHN0cnVjdHVyZSBh bmQgZnVuY3Rpb25pbmcgcGVybWl0IGEgcmFwaWQgZGlzY292ZXJ5IG9mIGEgbGFyZ2UgbnVtYmVy DQogICBvZiBub2RlcyBmcm9tIGFsbCBvdmVyIHRoZSB3b3JsZC4gIEluIGFkZGl0aW9uLCB0aGUg UDJQIHVzZXJzIGFyZQ0KICAgbW9yZSBsaWtlbHkgdG8gYmUgaW50ZXJlc3RlZCBieSBJUHY2IGFz IElQdjYgZG9lcyBub3QgaGF2ZSB0aGUgc2FtZQ0KICAgTkFUIHByb2JsZW1zIGFzIElQdjQuDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0K From washam.fan@gmail.com Fri Mar 2 04:59:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCDC521F869E for ; Fri, 2 Mar 2012 04:59:55 -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 priwAK6SnzeO for ; Fri, 2 Mar 2012 04:59:55 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id AF00C21F869A for ; Fri, 2 Mar 2012 04:59:54 -0800 (PST) Received: by werb10 with SMTP id b10so1371888wer.31 for ; Fri, 02 Mar 2012 04:59:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2RTs93bpgBN+JaeiOVYQp2ZymfGIps8sezytplDQFEs=; b=wdpmkOrcQZY4zhaGZoNa+DpDV1bwOgI9Bli8rtoNsknNkqznvbKhCyqrvqlTDamEqP pXTnpLWZ64XrzWLSb2jDyLvJM+nAlEUZRtsVhTgNfKASatQDeDyQe47Fl0cVzaedpFtN BFhOkQi+5OrlJyqatAZPT94/A5U1JbCyz3eQA= MIME-Version: 1.0 Received: by 10.180.100.196 with SMTP id fa4mr4843235wib.0.1330693193646; Fri, 02 Mar 2012 04:59:53 -0800 (PST) Received: by 10.216.1.6 with HTTP; Fri, 2 Mar 2012 04:59:53 -0800 (PST) In-Reply-To: <20120302112130.GB16141@1wt.eu> References: <4F4EE80D.6000106@gmail.com> <4F4F3511.8010307@bogus.com> <4F4FD5A2.5080602@gmail.com> <20120302070551.GB13959@1wt.eu> <20120302112130.GB16141@1wt.eu> Date: Fri, 2 Mar 2012 20:59:53 +0800 Message-ID: From: Washam Fan To: Willy Tarreau Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 12:59:55 -0000 Hi Willy, Thanks for your prompt response, please see inline. 2012/3/2 Willy Tarreau : > Hi Washam, > > On Fri, Mar 02, 2012 at 06:18:35PM +0800, Washam Fan wrote: >> Hi Willy, >> >> 2012/3/2 Willy Tarreau : >> > Hi Washam, >> > >> > On Fri, Mar 02, 2012 at 01:12:12PM +0800, Washam Fan wrote: >> >> the other is, for all 'transport layer' sessions between a given host >> >> with changing IPs and a given dest IP. flow label could be used to >> >> bind multiple such 'transport layer' sessions to a same 'application >> >> layer' session by setting the same value for the flow label field. >> >> Persionally I think it is not OK. And some other people have raised >> >> security concerns about this. in the flow label spec, it suggests flo= w >> >> label should be used with other fields like srcIP and destIP to >> >> identify a session, since the srcIP is changing, i don't think it >> >> would be compliant with the flow label spec if we allow this. >> > >> > The reasons for this have been explained in this thread. Basically, if >> > the srcIP is used at all to consider the flow label, then there is no >> > point using flow labels for this task since the main goal is to be abl= e >> > to do what is currently done at layer 7 because srcIP is not a reliabl= e >> > criterion for load balancing and stickiness. srcIP breaks stickiness b= y >> > changing for a small but real percentage of users. So in short, if src= IP >> > needs to be considered with flow label, then neither will be used (as = it >> > is today) and L7 only will continue to be used (as it is today too). >> > >> > The security concerns that were raised can be moderated in that they a= re >> > the ones that currently affect all load balanced infrastructures worki= ng >> > at layer 7 (eg: ~all). >> >> I am not sure if i understand completely. My interpretation of the >> draft is, flow label is not used for choosing a backend server. L7 >> identifier is still used to choosing a backend server, but the {srcIP, >> flow label} can be used to identify all subsequent packets belonging >> to the same L4 or L7 session. > > No it's not what is suggested, so we'll probably need to rework it. > > The main algorithm is : > > =A0- if flow label is not present, fall back to current methods (eg: L7 o= r srcIP) > =A0- if flow label is present and known, use it to select the proper serv= er > =A0- if flow label is present and not known, apply the usual load balanci= ng > =A0 =A0algorithm to select the server and remember the flow label <-> ser= ver > =A0 =A0mapping. Yes. this algorithm is how the draft suggests, IMHO. > It is *likely* that some admins will also prefer to apply a simple hash o= n > flow labels the following way, though this is not what is suggested right= now : > > =A0- if flow label is not present, fall back to current methods (eg: L7 o= r srcIP) > =A0- if flow label is present, hash it and use the result as the server n= umber. This algorithm is not what the draft is trying to express, but many people on the mailing list think that way, IMHO. > I think we'll have to discuss both methods in the draft separately to wip= e > any risk of misunderstanding. > >> If the srcIP changes, flow label alone can not be used to identify any >> session. I suggest to remove the scenario in section 3 where flow >> label is used across different srcIPs. > > On the opposite, flow label here makes it possible to perform load balanc= ing > across multiple srcIP which precisely is what saves the load balancer fro= m > having to perform L7 DPI. Otherwise the srcIP alone would be enough. flow label should always be used with other fields like srcIP, destIP to identify a session, per RFC6437. {srcIP, flow label} saves the load balancer from having to perform L7 DPI on subsequent packets belonging to the same session while load balancer has to perform L7 DPI anyway on the first packet on the session. If flow label alone can identify a session without srcIP, let's say. an attacker can easily launch the attach by insert same flow label value into packets originated form different hosts which are controlled by the attacker, just like some guys have pointed out. THanks, washam From w@1wt.eu Fri Mar 2 06:20:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A0121F8555 for ; Fri, 2 Mar 2012 06:20:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.03 X-Spam-Level: X-Spam-Status: No, score=-5.03 tagged_above=-999 required=5 tests=[AWL=-3.587, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, J_CHICKENPOX_45=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 q7TzH1dEESuw for ; Fri, 2 Mar 2012 06:20:44 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id AAF2821F854A for ; Fri, 2 Mar 2012 06:20:43 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q22EKcGD017915; Fri, 2 Mar 2012 15:20:38 +0100 Date: Fri, 2 Mar 2012 15:20:38 +0100 From: Willy Tarreau To: Washam Fan Message-ID: <20120302142038.GE16141@1wt.eu> References: <4F4EE80D.6000106@gmail.com> <4F4F3511.8010307@bogus.com> <4F4FD5A2.5080602@gmail.com> <20120302070551.GB13959@1wt.eu> <20120302112130.GB16141@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 14:20:44 -0000 On Fri, Mar 02, 2012 at 08:59:53PM +0800, Washam Fan wrote: > >> If the srcIP changes, flow label alone can not be used to identify any > >> session. I suggest to remove the scenario in section 3 where flow > >> label is used across different srcIPs. > > > > On the opposite, flow label here makes it possible to perform load balancing > > across multiple srcIP which precisely is what saves the load balancer from > > having to perform L7 DPI. Otherwise the srcIP alone would be enough. > > flow label should always be used with other fields like srcIP, destIP > to identify a session, per RFC6437. {srcIP, flow label} saves the load > balancer from having to perform L7 DPI on subsequent packets belonging > to the same session while load balancer has to perform L7 DPI anyway > on the first packet on the session. As I explained, it does not save it from anything because if the LB sticks to the flow+srcIP, once the IP changes, there will be nothing at L7 it could use to match the session against the previous one. Either we can use the flow label as a stable user-level *session* identifier, or it cannot be used at all as it won't offer anything above srcIP alone. > If flow label alone can identify a session without srcIP, let's say. > an attacker can easily launch the attach by insert same flow label > value into packets originated form different hosts which are > controlled by the attacker, just like some guys have pointed out. Yes and this is already the case everywhere. Connect to a server, get a stickiness cookie, share it with 1000 buddies and you'll get the same result. Nothing new here, the whole web infrastructure lives very well with this right now. Regards, Willy From fgont@si6networks.com Fri Mar 2 06:52:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7A721F84F5 for ; Fri, 2 Mar 2012 06:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, 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 fvRYEGUNP15C for ; Fri, 2 Mar 2012 06:52:28 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 937F321F84F8 for ; Fri, 2 Mar 2012 06:52:27 -0800 (PST) Received: from [2001:5c0:1000:a::33] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1S3TqF-0007nX-7n; Fri, 02 Mar 2012 15:52:20 +0100 Message-ID: <4F50A26C.5070108@si6networks.com> Date: Fri, 02 Mar 2012 07:35:24 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Ray Hunter References: <201202141455.q1EEt1C04893@ftpeng-update.cisco.com> <4F4286A0.6040203@globis.net> <4F4712D2.4050202@si6networks.com> <4F47C6E6.9040609@globis.net> <4F48390F.10900@si6networks.com> <4F48A332.7040204@globis.net> <4F490D68.4030107@si6networks.com> <4F4A0E0A.6000806@globis.net> In-Reply-To: <4F4A0E0A.6000806@globis.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-v6ops-ra-guard-implementation@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-ietf-v6ops-ra-guard-implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 14:52:30 -0000 Hi, Ray, Thanks so much for your comments! -- Please find my responses inline... On 02/26/2012 07:48 AM, Ray Hunter wrote: > Humbly suggest making the text a bit more neutral, and leaving the > debate about oversized headers for another day. Also the reason that a > packet cannot be positively identified as RA or not might be the > presence of headers split over fragments, but it could also be something > else (that we haven't thought of yet). Well, either you have the entire header chain, or you don't... not sure what could be the "third" option... > Suggested text: > > In order to protect current end-node IPv6 implementations, Rule 3 has > been defined as a default rule to drop packets that cannot be positively > identified as RA packets or not (perhaps due to the fact that it > contains fragments that do not contain the entire IPv6 I've included the above text verbatim. Regardng the text below, I've worthsmithed it a bit (see below): > header chain). This introduces a chance that RA-Guard filtering could > result in false-positive blocking of some legitimate non-RA packets that > could not be positively identified as being non-RA. In order to reduce > the likelihood of false positives, Rule 3 also requires that an RA-Guard > implementation check before dropping an unidentifiable packet that it > has an IPv6 Source Address that is a link-local address or the > unspecified address (::), and the Hop Limit is 255 i.e. it is a packet > that should not be forwarded by a router. How about rewriting this as: "This means that, at least in theory, RA-Guard could result in false-positive blocking of some legitimate non-RA packets that could not be positively identified as being non-RA. In order to reduce the likelihood of false positives, Rule #3 also requires that an RA-Guard implementation check, before dropping an unidentifiable packet, that it has an IPv6 Source Address that is a link-local address or the unspecified address (::), and that the Hop Limit is 255. > In any case, as noted in [draft-gont-6man-oversized-header-chain], > fragmented packets with oversized headers are anyway unlikely to survive > in real networks. Whilst currently legitimate from a specifications > standpoint, they are virtually impossible to police with state-less > filters and firewalls, and are hence likely to be blocked by such > filters and firewalls. I've re-written this as: In any case, as noted in [draft-gont-6man-oversized-header-chain], IPv6 packets that fail to include the entire IPv6 header chain are anyway unlikely to survive in real networks. Whilst currently legitimate from a specifications standpoint, they are virtually impossible to police with state-less filters and firewalls, and are hence likely to be blocked by such filters and firewalls. Please do let me know if all the paragraphs above are look okay.... > Also two dumb questions as checks: > > What about packets including encryption? > > RFC4861 Section 3.3 and 11.2 still specifies that IPSec may be used to > protect ND (and thus RA) > Presume encrypted traffic offers no threat as there's protection at a > higher layer via the security association. > But is there any clarification text required in your draft to explicitly > cover this? > i.e. all encrypted traffic should be passed by RA-Guard, even though it > cannot be positively identified as RA or not? If anything, I'd not write that requirement in terms of "encrypted traffic", but rather in terms of e.g. packets employing the ESP header. My take would be that, from the point of view of RA-Guard, ESP is considered "the last header in the chain", and hence this would mean that ESP packets are not filtered. In any case, I'll create a separate thread to discuss this issue, such that it is easier for others to weigh in. > Is there any need to further clarify how RA-Guard interacts with SeND? > I don't think so, but thought I'd ask. There are no special rules required to interact with SeND, since SeND traffic is not encrypted. Please let me know if you think that a comment about this is warranted. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From washam.fan@gmail.com Fri Mar 2 06:57:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2302321F8609 for ; Fri, 2 Mar 2012 06:57:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, 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 NOZCzLAG71Xd for ; Fri, 2 Mar 2012 06:57:57 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 052B421F85A0 for ; Fri, 2 Mar 2012 06:57:56 -0800 (PST) Received: by wicr5 with SMTP id r5so174808wic.31 for ; Fri, 02 Mar 2012 06:57:56 -0800 (PST) Received-SPF: pass (google.com: domain of washam.fan@gmail.com designates 10.180.95.34 as permitted sender) client-ip=10.180.95.34; Authentication-Results: mr.google.com; spf=pass (google.com: domain of washam.fan@gmail.com designates 10.180.95.34 as permitted sender) smtp.mail=washam.fan@gmail.com; dkim=pass header.i=washam.fan@gmail.com Received: from mr.google.com ([10.180.95.34]) by 10.180.95.34 with SMTP id dh2mr6131553wib.15.1330700276284 (num_hops = 1); Fri, 02 Mar 2012 06:57:56 -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=4ZH/Sdp3pTSi6DcNGo65JgC3LvwSyMoPLhr3BAh3Vi0=; b=UvdhXV1OK7KeEK/Myv3eaQxPphqSaHpJDKV/4R8BB3rvmzkPTICKRT0yMy33M/ag2T CqSWQyVBps2r1JdYlPvMHKRa1jqNCF4WZF46D9R/kV1qJbObpXvfwQGR9fE2hMiDVypc YV88Tib7fYkenpfkdvKSvU27L7QbBV3oh5NebfecIs8M3R3liB53YHCBV9sGzLgyNDmn PDpq6Td0/liUlbLhP2rHJqM6N+T37SYT22s7+P+y5ukBNUqhoaSXQ/xmIzbwKMzW+fLt CsjIalyLSfZg++e+OfAY0kPPzYBmHqRr0Lfa5657xeeK2wnFWFkVfP2yHhAg9Tfc4HxZ mk6Q== MIME-Version: 1.0 Received: by 10.180.95.34 with SMTP id dh2mr4905078wib.15.1330700276201; Fri, 02 Mar 2012 06:57:56 -0800 (PST) Received: by 10.216.205.169 with HTTP; Fri, 2 Mar 2012 06:57:55 -0800 (PST) In-Reply-To: <20120302142038.GE16141@1wt.eu> References: <4F4EE80D.6000106@gmail.com> <4F4F3511.8010307@bogus.com> <4F4FD5A2.5080602@gmail.com> <20120302070551.GB13959@1wt.eu> <20120302112130.GB16141@1wt.eu> <20120302142038.GE16141@1wt.eu> Date: Fri, 2 Mar 2012 22:57:55 +0800 Message-ID: From: Washam Fan To: Willy Tarreau Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 14:57:58 -0000 Hi Willy, >> flow label should always be used with other fields like srcIP, destIP >> to identify a session, per RFC6437. {srcIP, flow label} saves the load >> balancer from having to perform L7 DPI on subsequent packets belonging >> to the same session while load balancer has to perform L7 DPI anyway >> on the first packet on the session. > > As I explained, it does not save it from anything because if the LB sticks > to the flow+srcIP, once the IP changes, there will be nothing at L7 it > could use to match the session against the previous one. I agree once the IP changes, LB would do L7 DPI on the first packet using new srcIP. As far as the IP keeps as it is, LB would not do L7 DPI on packets belonging to the same session identified by flow+srcIP except the first packet. When IP doesn't change, it does save LB from L7 DPI on packets to identify a session. > Either we can > use the flow label as a stable user-level *session* identifier, or it > cannot be used at all as it won't offer anything above srcIP alone. LB can benefit when srcIP doesn't change. Please see above. >> If flow label alone can identify a session without srcIP, let's say. >> an attacker can easily launch the attach by insert same flow label >> value into packets originated form different hosts which are >> controlled by the attacker, just like some guys have pointed out. > > Yes and this is already the case everywhere. Connect to a server, > get a stickiness cookie, share it with 1000 buddies and you'll get > the same result. Nothing new here, the whole web infrastructure lives > very well with this right now. OK then. I'd like other people to chime in to share their opinions on this. Thanks, washam From w@1wt.eu Fri Mar 2 07:05:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 564B621F8622 for ; Fri, 2 Mar 2012 07:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.998 X-Spam-Level: X-Spam-Status: No, score=-4.998 tagged_above=-999 required=5 tests=[AWL=-3.555, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, J_CHICKENPOX_45=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 vxDIkbqURvS3 for ; Fri, 2 Mar 2012 07:05:47 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 856DB21F8643 for ; Fri, 2 Mar 2012 07:05:46 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q22F5cur018236; Fri, 2 Mar 2012 16:05:38 +0100 Date: Fri, 2 Mar 2012 16:05:37 +0100 From: Willy Tarreau To: Washam Fan Message-ID: <20120302150537.GF16141@1wt.eu> References: <4F4EE80D.6000106@gmail.com> <4F4F3511.8010307@bogus.com> <4F4FD5A2.5080602@gmail.com> <20120302070551.GB13959@1wt.eu> <20120302112130.GB16141@1wt.eu> <20120302142038.GE16141@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 15:05:47 -0000 On Fri, Mar 02, 2012 at 10:57:55PM +0800, Washam Fan wrote: > > As I explained, it does not save it from anything because if the LB sticks > > to the flow+srcIP, once the IP changes, there will be nothing at L7 it > > could use to match the session against the previous one. > > I agree once the IP changes, LB would do L7 DPI on the first packet > using new srcIP. As far as the IP keeps as it is, LB would not do L7 > DPI on packets belonging to the same session identified by flow+srcIP > except the first packet. I think we don't understand each other well, I'm sorry. What I mean is that if the load balancer has to rely on L7 in the middle of a session, it will not know what to look for there. From the beginning of the session, it only relied on the flow label. Suddenly the srcIP changes and the label is unknown. Let's consider it has to L7 DPI. What will it look for there ? Until then it has not had to open the L7 stream so it doesn't know what it contains nor what to look for there. And this is even worse when one wants to match HTTPS against HTTP and vice-versa. Regards, Willy From v6ops@globis.net Fri Mar 2 07:55:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 945FB21F8649 for ; Fri, 2 Mar 2012 07:55:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.046, 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 8ecsXALoA7Ie for ; Fri, 2 Mar 2012 07:55:33 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 07F2E21F8493 for ; Fri, 2 Mar 2012 07:55:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 032518700F5; Fri, 2 Mar 2012 16:55:32 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOFDoRlNWbhL; Fri, 2 Mar 2012 16:55:15 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 6DA678700F3; Fri, 2 Mar 2012 16:55:15 +0100 (CET) Message-ID: <4F50ED63.1070101@globis.net> Date: Fri, 02 Mar 2012 16:55:15 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Fernando Gont References: <201202141455.q1EEt1C04893@ftpeng-update.cisco.com> <4F4286A0.6040203@globis.net> <4F4712D2.4050202@si6networks.com> <4F47C6E6.9040609@globis.net> <4F48390F.10900@si6networks.com> <4F48A332.7040204@globis.net> <4F490D68.4030107@si6networks.com> <4F4A0E0A.6000806@globis.net> <4F50A26C.5070108@si6networks.com> In-Reply-To: <4F50A26C.5070108@si6networks.com> Content-Type: multipart/alternative; boundary="------------000906050800060700070008" Cc: draft-ietf-v6ops-ra-guard-implementation@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-ietf-v6ops-ra-guard-implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 15:55:34 -0000 This is a multi-part message in MIME format. --------------000906050800060700070008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Proposed text looks fine. > Well, either you have the entire header chain, or you don't... not sure > what could be the "third" option... Just trying to avoid making any unnecessary assumptions. For example, what about a (new) extension header for which the RA-Guard parser doesn't have an explicit decoder, but the end nodes do, and the header does not comply with http://tools.ietf.org/html/draft-ietf-6man-exthdr-06 ? You may be able to see all the headers in the packet, but that isn't necessarily a sufficient precondition to guarantee that all RA-Guard implementations can parse deep enough into the packet to determine that the packet is definitely not an RA message. An unlikely scenario I know, but the default drop un-parseable packets rule also protects this corner case. regards RayH Fernando Gont wrote: > Hi, Ray, > > Thanks so much for your comments! -- Please find my responses inline... > > On 02/26/2012 07:48 AM, Ray Hunter wrote: > >> Humbly suggest making the text a bit more neutral, and leaving the >> debate about oversized headers for another day. Also the reason that a >> packet cannot be positively identified as RA or not might be the >> presence of headers split over fragments, but it could also be something >> else (that we haven't thought of yet). >> > > Well, either you have the entire header chain, or you don't... not sure > what could be the "third" option... > > > > >> Suggested text: >> >> In order to protect current end-node IPv6 implementations, Rule 3 has >> been defined as a default rule to drop packets that cannot be positively >> identified as RA packets or not (perhaps due to the fact that it >> contains fragments that do not contain the entire IPv6 >> > > I've included the above text verbatim. Regardng the text below, I've > worthsmithed it a bit (see below): > > > >> header chain). This introduces a chance that RA-Guard filtering could >> result in false-positive blocking of some legitimate non-RA packets that >> could not be positively identified as being non-RA. In order to reduce >> the likelihood of false positives, Rule 3 also requires that an RA-Guard >> implementation check before dropping an unidentifiable packet that it >> has an IPv6 Source Address that is a link-local address or the >> unspecified address (::), and the Hop Limit is 255 i.e. it is a packet >> that should not be forwarded by a router. >> > > How about rewriting this as: > > "This means that, at least in theory, RA-Guard could result in > false-positive blocking of some legitimate non-RA packets that could not > be positively identified as being non-RA. In order to reduce the > likelihood of false positives, Rule #3 also requires that an RA-Guard > implementation check, before dropping an unidentifiable packet, that it > has an IPv6 Source Address that is a link-local address or the > unspecified address (::), and that the Hop Limit is 255. > > > > >> In any case, as noted in [draft-gont-6man-oversized-header-chain], >> fragmented packets with oversized headers are anyway unlikely to survive >> in real networks. Whilst currently legitimate from a specifications >> standpoint, they are virtually impossible to police with state-less >> filters and firewalls, and are hence likely to be blocked by such >> filters and firewalls. >> > > I've re-written this as: > > In any case, as noted in [draft-gont-6man-oversized-header-chain], > IPv6 packets that fail to include the entire IPv6 header chain are > anyway unlikely to survive in real networks. Whilst currently > legitimate from a specifications standpoint, they are virtually > impossible to police with state-less filters and firewalls, and are > hence likely to be blocked by such > filters and firewalls. > > > Please do let me know if all the paragraphs above are look okay.... > > > > >> Also two dumb questions as checks: >> >> What about packets including encryption? >> >> RFC4861 Section 3.3 and 11.2 still specifies that IPSec may be used to >> protect ND (and thus RA) >> Presume encrypted traffic offers no threat as there's protection at a >> higher layer via the security association. >> But is there any clarification text required in your draft to explicitly >> cover this? >> i.e. all encrypted traffic should be passed by RA-Guard, even though it >> cannot be positively identified as RA or not? >> > > If anything, I'd not write that requirement in terms of "encrypted > traffic", but rather in terms of e.g. packets employing the ESP header. > My take would be that, from the point of view of RA-Guard, ESP is > considered "the last header in the chain", and hence this would mean > that ESP packets are not filtered. > > In any case, I'll create a separate thread to discuss this issue, such > that it is easier for others to weigh in. > > > >> Is there any need to further clarify how RA-Guard interacts with SeND? >> I don't think so, but thought I'd ask. >> > > There are no special rules required to interact with SeND, since SeND > traffic is not encrypted. Please let me know if you think that a comment > about this is warranted. > > Thanks! > > Best regards, > --------------000906050800060700070008 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Proposed text looks fine.

Well, either you have the entire header chain, or you don't... not sure
what could be the "third" option...
Just trying to avoid making any unnecessary assumptions.

For example, what about a (new) extension header for which the RA-Guard parser doesn't have an explicit decoder, but the end nodes do, and the header does not comply with http://tools.ietf.org/html/draft-ietf-6man-exthdr-06 ?

You may be able to see all the headers in the packet, but that isn't necessarily a sufficient precondition to guarantee that all RA-Guard implementations can parse deep enough into the packet to determine that the packet is definitely not an RA message.

An unlikely scenario I know, but the default drop un-parseable packets rule also protects this corner case.

regards
RayH
 
Fernando Gont wrote: 
Hi, Ray,

Thanks so much for your comments! -- Please find my responses inline...

On 02/26/2012 07:48 AM, Ray Hunter wrote:
  
Humbly suggest making the text a bit more neutral, and leaving the
debate about oversized headers for another day. Also the reason that a
packet cannot be positively identified as RA or not might be the
presence of headers split over fragments, but it could also be something
else (that we haven't thought of yet).
    

Well, either you have the entire header chain, or you don't... not sure
what could be the "third" option...



  
Suggested text:

In order to protect current end-node IPv6 implementations, Rule 3 has
been defined as a default rule to drop packets that cannot be positively
identified as RA packets or not (perhaps due to the fact that it
contains fragments that do not contain the entire IPv6
    

I've included the above text verbatim. Regardng the text below, I've
worthsmithed it a bit (see below):


  
header chain). This introduces a chance that RA-Guard filtering could
result in false-positive blocking of some legitimate non-RA packets that
could not be positively identified as being non-RA. In order to reduce
the likelihood of false positives, Rule 3 also requires that an RA-Guard
implementation check before dropping an unidentifiable packet that it
has an IPv6 Source Address that is a link-local address or the
unspecified address (::), and the Hop Limit is 255 i.e. it is a packet
that should not be forwarded by a router.
    

How about rewriting this as:

"This means that, at least in theory, RA-Guard could result in
false-positive blocking of some legitimate non-RA packets that could not
be positively identified as being non-RA. In order to reduce the
likelihood of false positives, Rule #3 also requires that an RA-Guard
implementation check, before dropping an unidentifiable packet, that it
has an IPv6 Source Address that is a link-local address or the
unspecified address (::), and that the Hop Limit is 255.



  
In any case, as noted in [draft-gont-6man-oversized-header-chain],
fragmented packets with oversized headers are anyway unlikely to survive
in real networks. Whilst currently legitimate from a specifications
standpoint, they are virtually impossible to police with state-less
filters and firewalls, and are hence likely to be blocked by such
filters and firewalls.
    

I've re-written this as:

  In any case, as noted in [draft-gont-6man-oversized-header-chain],
  IPv6 packets that fail to include the entire IPv6 header chain are
  anyway unlikely to survive in real networks. Whilst currently
  legitimate from a specifications standpoint, they are virtually
  impossible to police with state-less filters and firewalls, and are
  hence likely to be blocked by such
  filters and firewalls.


Please do let me know if all the paragraphs above are look okay....



  
Also two dumb questions as checks:

What about packets including encryption?

RFC4861 Section 3.3 and 11.2 still specifies that IPSec may be used to
protect ND (and thus RA)
Presume encrypted traffic offers no threat as there's protection at a
higher layer via the security association.
But is there any clarification text required in your draft to explicitly
cover this?
i.e. all encrypted traffic should be passed by RA-Guard, even though it
cannot be positively identified as RA or not?
    

If anything, I'd not write that requirement in terms of "encrypted
traffic", but rather in terms of e.g. packets employing the ESP header.
My take would be that, from the point of view of RA-Guard, ESP is
considered "the last header in the chain", and hence this would mean
that ESP packets are not filtered.

In any case, I'll create a separate thread to discuss this issue, such
that it is easier for others to weigh in.


  
Is there any need to further clarify how RA-Guard interacts with SeND?
I don't think so, but thought I'd ask.
    

There are no special rules required to interact with SeND, since SeND
traffic is not encrypted. Please let me know if you think that a comment
about this is warranted.

Thanks!

Best regards,

--------------000906050800060700070008-- From joelja@bogus.com Fri Mar 2 08:34:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F9421F8715 for ; Fri, 2 Mar 2012 08:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 tyzvNY9aVXfU for ; Fri, 2 Mar 2012 08:34:08 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id CAC6B21F8714 for ; Fri, 2 Mar 2012 08:34:08 -0800 (PST) Received: from Joels-MacBook-Pro.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q22GXedl078582 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Fri, 2 Mar 2012 16:33:41 GMT (envelope-from joelja@bogus.com) Message-ID: <4F50F664.8020206@bogus.com> Date: Fri, 02 Mar 2012 08:33:40 -0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Brian E Carpenter References: <4F4EE80D.6000106@gmail.com> <4F4F3511.8010307@bogus.com> <4F4FD5A2.5080602@gmail.com> In-Reply-To: <4F4FD5A2.5080602@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Fri, 02 Mar 2012 16:33:42 +0000 (UTC) Cc: IPv6 Operations , Willy Tarreau Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 16:34:09 -0000 On 3/1/12 12:01 , Brian E Carpenter wrote: > On 2012-03-01 21:36, Joel jaeggli wrote: >> On 2/29/12 19:07 , Brian E Carpenter wrote: >> >>>> => Yes but they don't use flow labels for that. They use a unique >>>> application-specific identifier. >>>> flow label != cookie. The cookie is not created by the client. >>> Correct, and it's a fairly horrible solution, isn't it? It forces >>> you into DPI for every packet in order to recognise the session. >>> That's *exactly* what needs to change. >> >> This is a fundamental misrepresentation of how load balancers work... >> >> If you're doing l3+l4 there's nothing to "DPI" because you have to >> dispatch a new TCP connection request on the basis of a SYN only, >> there's literally nothing to inspect. If you are doing L7 termination, >> for example with http(s), imap or even sip there's no packet inspection >> involved in plucking out a cookie, or login credentials or the like. > > If you are mixing the two approaches, I'm not... I'm distinguishing between two approaches neither of which involve deep packet inspection. > which I understand is common, > it isn't that simple. When you see a new L4 flow starting, you have to > check whether it is in fact part of an existing L7 flow but using > a different address/port. Or, I don't. Common web application tiers based on rest api are stateless beyond a single session. so an application implemented in that fashion has no l7 sticky implications beyond the open tcp connection. For applications that do require adhesion today, for example realtime game servers, if you want to load balance them, how do you do that)? you: use an upper-layer identifier of some variety (Which involves becoming an ALG) use ip persistence and recognize that devices that change IP will be disrupted in some fashion. does a unique flow label per host enhance the ability to do that? maybe. if you can get clients to actually behave in the fashion you describe, if you're marking the flow label yourself you don't have a prayer of having it be useful for this. > I guess you are correct that once you have done this for the first full > L7 packet (not the SYN packet), you can revert to only looking at the > L3/L4 bits. An application layer load balancer is terminating the incoming connection, it's not doing l3/l4 forwarding. If you're snarfing cookies, doing http-proxy or https/tls termination that's what you're doing. No DPI is involved. > But with IPv6 extension headers present, looking for L4 > is extra work; the flow label is in a fixed place in the L3 header. If you're terminating the connection on the load balancer as for example ha-proxy does when operating as an http-proxy you've got to find the l4 header anyway. > Brian > From w@1wt.eu Fri Mar 2 08:47:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2201C21F86BD for ; Fri, 2 Mar 2012 08:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.266 X-Spam-Level: X-Spam-Status: No, score=-5.266 tagged_above=-999 required=5 tests=[AWL=-3.223, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] 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 5CUVUMbf8pKe for ; Fri, 2 Mar 2012 08:47:58 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAC721F86BB for ; Fri, 2 Mar 2012 08:47:58 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q22Glh6f019477; Fri, 2 Mar 2012 17:47:43 +0100 Date: Fri, 2 Mar 2012 17:47:43 +0100 From: Willy Tarreau To: Joel jaeggli Message-ID: <20120302164743.GH16141@1wt.eu> References: <4F4EE80D.6000106@gmail.com> <4F4F3511.8010307@bogus.com> <4F4FD5A2.5080602@gmail.com> <4F50F664.8020206@bogus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F50F664.8020206@bogus.com> User-Agent: Mutt/1.4.2.3i Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 16:47:59 -0000 Hi Joel, On Fri, Mar 02, 2012 at 08:33:40AM -0800, Joel jaeggli wrote: > > I guess you are correct that once you have done this for the first full > > L7 packet (not the SYN packet), you can revert to only looking at the > > L3/L4 bits. > > An application layer load balancer is terminating the incoming > connection, it's not doing l3/l4 forwarding. If you're snarfing cookies, > doing http-proxy or https/tls termination that's what you're doing. No > DPI is involved. DPI was used in this thread to distinguish the need to analyze up to layer 7 vs the need to analyze up to L3. I totally agree with you that L7 load balancers are proxy nowadays (I'm not counting the few old Alteon and KTCPVS which used to process L7 on a per-packet basis). > > But with IPv6 extension headers present, looking for L4 > > is extra work; the flow label is in a fixed place in the L3 header. > > If you're terminating the connection on the load balancer as for example > ha-proxy does when operating as an http-proxy you've got to find the l4 > header anyway. The difference is that you can have your L4 LB totally bypass the L7 LB when the flow label is correctly set. This is a huge gain, especially when it comes to https where the LB does not have to decipher anymore. Regards, Willy From brian.e.carpenter@gmail.com Fri Mar 2 11:20:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2AFC21F85CC for ; Fri, 2 Mar 2012 11:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.49 X-Spam-Level: X-Spam-Status: No, score=-103.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 l6oR0II9K20f for ; Fri, 2 Mar 2012 11:20:03 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1B42421F85C3 for ; Fri, 2 Mar 2012 11:20:02 -0800 (PST) Received: by eeke51 with SMTP id e51so722275eek.31 for ; Fri, 02 Mar 2012 11:20:02 -0800 (PST) Received-SPF: pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.14.27.142 as permitted sender) client-ip=10.14.27.142; Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.14.27.142 as permitted sender) smtp.mail=brian.e.carpenter@gmail.com; dkim=pass header.i=brian.e.carpenter@gmail.com Received: from mr.google.com ([10.14.27.142]) by 10.14.27.142 with SMTP id e14mr6741523eea.70.1330716002370 (num_hops = 1); Fri, 02 Mar 2012 11:20:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gEUHSwlLCB+cYfQAjbZsPe2mNdK7QbMDCX2+W/DfZyc=; b=czmn/OTwsW/3/vu/RLdrQxlRCbYYhaDjZyG+aWHt6FG3/9Q/3VVmRDtznXb+BL9wtS nqF59/uzzYom8yzbIhZq74Dwba+0eTXrGfRW4k2FUF/xAKCt50o+9Towz2VyRhTTmI+d gMr85SW35RCFHFL42cYKaTBc+GsgOxqpmSlPtslyOVijma4MUI77yiz6NPt2wd/4/GWL 1/a5s+aCxYxlHUB9F93cUAye3Pv94eTSLgEhvNHnMA3bBwhFMhY3MEmqwzjiRtqH2Br8 2n8OleAygoUtdYPlC6zyIvrMXeb6wTbjBa2sb3X2HXigapSmro8Jv9IGQJxYFVfzqlpT +LKA== Received: by 10.14.27.142 with SMTP id e14mr5175827eea.70.1330716002196; Fri, 02 Mar 2012 11:20:02 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id n52sm23662531eea.5.2012.03.02.11.19.58 (version=SSLv3 cipher=OTHER); Fri, 02 Mar 2012 11:20:01 -0800 (PST) Message-ID: <4F511D57.5020606@gmail.com> Date: Sat, 03 Mar 2012 08:19:51 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Washam Fan References: <4F4EE80D.6000106@gmail.com> <4F4F3511.8010307@bogus.com> <4F4FD5A2.5080602@gmail.com> <20120302070551.GB13959@1wt.eu> <20120302112130.GB16141@1wt.eu> <20120302142038.GE16141@1wt.eu> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations , Willy Tarreau Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 19:20:04 -0000 On 2012-03-03 03:57, Washam Fan wrote: >>> If flow label alone can identify a session without srcIP, let's say. >>> an attacker can easily launch the attach by insert same flow label >>> value into packets originated form different hosts which are >>> controlled by the attacker, just like some guys have pointed out. >> Yes and this is already the case everywhere. Connect to a server, >> get a stickiness cookie, share it with 1000 buddies and you'll get >> the same result. Nothing new here, the whole web infrastructure lives >> very well with this right now. > > OK then. I'd like other people to chime in to share their opinions on this. As far as I can see, you could check the L7 information on the *first* packet with a known flow label and a different srcIP, to see if it's the same session. That way, the attacker would have to fake the whole packet and not just the flow label - which is exactly what they have to do today, as Willy says. DDOS is certainly hard to defeat, but I don't think there is really a new attack vector here. Brian From fgont@si6networks.com Fri Mar 2 11:46:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A65D21E8048 for ; Fri, 2 Mar 2012 11:46:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 8ByNAJB8jUP3 for ; Fri, 2 Mar 2012 11:46:14 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id C1BF921E803D for ; Fri, 2 Mar 2012 11:46:14 -0800 (PST) Received: from [186.134.11.43] (helo=[192.168.123.102]) by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1S3YQd-00025N-DB; Fri, 02 Mar 2012 20:46:11 +0100 Message-ID: <4F512365.3020803@si6networks.com> Date: Fri, 02 Mar 2012 16:45:41 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Ray Hunter References: <201202141455.q1EEt1C04893@ftpeng-update.cisco.com> <4F4286A0.6040203@globis.net> <4F4712D2.4050202@si6networks.com> <4F47C6E6.9040609@globis.net> <4F48390F.10900@si6networks.com> <4F48A332.7040204@globis.net> <4F490D68.4030107@si6networks.com> <4F4A0E0A.6000806@globis.net> <4F50A26C.5070108@si6networks.com> <4F50ED63.1070101@globis.net> In-Reply-To: <4F50ED63.1070101@globis.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-v6ops-ra-guard-implementation@tools.ietf.org, v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-ietf-v6ops-ra-guard-implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 19:46:59 -0000 Hi, Ray, On 03/02/2012 12:55 PM, Ray Hunter wrote: > Proposed text looks fine. > >> Well, either you have the entire header chain, or you don't... not sure >> what could be the "third" option... > Just trying to avoid making any unnecessary assumptions. > > For example, what about a (new) extension header for which the RA-Guard > parser doesn't have an explicit decoder, but the end nodes do, and the > header does not comply with > http://tools.ietf.org/html/draft-ietf-6man-exthdr-06 ? 6man has been very clear that there have to be very good reasons for introducing a new ext header, and in the event that happens, they new ext header will have the TLV format specified in draft-ietf-6man-exthdr (it's a "MUST"). So, the scenario you mention won't happen. > You may be able to see all the headers in the packet, but that isn't > necessarily a sufficient precondition to guarantee that all RA-Guard > implementations can parse deep enough into the packet to determine that > the packet is definitely not an RA message. > > An unlikely scenario I know, but the default drop un-parseable packets > rule also protects this corner case. Exactly. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From ietf-ipr@ietf.org Fri Mar 2 14:30:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB7521E806A; Fri, 2 Mar 2012 14:30:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.431 X-Spam-Level: X-Spam-Status: No, score=-102.431 tagged_above=-999 required=5 tests=[AWL=0.168, 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 BWpUwqUved5W; Fri, 2 Mar 2012 14:30:52 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E38BE21F849A; Fri, 2 Mar 2012 14:30:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: shengjiang@huawei.com, brian.e.carpenter@gmail.com, guoseu@huawei.com X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120302223052.4594.47579.idtracker@ietfa.amsl.com> Date: Fri, 02 Mar 2012 14:30:52 -0800 Cc: v6ops@ietf.org, fred.baker@cisco.com, dromasca@avaya.com, ipr-announce@ietf.org Subject: [v6ops] IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to RFC 6264 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Mar 2012 22:30:53 -0000 Dear Sheng Jiang, Brian Carpenter, Dayong Guo: An IPR disclosure that pertains to your RFC entitled "An Incremental Carri= er- Grade NAT (CGN) for IPv6 Transition" (RFC6264) was submitted to the IETF Secretariat on 2012-02-24 and has been posted on the "IETF Page of Intellec= tual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1687/). The = title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to RFC 6264.""); The IETF Secretariat From washam.fan@gmail.com Fri Mar 2 22:18:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50E1E21E8069 for ; Fri, 2 Mar 2012 22:18:31 -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 McrAbfavPI06 for ; Fri, 2 Mar 2012 22:18:30 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 31AB121E8061 for ; Fri, 2 Mar 2012 22:18:30 -0800 (PST) Received: by werb10 with SMTP id b10so1903254wer.31 for ; Fri, 02 Mar 2012 22:18: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=68ozb1GsQ/QUsjQcUPNsoUZgUaptNb5IIkpBSO4KYMw=; b=Mwero/Vh9pRyObC2l5P9grFvxDvu9Ys+CH2ma9LoqLXfNRZ7KwBmTHeEEppLZxTIiA QrTrbPlRmxXBebOfrfABzGPAx9K7rm/V1OpzE4kD16n7tEG7uVo0riOohYL+Nf5fd7ns ptMGbMBpGAWMkuitxJshgIpT5xq3Ef9YiUhqTiY2aUbqdfPWjjGeFHwdtdmjGa98nYDF UHWa9SHacJhA4Ee/6r+2MPSyYp0XHeNmqdqgkH+pXHiAqXuZ3+/7SHO8bHu9T33q5cVZ ZqG4Kap0kTnwb4XBX7k8uqTnZD/SRPy4eL2IZ+87RmTzmwTwO/eNN+TkS50oguPgHbQV V/AA== MIME-Version: 1.0 Received: by 10.180.82.132 with SMTP id i4mr1702475wiy.12.1330755509386; Fri, 02 Mar 2012 22:18:29 -0800 (PST) Received: by 10.216.205.169 with HTTP; Fri, 2 Mar 2012 22:18:29 -0800 (PST) In-Reply-To: <4F511D57.5020606@gmail.com> References: <4F4EE80D.6000106@gmail.com> <4F4F3511.8010307@bogus.com> <4F4FD5A2.5080602@gmail.com> <20120302070551.GB13959@1wt.eu> <20120302112130.GB16141@1wt.eu> <20120302142038.GE16141@1wt.eu> <4F511D57.5020606@gmail.com> Date: Sat, 3 Mar 2012 14:18:29 +0800 Message-ID: From: Washam Fan To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Operations , Willy Tarreau Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 06:18:31 -0000 Hi Brian, 2012/3/3 Brian E Carpenter : > On 2012-03-03 03:57, Washam Fan wrote: > > > >>>> If flow label alone can identify a session without srcIP, let's say. >>>> an attacker can easily launch the attach by insert same flow label >>>> value into packets originated form different hosts which are >>>> controlled by the attacker, just like some guys have pointed out. > >>> Yes and this is already the case everywhere. Connect to a server, >>> get a stickiness cookie, share it with 1000 buddies and you'll get >>> the same result. Nothing new here, the whole web infrastructure lives >>> very well with this right now. >> >> OK then. I'd like other people to chime in to share their opinions on this. > > As far as I can see, you could check the L7 information on the *first* > packet with a known flow label and a different srcIP, to see if it's > the same session. That way, the attacker would have to fake the whole > packet and not just the flow label - which is exactly what they have > to do today, as Willy says. That way, you don't need share the same flow label across different srcIPs, since the *first" packet would be L7 checked anyway. My take was, flow label can be shared between different srcPorts as far as the srcIP doesn't change. > DDOS is certainly hard to defeat, but I don't think there is really > a new attack vector here. Right. Thanks, washam From washam.fan@gmail.com Fri Mar 2 22:27:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60A4E21F8547 for ; Fri, 2 Mar 2012 22:27:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, 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 foOufVU5PeiU for ; Fri, 2 Mar 2012 22:27:16 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC2121F8542 for ; Fri, 2 Mar 2012 22:27:16 -0800 (PST) Received: by werb10 with SMTP id b10so1905797wer.31 for ; Fri, 02 Mar 2012 22:27:15 -0800 (PST) Received-SPF: pass (google.com: domain of washam.fan@gmail.com designates 10.216.138.7 as permitted sender) client-ip=10.216.138.7; Authentication-Results: mr.google.com; spf=pass (google.com: domain of washam.fan@gmail.com designates 10.216.138.7 as permitted sender) smtp.mail=washam.fan@gmail.com; dkim=pass header.i=washam.fan@gmail.com Received: from mr.google.com ([10.216.138.7]) by 10.216.138.7 with SMTP id z7mr2913438wei.16.1330756035917 (num_hops = 1); Fri, 02 Mar 2012 22:27:15 -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=D80MZ7Yf2vQIm5WAaP2DBSn83sYYhh+sicW71aaZHCg=; b=lZbS0BbsSMgiK/L6fqZpsQ5gu4aMOdQmBZ4q31giMngPNthfckbGwNok5rNma0IbRJ 7HCDZd2I+JwTrM/Mg5TKVlrVpc704gcXtygH9NwQV0EmQCP2kci6sD8n4hhMAtr1J0XH GdRj/nhtYlQNRBvNM1t129rwSzaOM8OTxSC0jxA3FR49Q/g8UDBN5yiLpVFZDsFbSAtM 7swsxZJNOfyXz9ge9APWu3WJ7VESK+zn0wi25suUCtyXTPIopCbUUEfqy9Ozi96Iukpz 2XEVF/UPHBdPX6BEispl3iIEZsC5m9T+Z0f3TPcgLqgDM1QQRmzJotit75PBfNzQI+mk vXrw== MIME-Version: 1.0 Received: by 10.216.138.7 with SMTP id z7mr2352882wei.16.1330756035801; Fri, 02 Mar 2012 22:27:15 -0800 (PST) Received: by 10.216.205.169 with HTTP; Fri, 2 Mar 2012 22:27:15 -0800 (PST) In-Reply-To: <20120302150537.GF16141@1wt.eu> References: <4F4EE80D.6000106@gmail.com> <4F4F3511.8010307@bogus.com> <4F4FD5A2.5080602@gmail.com> <20120302070551.GB13959@1wt.eu> <20120302112130.GB16141@1wt.eu> <20120302142038.GE16141@1wt.eu> <20120302150537.GF16141@1wt.eu> Date: Sat, 3 Mar 2012 14:27:15 +0800 Message-ID: From: Washam Fan To: Willy Tarreau Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 06:27:17 -0000 Hi Willy, 2012/3/2 Willy Tarreau : > On Fri, Mar 02, 2012 at 10:57:55PM +0800, Washam Fan wrote: >> > As I explained, it does not save it from anything because if the LB sticks >> > to the flow+srcIP, once the IP changes, there will be nothing at L7 it >> > could use to match the session against the previous one. >> >> I agree once the IP changes, LB would do L7 DPI on the first packet >> using new srcIP. As far as the IP keeps as it is, LB would not do L7 >> DPI on packets belonging to the same session identified by flow+srcIP >> except the first packet. > > I think we don't understand each other well, I'm sorry. What I mean is > that if the load balancer has to rely on L7 in the middle of a session, > it will not know what to look for there. From the beginning of the > session, it only relied on the flow label. Suddenly the srcIP changes > and the label is unknown. Let's consider it has to L7 DPI. What will > it look for there ? Until then it has not had to open the L7 stream so > it doesn't know what it contains nor what to look for there. And this > is even worse when one wants to match HTTPS against HTTP and vice-versa. > flow label only used to identify a session between a given srcIP and a given dstIP. If srcIP changes, it is beyond flow label's scope, and L7 DPI would be unavoidable. But L7 DPI only used on the *first* packet after srcIP changes. If srcIP changes frequently, i admit flow label can not benefit much in this case. Sorry if i have not made it clearer. Thanks, washam From w@1wt.eu Sat Mar 3 00:21:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A740321E8082 for ; Sat, 3 Mar 2012 00:21:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.944 X-Spam-Level: X-Spam-Status: No, score=-2.944 tagged_above=-999 required=5 tests=[AWL=-5.489, BAYES_00=-2.599, FRT_STOCK2=3.988, HELO_IS_SMALL6=0.556, J_CHICKENPOX_45=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 1Lm9pacso5V2 for ; Sat, 3 Mar 2012 00:21:56 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 90B8F21E8078 for ; Sat, 3 Mar 2012 00:21:54 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q238Llw5022575; Sat, 3 Mar 2012 09:21:47 +0100 Date: Sat, 3 Mar 2012 09:21:47 +0100 From: Willy Tarreau To: Washam Fan Message-ID: <20120303082147.GF20538@1wt.eu> References: <4F4FD5A2.5080602@gmail.com> <20120302070551.GB13959@1wt.eu> <20120302112130.GB16141@1wt.eu> <20120302142038.GE16141@1wt.eu> <20120302150537.GF16141@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 08:21:56 -0000 Hi Washam, On Sat, Mar 03, 2012 at 02:27:15PM +0800, Washam Fan wrote: > Hi Willy, > > 2012/3/2 Willy Tarreau : > > On Fri, Mar 02, 2012 at 10:57:55PM +0800, Washam Fan wrote: > >> > As I explained, it does not save it from anything because if the LB sticks > >> > to the flow+srcIP, once the IP changes, there will be nothing at L7 it > >> > could use to match the session against the previous one. > >> > >> I agree once the IP changes, LB would do L7 DPI on the first packet > >> using new srcIP. As far as the IP keeps as it is, LB would not do L7 > >> DPI on packets belonging to the same session identified by flow+srcIP > >> except the first packet. > > > > I think we don't understand each other well, I'm sorry. What I mean is > > that if the load balancer has to rely on L7 in the middle of a session, > > it will not know what to look for there. From the beginning of the > > session, it only relied on the flow label. Suddenly the srcIP changes > > and the label is unknown. Let's consider it has to L7 DPI. What will > > it look for there ? Until then it has not had to open the L7 stream so > > it doesn't know what it contains nor what to look for there. And this > > is even worse when one wants to match HTTPS against HTTP and vice-versa. > > > > flow label only used to identify a session between a given srcIP and a > given dstIP. If srcIP changes, it is beyond flow label's scope, and L7 > DPI would be unavoidable. But L7 DPI only used on the *first* packet > after srcIP changes. If srcIP changes frequently, i admit flow label > can not benefit much in this case. Sorry if i have not made it > clearer. No, L7 and flow label usage *cannot* be mixed that way. Either the LB relies on the L7 or it relies on the flow label. The reason is that for an LB to rely on L7, it must see *all* the L7 traffic of the session. Take this very common example : User foo uses his smartphone to check his bank account while he's been driven in a friend's car. 1) he has IP address 1.1.1.1 dynamically assigned by the nearest cell. 2) he opens the browser 3) he clicks on the bookmark 4) the browser picks a random flow label 0x12345 and connects to the bank doing a setsockopt() on all outgoing connections so that all packets have the proper flow label. 5) incoming connections pass through the L7 LB which only see the srcIP (1.1.1.1) and the flow label (0x12345). Connections are forwarded to the servers. 6) the home page is totally stateless, the server does not emit any cookie. 7) he logs in, so that's a new request. 8) LB knows the flow label (0x12345) and directs the stream to the same server. 9) bank servers emit a session cookie which can only be seen at L7 but nobody is looking. 10) the car enters a tunnel. Lack of connectivity. When leaving the tunnel, the phone finally recovers connectivity with a new 1.1.1.2 address. 11) foo clicks on an operation on the page. 12) the LB receives a request from IP 1.1.1.2 with the flow label 0x12345. If it considers the IP in association with the flow label, then it does not know this association. If it decides to decipher the stream and extract the cookie, it will see a cookie it does not know and will pick a new server. 13) the request goes to the wrong server, it doesn't have the user context and the poor guy has lost his session (and cannot even log it off). Now I know what you'll say, let's have the server emit the session ID upon first request to the home page (6). Eventhough it's in general not acceptable because it requires some deep application level changes, it only pushes the problem one step further, because once the session is renewed (eg: frequent sessions renewal due to the bank's security measures, or user foo being idle for too long talking to his friend), the LB doesn't catch the new cookie and will still have the issue at step 12. Another workaround would be to have the L7 LB insert the stickiness cookie itself at stem 6. That still doesn't survive a change of server which would leave the initial server's cookie in the request with a flow label associated to another server. Also there is an architectural issue in mixing the two methods the way you're suggesting it, it forces the flow label LB and the L7 LB to be the same, which doesn't scale at all. The goal of using the flow label was to be able to use distinct components so that the flow works like this : +-------+ | ASIC- | flow label present client packets ------->| based |------------------------> servers | L3/L4 | | LB | +-------+ | no flow label | +----------+ | | software | +------>| based L7 |---------> servers | LBs | +----------+ With this model, you can have 1 entry point which processes all flow label enabled sessions, and keep the good old L7 LB farm for SSL decipher/HTTP extraction/SSL cipher to go to the servers. It offers a smooth upgrade path for existing infrastructures, because if this mechanism is implemented in high grade switches, then the big investments on the LBs are maintained without any change to continue to handle all clients who do not emit flow labels. The L3/L4 LB implemented in the switch is just an L7 LB bypass. Regards, Willy From washam.fan@gmail.com Sat Mar 3 05:48:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A421E21F8739 for ; Sat, 3 Mar 2012 05:48:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.562 X-Spam-Level: X-Spam-Status: No, score=-1.562 tagged_above=-999 required=5 tests=[AWL=-1.951, BAYES_00=-2.599, FRT_STOCK2=3.988, 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 KAov1M5Rin1r for ; Sat, 3 Mar 2012 05:48:04 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9753721F865F for ; Sat, 3 Mar 2012 05:48:03 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so1616152wgb.13 for ; Sat, 03 Mar 2012 05:48:02 -0800 (PST) Received-SPF: pass (google.com: domain of washam.fan@gmail.com designates 10.180.88.199 as permitted sender) client-ip=10.180.88.199; Authentication-Results: mr.google.com; spf=pass (google.com: domain of washam.fan@gmail.com designates 10.180.88.199 as permitted sender) smtp.mail=washam.fan@gmail.com; dkim=pass header.i=washam.fan@gmail.com Received: from mr.google.com ([10.180.88.199]) by 10.180.88.199 with SMTP id bi7mr4058871wib.12.1330782482688 (num_hops = 1); Sat, 03 Mar 2012 05:48:02 -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:content-transfer-encoding; bh=3IqasFrWjAM7xrgGu3+ZVuyrmY80xxUnSZcv2z/rb4Q=; b=um8kZBuKWgBLK5rFXyI+Iy3/RXM107G/OzdpCblErK6oyuPzXZtNk+72vUZX6Cpszf dMBnzjQ7FjyR5FawMnQDETeUBen5rFdkkMzTteKszsniue8j088Rcno8DGEYXlN8276R /tsaLsBf65JdK31s3T7tnTmygpc+qvME60UOp/NXKfnRkeqBIquiyS/rDVg/Oqg90Ewn DbTylW3kURt9uTJCttp1lk+QEmb9SB9jjUNsvmI+KHGGClUCXOHml4mRuwPVoAEJMel3 Y4LYwC91yiLWlflicJ7svfa8ZmAneWORlwp4nhVChAMXKaYpCJYm20H/iscHg2Iaf0pD kiAA== MIME-Version: 1.0 Received: by 10.180.88.199 with SMTP id bi7mr3209733wib.12.1330782482570; Sat, 03 Mar 2012 05:48:02 -0800 (PST) Received: by 10.216.205.169 with HTTP; Sat, 3 Mar 2012 05:48:02 -0800 (PST) In-Reply-To: <20120303082147.GF20538@1wt.eu> References: <4F4FD5A2.5080602@gmail.com> <20120302070551.GB13959@1wt.eu> <20120302112130.GB16141@1wt.eu> <20120302142038.GE16141@1wt.eu> <20120302150537.GF16141@1wt.eu> <20120303082147.GF20538@1wt.eu> Date: Sat, 3 Mar 2012 21:48:02 +0800 Message-ID: From: Washam Fan To: Willy Tarreau Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 13:48:04 -0000 Hi Willy, >> flow label only used to identify a session between a given srcIP and a >> given dstIP. If srcIP changes, it is beyond flow label's scope, and L7 >> DPI would be unavoidable. But L7 DPI only used on the *first* packet >> after srcIP changes. If srcIP changes frequently, i admit flow label >> can not benefit much in this case. Sorry if i have not made it >> clearer. > > No, L7 and flow label usage *cannot* be mixed that way. I was not suggesting this. I was think that what the draft says. The authors might clarify that. > Either the LB > relies on the L7 or it relies on the flow label. I am not an expert on LB. LB could have relied on combination of L7 and flow label, per the draft. The author might clarify here, too. > The reason is that for > an LB to rely on L7, it must see *all* the L7 traffic of the session. that is why the draft suggests how flow label can be used to save LB from having to see *all* the L7 traffic of the session. LB has to only see the *first* packet fo the session, because flow label can be used to identify subsequent packets of the same session. If {srcIP, flow} is unknown, it is the *first* packet of a new session and L7 DPI should be taken on it. > Take this very common example : > > =A0 User foo uses his smartphone to check his bank account while he's > =A0 been driven in a friend's car. > > =A0 1) he has IP address 1.1.1.1 dynamically assigned by the nearest cell= . > =A0 2) he opens the browser > =A0 3) he clicks on the bookmark > =A0 4) the browser picks a random flow label 0x12345 and connects to the > =A0 =A0 =A0bank doing a setsockopt() on all outgoing connections so that = all > =A0 =A0 =A0packets have the proper flow label. > =A0 5) incoming connections pass through the L7 LB which only see > =A0 =A0 =A0the srcIP (1.1.1.1) and the flow label (0x12345). Connections > =A0 =A0 =A0are forwarded to the servers. > =A0 6) the home page is totally stateless, the server does not emit > =A0 =A0 =A0any cookie. > =A0 7) he logs in, so that's a new request. > =A0 8) LB knows the flow label (0x12345) and directs the stream to the > =A0 =A0 =A0same server. > =A0 9) bank servers emit a session cookie which can only be seen at > =A0 =A0 =A0L7 but nobody is looking. > =A010) the car enters a tunnel. Lack of connectivity. When leaving > =A0 =A0 =A0the tunnel, the phone finally recovers connectivity with a > =A0 =A0 =A0new 1.1.1.2 address. > =A011) foo clicks on an operation on the page. > =A012) the LB receives a request from IP 1.1.1.2 with the flow label > =A0 =A0 =A00x12345. If it considers the IP in association with the flow > =A0 =A0 =A0label, then it does not know this association. If it decides > =A0 =A0 =A0to decipher the stream and extract the cookie, it will see a > =A0 =A0 =A0cookie it does not know and will pick a new server. Why the cookie is unknown? cookies can be used across different 'transport layer' sessions. > =A013) the request goes to the wrong server, it doesn't have the user > =A0 =A0 =A0context and the poor guy has lost his session (and cannot even > =A0 =A0 =A0log it off). > > Now I know what you'll say, let's have the server emit the session > ID upon first request to the home page (6). Eventhough it's in general > not acceptable because it requires some deep application level changes, > it only pushes the problem one step further, because once the session > is renewed (eg: frequent sessions renewal due to the bank's security > measures, or user foo being idle for too long talking to his friend), > the LB doesn't catch the new cookie and will still have the issue at > step 12. > > Another workaround would be to have the L7 LB insert the stickiness > cookie itself at stem 6. That still doesn't survive a change of server > which would leave the initial server's cookie in the request with a > flow label associated to another server. it is cookie associated to a backend server, and different {srcIP, flow} pairs can be associated to the same cookie. > Also there is an architectural issue in mixing the two methods the > way you're suggesting it, it forces the flow label LB and the L7 LB > to be the same, which doesn't scale at all. The goal of using the > flow label was to be able to use distinct components so that the > flow works like this : > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +-------+ > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | ASIC- | =A0flow label p= resent > =A0client packets ------->| based |------------------------> servers > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | L3/L4 | > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 LB =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 | no flow label > =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 | s= oftware | > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 +------>| based L= 7 |---------> servers > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |= =A0 =A0LBs =A0 | > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 += ----------+ > > With this model, you can have 1 entry point which processes all > flow label enabled sessions, and keep the good old L7 LB farm > for SSL decipher/HTTP extraction/SSL cipher to go to the servers. > It offers a smooth upgrade path for existing infrastructures, > because if this mechanism is implemented in high grade switches, > then the big investments on the LBs are maintained without any > change to continue to handle all clients who do not emit flow > labels. The L3/L4 LB implemented in the switch is just an L7 LB > bypass. flow label can be used for L3/L4 LB obviously. But we are talking about how flow label could ease L7 LB's job. Thanks, washam From w@1wt.eu Sat Mar 3 06:01:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3398021F86F0 for ; Sat, 3 Mar 2012 06:01:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.196 X-Spam-Level: X-Spam-Status: No, score=-3.196 tagged_above=-999 required=5 tests=[AWL=-5.141, BAYES_00=-2.599, FRT_STOCK2=3.988, HELO_IS_SMALL6=0.556] 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 0fQAUxfb50Dx for ; Sat, 3 Mar 2012 06:01:03 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE3D21F86E3 for ; Sat, 3 Mar 2012 06:01:02 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q23E10Im023506; Sat, 3 Mar 2012 15:01:00 +0100 Date: Sat, 3 Mar 2012 15:01:00 +0100 From: Willy Tarreau To: Washam Fan Message-ID: <20120303140100.GK20538@1wt.eu> References: <20120302070551.GB13959@1wt.eu> <20120302112130.GB16141@1wt.eu> <20120302142038.GE16141@1wt.eu> <20120302150537.GF16141@1wt.eu> <20120303082147.GF20538@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: IPv6 Operations Subject: Re: [v6ops] So nobody cares about load balancers? [ draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 14:01:04 -0000 Hi Washam, On Sat, Mar 03, 2012 at 09:48:02PM +0800, Washam Fan wrote: > > No, L7 and flow label usage *cannot* be mixed that way. > > I was not suggesting this. I was think that what the draft says. The > authors might clarify that. Thanks, that's precisely to get this feedback on what needs to be clarified that the draft was posted to the list :-) I'm pretty sure we need to work a lot on it still (and possibly fix some points). (...) > >   1) he has IP address 1.1.1.1 dynamically assigned by the nearest cell. > >   2) he opens the browser > >   3) he clicks on the bookmark > >   4) the browser picks a random flow label 0x12345 and connects to the > >      bank doing a setsockopt() on all outgoing connections so that all > >      packets have the proper flow label. > >   5) incoming connections pass through the L7 LB which only see > >      the srcIP (1.1.1.1) and the flow label (0x12345). Connections > >      are forwarded to the servers. > >   6) the home page is totally stateless, the server does not emit > >      any cookie. > >   7) he logs in, so that's a new request. > >   8) LB knows the flow label (0x12345) and directs the stream to the > >      same server. > >   9) bank servers emit a session cookie which can only be seen at > >      L7 but nobody is looking. > >  10) the car enters a tunnel. Lack of connectivity. When leaving > >      the tunnel, the phone finally recovers connectivity with a > >      new 1.1.1.2 address. > >  11) foo clicks on an operation on the page. > >  12) the LB receives a request from IP 1.1.1.2 with the flow label > >      0x12345. If it considers the IP in association with the flow > >      label, then it does not know this association. If it decides > >      to decipher the stream and extract the cookie, it will see a > >      cookie it does not know and will pick a new server. > > Why the cookie is unknown? cookies can be used across different > 'transport layer' sessions. Because at none of the steps above the L7 LB had a chance to see it, look carefully. The only steps it saw the request/response was 5-6, and such steps did not carry any cookie yet. > >  13) the request goes to the wrong server, it doesn't have the user > >      context and the poor guy has lost his session (and cannot even > >      log it off). > > > > Now I know what you'll say, let's have the server emit the session > > ID upon first request to the home page (6). Eventhough it's in general > > not acceptable because it requires some deep application level changes, > > it only pushes the problem one step further, because once the session > > is renewed (eg: frequent sessions renewal due to the bank's security > > measures, or user foo being idle for too long talking to his friend), > > the LB doesn't catch the new cookie and will still have the issue at > > step 12. > > > > Another workaround would be to have the L7 LB insert the stickiness > > cookie itself at stem 6. That still doesn't survive a change of server > > which would leave the initial server's cookie in the request with a > > flow label associated to another server. > > it is cookie associated to a backend server, and different {srcIP, > flow} pairs can be associated to the same cookie. It depends. If it's the cookie associated to the server (which is commonly called stickiness cookie or persistence cookie), it has to be inserted by the L7 LB. Then if you have two distinct LBs (L4 and L7), none of them knows when the other decides to rebalance the traffic (eg: a faulty server has resumed, flow label might be updated but the L7 cookie won't be touched by anyone). > > Also there is an architectural issue in mixing the two methods the > > way you're suggesting it, it forces the flow label LB and the L7 LB > > to be the same, which doesn't scale at all. The goal of using the > > flow label was to be able to use distinct components so that the > > flow works like this : > > > >                         +-------+ > >                         | ASIC- |  flow label present > >  client packets ------->| based |------------------------> servers > >                         | L3/L4 | > >                         |   LB  | > >                         +-------+ > >                             | no flow label > >                             |       +----------+ > >                             |       | software | > >                             +------>| based L7 |---------> servers > >                                     |    LBs   | > >                                     +----------+ > > > > With this model, you can have 1 entry point which processes all > > flow label enabled sessions, and keep the good old L7 LB farm > > for SSL decipher/HTTP extraction/SSL cipher to go to the servers. > > It offers a smooth upgrade path for existing infrastructures, > > because if this mechanism is implemented in high grade switches, > > then the big investments on the LBs are maintained without any > > change to continue to handle all clients who do not emit flow > > labels. The L3/L4 LB implemented in the switch is just an L7 LB > > bypass. > > flow label can be used for L3/L4 LB obviously. But we are talking > about how flow label could ease L7 LB's job. Not exactly, more like to bypass them, hence reducing their work. In fact, we can also make L7 LBs use and even forward a flow label (and I'm planning on adding that to haproxy+provide some linux patches when we make progress on this draft). But I really think that if we *only* focus on getting all the job done by L7 LBs, then we'd better use something else than those bits which are present in every packet. The reason is that an L7 LB handles connections. Having a TCP option to carry such an ID would be more than enough. But it would not work on totally stateless devices (eg: L3 LBs, switches). Using the bits at L3 makes this possible. Right now swiches are able to process terabits of aggregated traffic, while L7 LBs are only able of tens of gigabits at best. This is why it's much better to be able to bypass L7 LBs than just making their work easier. Regards, Willy From internet-drafts@ietf.org Sat Mar 3 12:15:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250DA21F867E; Sat, 3 Mar 2012 12:15:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 SW0eaWazjKq7; Sat, 3 Mar 2012 12:14:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E52221F8551; Sat, 3 Mar 2012 12:14:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120303201441.644.24514.idtracker@ietfa.amsl.com> Date: Sat, 03 Mar 2012 12:14:41 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ra-guard-implementation-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 20:15:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : Implementation Advice for IPv6 Router Advertisement Guar= d (RA-Guard) Author(s) : Fernando Gont Filename : draft-ietf-v6ops-ra-guard-implementation-01.txt Pages : 18 Date : 2012-03-03 The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly employed to mitigate attack vectors based on forged ICMPv6 Router Advertisement messages. Many existing IPv6 deployments rely on RA- Guard as the first line of defense against the aforementioned attack vectors. However, some implementations of RA-Guard have been found to be prone to circumvention by employing IPv6 Extension Headers. This document describes the evasion techniques that affect the aforementioned implementations, and provides advice on the implementation of RA-Guard, such that the RA-Guard evasion vectors are eliminated. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ra-guard-implementatio= n-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-ra-guard-implementation= -01.txt From joelja@bogus.com Sat Mar 3 14:33:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1ECE21F85B5 for ; Sat, 3 Mar 2012 14:33:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 MOkanNZm3XlC for ; Sat, 3 Mar 2012 14:33:30 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 50C9921F85B4 for ; Sat, 3 Mar 2012 14:33:30 -0800 (PST) Received: from Joels-MacBook-Pro.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q23MXSWb012996 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Sat, 3 Mar 2012 22:33:29 GMT (envelope-from joelja@bogus.com) Message-ID: <4F529C37.9090900@bogus.com> Date: Sat, 03 Mar 2012 14:33:27 -0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: IPv6 Ops WG References: <20120303200905.31106.67929.idtracker@ietfa.amsl.com> In-Reply-To: <20120303200905.31106.67929.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120303200905.31106.67929.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 03 Mar 2012 22:33:29 +0000 (UTC) Subject: [v6ops] Fwd: ID Tracker State Update Notice: X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 22:33:31 -0000 fyi It looks like this docuement is moving to publication. -------- Original Message -------- Subject: ID Tracker State Update Notice: Date: Sat, 03 Mar 2012 12:09:05 -0800 From: IETF Secretariat To: v6ops-chairs@tools.ietf.org, draft-ietf-v6ops-v6nd-problems@tools.ietf.org State changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6nd-problems/ From fgont@si6networks.com Sat Mar 3 15:51:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A443621F8618 for ; Sat, 3 Mar 2012 15:51:38 -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=-2.599, 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 Y5BAJXit-I-y for ; Sat, 3 Mar 2012 15:51:38 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2999F21F860E for ; Sat, 3 Mar 2012 15:51:38 -0800 (PST) Received: from [2001:5c0:1000:a::1db] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1S3yjd-000378-ET; Sun, 04 Mar 2012 00:51:33 +0100 Message-ID: <4F52AE79.9020504@si6networks.com> Date: Sat, 03 Mar 2012 20:51:21 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Joel jaeggli References: <20120303200905.31106.67929.idtracker@ietfa.amsl.com> <4F529C37.9090900@bogus.com> In-Reply-To: <4F529C37.9090900@bogus.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: ID Tracker State Update Notice: X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 23:51:38 -0000 Hi, Joel, This seems already too-late, but: it seems the comments I had sent were not incorporated? (I didn't receive a response to my feedback, either). Thanks, Fernando On 03/03/2012 07:33 PM, Joel jaeggli wrote: > fyi It looks like this docuement is moving to publication. > > -------- Original Message -------- > Subject: ID Tracker State Update Notice: > > Date: Sat, 03 Mar 2012 12:09:05 -0800 > From: IETF Secretariat > To: v6ops-chairs@tools.ietf.org, > draft-ietf-v6ops-v6nd-problems@tools.ietf.org > > State changed to Approved-announcement to be sent from > Approved-announcement to be sent::Point Raised - writeup needed > ID Tracker URL: > http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6nd-problems/ > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fernando.gont.netbook.win@gmail.com Sun Mar 4 05:40:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8E821F8562 for ; Sun, 4 Mar 2012 05:40:49 -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 IIa9E2U4Mhw5 for ; Sun, 4 Mar 2012 05:40:49 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 095AF21F855F for ; Sun, 4 Mar 2012 05:40:48 -0800 (PST) Received: by ghbg16 with SMTP id g16so1512995ghb.31 for ; Sun, 04 Mar 2012 05:40:48 -0800 (PST) Received-SPF: pass (google.com: domain of fernando.gont.netbook.win@gmail.com designates 10.236.80.4 as permitted sender) client-ip=10.236.80.4; Authentication-Results: mr.google.com; spf=pass (google.com: domain of fernando.gont.netbook.win@gmail.com designates 10.236.80.4 as permitted sender) smtp.mail=fernando.gont.netbook.win@gmail.com; dkim=pass header.i=fernando.gont.netbook.win@gmail.com Received: from mr.google.com ([10.236.80.4]) by 10.236.80.4 with SMTP id j4mr22493973yhe.120.1330868448663 (num_hops = 1); Sun, 04 Mar 2012 05:40:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=guQZjp8/Q8X3A68LuNBKtFTWlyyQsinunnrqIBooGyw=; b=l9mlYdKo48jeYhDobBVx7KZSd9tWSlhGqZ9VnjnIJ5VV5TzhCkmoMAtXpGAn6o/28v f5SAcxy0BCHTOhRQAiiwgR9Qm2vNzz4HswhpWefZl23+7RFFxn07wasdd3s82+qu/jwj gNIGPc2wvCnYjlWIfByrIu03b4oZNdnCjGuXe7+vcgXej5UusARVoliUiLJ7VE+zww95 Jbp5zjS3vsS3sZYH79GBCtcPeGY4kcuAqio0/ZHtc5RMvJpThxEJDZN/H5Q0vBIP/vb5 +NUGh2uNgqJq6MRVaz1f28L3d9N7atIGbkohy3mbD2AMp4KpziJP56jaem5KS1zHDCLw mogA== Received: by 10.236.80.4 with SMTP id j4mr17796199yhe.120.1330868448621; Sun, 04 Mar 2012 05:40:48 -0800 (PST) Received: from [192.168.123.102] ([186.134.1.140]) by mx.google.com with ESMTPS id 32sm19379449anu.14.2012.03.04.05.40.46 (version=SSLv3 cipher=OTHER); Sun, 04 Mar 2012 05:40:47 -0800 (PST) Sender: Fernando Gont Message-ID: <4F5370D7.6070202@gont.com.ar> Date: Sun, 04 Mar 2012 10:40:39 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <4F15E499.5040908@gmail.com> <4F25C955.8070704@gmail.com> <4F32D59E.7080306@gmail.com> <4F47FE6E.7050905@gmail.com> <4F48AB30.7060109@bogus.com> <4F4B566E.3050901@inex.ie> <4F4B675C.4040909@inex.ie> <20120227151105.GO84425@Space.Net> <72DBDB2C-91CF-4794-B1A0-E3454B8C1F26@lists.zabbadoz.net> In-Reply-To: <72DBDB2C-91CF-4794-B1A0-E3454B8C1F26@lists.zabbadoz.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] So nobody cares about load balancers? draft-carpenter-v6ops-label-balance-01.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 13:40:49 -0000 On 02/27/2012 12:54 PM, Bjoern A. Zeeb wrote: > I think part of the load balancer issues is that the latest documents do not > make it fully suitable for "hosts" anymore What specific use do you have in mind here? > where an e-to-end (edge-to-host or > better end-to-end) flow label would be essential (controllable by the host > ideally) or uniquely by an entire management domain, which already breaks with > a customer host (I'll ignore Fernando's immediate concerns there;-) FWIW, while there has been some debate on the issue of the FL being used as a covert channel (fwiw, this was covered in draft-gont-6man-flowlabel-security just for cmopleteness-sake), the important thing here is that if the FL is not covered by an error detection code and it is not authenticated, you cannot really depend on it being immutable -- whether you like it or not. Allowing for the FL to be rewriten is, in part, admitting the above. But it also means that you could deploy a box that set the FL on behalf of old systems that fail to do it, or that do not do it properly. And you also accept the fact that there might be protocol scrubbers already clearing the FL to zero. Thanks, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From joelja@bogus.com Sun Mar 4 13:47:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7256221F8595 for ; Sun, 4 Mar 2012 13:47:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.384 X-Spam-Level: X-Spam-Status: No, score=-101.384 tagged_above=-999 required=5 tests=[AWL=-1.188, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, LONGWORDS=1.803, 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 Nz+JltJNFMK7 for ; Sun, 4 Mar 2012 13:47:26 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 011AE21F855F for ; Sun, 4 Mar 2012 13:47:25 -0800 (PST) Received: from Joels-MacBook-Pro.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q24LlDdO036712 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 4 Mar 2012 21:47:22 GMT (envelope-from joelja@bogus.com) Message-ID: <4F53E2DF.6090904@bogus.com> Date: Sun, 04 Mar 2012 13:47:11 -0800 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Fernando Gont References: <20120303200905.31106.67929.idtracker@ietfa.amsl.com> <4F529C37.9090900@bogus.com> <4F52AE79.9020504@si6networks.com> In-Reply-To: <4F52AE79.9020504@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 04 Mar 2012 21:47:25 +0000 (UTC) Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: ID Tracker State Update Notice: X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 21:47:26 -0000 I read it at the time... we had dropped the 2119 language/boilerplate entirely. the prefix scanning ease issue is something I would dispute... common address assignment methods already greatly facilitate subnet and particularly router discover greatly. this doesn't seem likely to alter that. theres still the opportunity for nit language fixes in auth48 so ew should consider that. On 3/3/12 15:51 , Fernando Gont wrote: > Hi, Joel, > > This seems already too-late, but: it seems the comments I had sent were > not incorporated? (I didn't receive a response to my feedback, either). > > Thanks, > Fernando > > > > > On 03/03/2012 07:33 PM, Joel jaeggli wrote: >> fyi It looks like this docuement is moving to publication. >> >> -------- Original Message -------- >> Subject: ID Tracker State Update Notice: >> >> Date: Sat, 03 Mar 2012 12:09:05 -0800 >> From: IETF Secretariat >> To: v6ops-chairs@tools.ietf.org, >> draft-ietf-v6ops-v6nd-problems@tools.ietf.org >> >> State changed to Approved-announcement to be sent from >> Approved-announcement to be sent::Point Raised - writeup needed >> ID Tracker URL: >> http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6nd-problems/ >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > From victor.kuarsingh@gmail.com Sun Mar 4 18:32:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A067121F869A for ; Sun, 4 Mar 2012 18:32:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 e7NTyj6HSPDY for ; Sun, 4 Mar 2012 18:32:07 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id EBA5521F8698 for ; Sun, 4 Mar 2012 18:32:06 -0800 (PST) Received: by iazz13 with SMTP id z13so5780509iaz.31 for ; Sun, 04 Mar 2012 18:32:04 -0800 (PST) Received-SPF: pass (google.com: domain of victor.kuarsingh@gmail.com designates 10.50.17.230 as permitted sender) client-ip=10.50.17.230; Authentication-Results: mr.google.com; spf=pass (google.com: domain of victor.kuarsingh@gmail.com designates 10.50.17.230 as permitted sender) smtp.mail=victor.kuarsingh@gmail.com; dkim=pass header.i=victor.kuarsingh@gmail.com Received: from mr.google.com ([10.50.17.230]) by 10.50.17.230 with SMTP id r6mr5151499igd.54.1330914724583 (num_hops = 1); Sun, 04 Mar 2012 18:32:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to :mime-version:content-type; bh=BZvweEOUemboJiLHN8j72+mcPTMlpWjXX6UG76zR5Gs=; b=xnxFRvKT2Paq9EWJWpiFtBLkryyeTfP0J3Rixsi/FCn6K1hZ4H5sPQRTqIxMeA8mut gnZ511YazSySMZVagUSly4+l68jU8RiZ+2x9qOuRTg96A/Os0dRUxT13Mlhoknuw+1nB qtDEmvzpWEToVWmA8s1Sh7XvK4+POTKsYqc9jLDiH44bhGAG4f2+geZfylfZ5z8fNtLM 7UX5S6FiRqULUlrvjWHj2Q345HBu7Jc0yllpMF3X+P44byIesKzcOYTzV+ZIYw0Dg3vO xASSWSTWKru6QJRu55WP2J47CGXi+TQTq3X9K6/VpAR1Z+275E9lv5pPV1fgM89WSTRC Xm9g== Received: by 10.50.17.230 with SMTP id r6mr4308578igd.54.1330914724514; Sun, 04 Mar 2012 18:32:04 -0800 (PST) Received: from [192.168.100.205] ([67.224.83.162]) by mx.google.com with ESMTPS id df2sm15846357igb.0.2012.03.04.18.32.00 (version=SSLv3 cipher=OTHER); Sun, 04 Mar 2012 18:32:03 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Sun, 04 Mar 2012 21:31:57 -0500 From: Victor Kuarsingh To: Message-ID: Thread-Topic: Updated Feedback on Wireline Incremental IPv6 In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3413741521_34935715" Subject: Re: [v6ops] Updated Feedback on Wireline Incremental IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 02:32:08 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3413741521_34935715 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable V6ops team, (Second Post of this message) A new version of "draft-ietf-v6ops-wireline-incremental-ipv6-01" has been posted including feedback from the group. This version has some textual improvements and has made the following changes. 1. We have removed some language which focused on the IPv4 connectivity phenomenon (we did not remove all, but some). The focus of this document i= s about IPv6 introduction and evolution. This is also based on other discussions such as the Intarea meeting in Taipei (ref - http://www.ietf.org/proceedings/82/intarea.html) 2. The third phase is no longer called tunnelled IPv4, but IPv6-only. This phase would include tunnelled mode IPv4 if required (I.e. DS-LITE) I would like WG feedback if the refined focus (which is based on comments on/off list) is in line with how the WG thinks this document should proceed= . As well, I would also like feedback on the inclusion/exclusion of the following technologies in phase 3. 1. NAT64. Although this mode of operation will be difficult in the foreseeable future (on it's own) in a Wireline network due to the massive amounts of iPv4 equipment in the environment, it may be of consideration to some wireline providers. 2. Also, should we include discussion on 464 xlate (draft-ietf-v6ops-464xlat-00) framework/architecture. Although the documen= t is focused on "commercially available" technology, it appears that the technology for the 464 xlate is available (CLAT via some beta code and NAT6= 4 is out there) I would like to build in comments in the next rev =AD02. In that rev, there will also be additional considerations discussion/information based on some additional input which is coming now. Regards, Victor K --B_3413741521_34935715 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
V6ops team, (Second Post of = this message)
=

  1. We have removed some language which focused on the IP= v4 connectivity phenomenon (we did not remove all, but some).  The focu= s of this document is about IPv6 introduction and evolution.  This is a= lso based on other discussions such as the Intarea meeting in Taipei (ref -&= nbsp;http://www.ie= tf.org/proceedings/82/intarea.html)
  2. The third phase is no longer= called tunnelled IPv4, but IPv6-only.  This phase would include tunnel= led mode IPv4 if required (I.e. DS-LITE)
I would like WG feedb= ack if the refined focus (which is based on comments on/off list) is in line= with how the WG thinks this document should proceed.  As well, I would= also like feedback on the inclusion/exclusion of the following technologies= in phase 3.

  1. NAT64.  Although this mode of = operation will be difficult in the foreseeable future (on it's own) in a Wir= eline network due to the massive amounts of iPv4 equipment in the environmen= t, it may be of consideration to some wireline providers.
  2. Also, shou= ld we include discussion on 464 xlate (draft-ietf-v6ops-464xlat-00) framewor= k/architecture.  Although the document is focused on "commercially avai= lable" technology, it appears that the technology for the 464 xlate is avail= able (CLAT via some beta code and NAT64 is out there)
I would = like to build in comments in the next rev –02.  In that rev, ther= e will also be additional considerations discussion/information based on som= e additional input which is coming now.

Regards,

Victor K
--B_3413741521_34935715-- From john.mann@monash.edu Sun Mar 4 18:48:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28C9A21F86AD for ; Sun, 4 Mar 2012 18:48:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.376 X-Spam-Level: X-Spam-Status: No, score=-5.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 iwrJhej7O8Jv for ; Sun, 4 Mar 2012 18:48:49 -0800 (PST) Received: from na3sys009aog105.obsmtp.com (na3sys009aog105.obsmtp.com [74.125.149.75]) by ietfa.amsl.com (Postfix) with ESMTP id B58EB21F8682 for ; Sun, 4 Mar 2012 18:48:48 -0800 (PST) Received: from mail-tul01m020-f176.google.com ([209.85.214.176]) (using TLSv1) by na3sys009aob105.postini.com ([74.125.148.12]) with SMTP ID DSNKT1Qpj6VwN0oVs9WH85zsMtFUhxmLz0AA@postini.com; Sun, 04 Mar 2012 18:48:48 PST Received: by obbef5 with SMTP id ef5so4263383obb.7 for ; Sun, 04 Mar 2012 18:48:47 -0800 (PST) Received-SPF: pass (google.com: domain of john.mann@monash.edu designates 10.60.29.10 as permitted sender) client-ip=10.60.29.10; Authentication-Results: mr.google.com; spf=pass (google.com: domain of john.mann@monash.edu designates 10.60.29.10 as permitted sender) smtp.mail=john.mann@monash.edu Received: from mr.google.com ([10.60.29.10]) by 10.60.29.10 with SMTP id f10mr1806610oeh.32.1330915727212 (num_hops = 1); Sun, 04 Mar 2012 18:48:47 -0800 (PST) Received: by 10.60.29.10 with SMTP id f10mr1634054oeh.32.1330915727118; Sun, 04 Mar 2012 18:48:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.154.39 with HTTP; Sun, 4 Mar 2012 18:48:27 -0800 (PST) In-Reply-To: <317616CE96204D49B5A1811098BA895006B6DFDE@XMB-AMS-110.cisco.com> References: <317616CE96204D49B5A1811098BA895006B6DFDE@XMB-AMS-110.cisco.com> From: John Mann Date: Mon, 5 Mar 2012 13:48:27 +1100 Message-ID: To: "Eric Vyncke (evyncke)" Content-Type: multipart/alternative; boundary=e89a8ff1c89a24114a04ba75f746 X-Gm-Message-State: ALoCoQlijuwh4clq9kh2xaHenXc0QoiV24sRTLrKJx9crWCPWDyP05qJRzt8ENYBr1mxi45b7b2n Cc: v6ops@ietf.org Subject: Re: [v6ops] FW: New Version Notification for draft-vyncke-ipv6-traffic-in-p2p-networks-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 02:48:50 -0000 --e89a8ff1c89a24114a04ba75f746 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, --- The measurements were done in two periods: --- Three, or perhaps four periods. --- o May 2009 to July 2009: 5,000,000 peers were discovered but we were only able to to establish a BitTorrent connection with 1,500,000 peers; o 1 day in October 2009: 100,000 peers were discovered; ... --- Are the IPv6 stats based on the total number of peers discovered, or on the peers that you were able to establish connections to? If "establish connections to", then what were the numbers for the subsequent tests? s/Chine/China/ I also wonder whether the choice of torrents effected which peers and which countries were detected. For example, a torrent swarm for a particular language/type of software or movie may mostly be of interest to people in particular countries. Or if a tracker inside China was only used mostly by users inside that country, you may not get to know about those torrents or users. Thanks, John On 2 March 2012 23:21, Eric Vyncke (evyncke) wrote: > Updated version with more recent statistics about BitTorrent peers using > or not IPv6. For a more graphical version: > http://www.vyncke.org/ipv6status/p2p.php > > -=E9ric > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: vendredi 2 mars 2012 13:18 > To: Eric Vyncke (evyncke) > Cc: martin.defeche@gmail.com > Subject: New Version Notification > fordraft-vyncke-ipv6-traffic-in-p2p-networks-01.txt > > A new version of I-D, draft-vyncke-ipv6-traffic-in-p2p-networks-01.txt ha= s > been successfully submitted by Eric Vyncke and posted to the IETF > repository. > > Filename: draft-vyncke-ipv6-traffic-in-p2p-networks > Revision: 01 > Title: Measuring IPv6 Traffic in BitTorrent Networks > Creation date: 2012-03-02 > WG ID: Individual Submission > Number of pages: 12 > > Abstract: > This document is a follow-up of a University thesis which aims to > measure the evolution over time of IPv6 traffic and to analyze the > geographical distribution of IPv6 nodes. The first measurements were > done during the Summer 2009 using a specific-purpose program which > connects to the BitTorrent peer-to-peer network and this document > adds measurements done with the same program but in October 2011 and > February 2012. > > The study was made in Peer-to-Peer (P2P) networks because they are > responsible for a big part of Internet traffic and because their > structure and functioning permit a rapid discovery of a large number > of nodes from all over the world. In addition, the P2P users are > more likely to be interested by IPv6 as IPv6 does not have the same > NAT problems as IPv4. > > > > > The IETF Secretariat > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --e89a8ff1c89a24114a04ba75f746 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

---
The measurements were done in two periods:
---
Thre= e, or perhaps four periods.

---
   o  May =
2009 to July 2009: 5,000,000 peers were discovered but we were
      only able to to establish a BitTorrent connection with 1,500,000
      peers;

   o  1 day in October 2009: 100,000 peers were discovered;
...
---
Are the IPv6 stats based on the total number of peers d= iscovered, or on the peers that you were able to establish connections to?<= br>If "establish connections to", then what were the numbers for = the subsequent tests?

s/Chine/China/

I also wonder whether the choice of torrents effe= cted which peers and which countries were detected.
For example, a torre= nt swarm for a particular language/type of software or movie may mostly be = of interest to people in particular countries.
Or if a tracker inside China was only used mostly by users inside that coun= try, you may not get to know about those torrents or users.

Thanks,<= br>=A0=A0=A0 John

On 2 March 2012 23:21, Eric Vyncke (evyncke) <evyncke@cisco.com= > wrote:
Updated version w= ith more recent statistics about BitTorrent peers using or not IPv6. For a = more graphical version:
http= ://www.vyncke.org/ipv6status/p2p.php

-=E9ric

-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: vendredi 2 mars 2012 13:18
To: Eric Vyncke (evyncke)
Cc: martin.defeche@gmail.com
Subject: New Version Notification fordraft-vyncke-ipv6-traffic-in-p2p-netwo= rks-01.txt

A new version of I-D, draft-vyncke-ipv6-traffic-in-p2p-networks-01.txt has = been successfully submitted by Eric Vyncke and posted to the IETF repositor= y.

Filename: =A0 =A0 =A0 =A0draft-vyncke-ipv6-traffic-in-p2p-networks
Revision: =A0 =A0 =A0 =A001
Title: =A0 =A0 =A0 =A0 =A0 Measuring IPv6 Traffic in BitTorrent Networks Creation date: =A0 2012-03-02
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 12

Abstract:
=A0 This document is a follow-up of a University thesis which aims to
=A0 measure the evolution over time of IPv6 traffic and to analyze the
=A0 geographical distribution of IPv6 nodes. =A0The first measurements wer= e
=A0 done during the Summer 2009 using a specific-purpose program which
=A0 connects to the BitTorrent peer-to-peer network and this document
=A0 adds measurements done with the same program but in October 2011 and =A0 February 2012.

=A0 The study was made in Peer-to-Peer (P2P) networks because they are
=A0 responsible for a big part of Internet traffic and because their
=A0 structure and functioning permit a rapid discovery of a large number =A0 of nodes from all over the world. =A0In addition, the P2P users are =A0 more likely to be interested by IPv6 as IPv6 does not have the same =A0 NAT problems as IPv4.




The IETF Secretariat
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--e89a8ff1c89a24114a04ba75f746-- From cb.list6@gmail.com Sun Mar 4 19:19:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E87221F8507 for ; Sun, 4 Mar 2012 19:19:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.135 X-Spam-Level: X-Spam-Status: No, score=-3.135 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 czQt63kHXWcg for ; Sun, 4 Mar 2012 19:19:37 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9628B21F84AE for ; Sun, 4 Mar 2012 19:19:37 -0800 (PST) Received: by obbta4 with SMTP id ta4so1887166obb.31 for ; Sun, 04 Mar 2012 19:19:37 -0800 (PST) Received-SPF: pass (google.com: domain of cb.list6@gmail.com designates 10.60.12.230 as permitted sender) client-ip=10.60.12.230; Authentication-Results: mr.google.com; spf=pass (google.com: domain of cb.list6@gmail.com designates 10.60.12.230 as permitted sender) smtp.mail=cb.list6@gmail.com; dkim=pass header.i=cb.list6@gmail.com Received: from mr.google.com ([10.60.12.230]) by 10.60.12.230 with SMTP id b6mr5449567oec.54.1330917577300 (num_hops = 1); Sun, 04 Mar 2012 19:19:37 -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=UVxaMl8a2mMIGU94jw3eS3S/1IXRFokoR9sXyJ3a4gg=; b=GT0D0Tk3tMCZZFJim1GuN060nyMVrsyhDx0jS9cWRGYQLn+9hjdOFaLD6vqIF79Hkg pF2tU2Rnvu3bQvAuyYSXnAtcjPdQnxmwrBIDoL5+/6eU4juV2QkXAY8noOKU7WClHg2T TudlpmIe/JnkNoCTjsE89ahTN8KEqTfehPif2YnI8NXgMQqwA6HMs6DI27cIpu5zt+0W 69rNUv5RKWo9okDYDxS6ebs+grSMp2C+qEMRdrzszYaBokvRX6lQTLKyJM/MJo/QAx3Y MKVTJdC3V6kTdOKEXmxE4tatoVb1ich73Hr7kUAGtrryavtQD3kwKahcKwdHg2QcsdAm CxrQ== MIME-Version: 1.0 Received: by 10.60.12.230 with SMTP id b6mr4835462oec.54.1330917577245; Sun, 04 Mar 2012 19:19:37 -0800 (PST) Received: by 10.182.192.41 with HTTP; Sun, 4 Mar 2012 19:19:37 -0800 (PST) Received: by 10.182.192.41 with HTTP; Sun, 4 Mar 2012 19:19:37 -0800 (PST) In-Reply-To: References: Date: Sun, 4 Mar 2012 19:19:37 -0800 Message-ID: From: Cameron Byrne To: Victor Kuarsingh Content-Type: multipart/alternative; boundary=e89a8ff1ce266ac58504ba766526 Cc: v6ops@ietf.org Subject: Re: [v6ops] Updated Feedback on Wireline Incremental IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 03:19:38 -0000 --e89a8ff1ce266ac58504ba766526 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mar 4, 2012 6:32 PM, "Victor Kuarsingh" @ gmail.com > wrote= : > > V6ops team, (Second Post of this message) > > A new version of "draft-ietf-v6ops-wireline-incremental-ipv6-01" has been posted including feedback from the group. This version has some textual improvements and has made the following changes. > > We have removed some language which focused on the IPv4 connectivity phenomenon (we did not remove all, but some). The focus of this document is about IPv6 introduction and evolution. This is also based on other discussions such as the Intarea meeting in Taipei (ref - http:// www.ietf.org /proceedings/82/ intarea.html ) > The third phase is no longer called tunnelled IPv4, but IPv6-only. This phase would include tunnelled mode IPv4 if required (I.e. DS-LITE) > I would like WG feedback if the refined focus (which is based on comments on/off list) is in line with how the WG thinks this document should proceed. As well, I would also like feedback on the inclusion/exclusion of the following technologies in phase 3. > > NAT64. Although this mode of operation will be difficult in the foreseeable future (on it's own) in a Wireline network due to the massive amounts of iPv4 equipment in the environment, it may be of consideration to some wireline providers. Understood, but there are places in wireline that can work ipv6-only in time (ftth) > Also, should we include discussion on 464 xlate (draft-ietf-v6ops-464xlat-00) framework/architecture. Although the document is focused on "commercially available" technology, it appears that the technology for the 464 xlate is available (CLAT via some beta code and NAT64 is out there) Yes, there is the Android code. NEC also has a commercial home gateway product with CLAT feature. I am also in the process of documenting proof of concept testing using the Cisco asr 1000 and Linux Tayga both functioning as CLAT. As co-author of the 464xlat draft, I think it would be a relevant scenario for your draft to reference Cb > I would like to build in comments in the next rev =9602. In that rev, there will also be additional considerations discussion/information based on some additional input which is coming now. > > Regards, > > Victor K > > _______________________________________________ > v6ops mailing list > v6ops @ ietf.org > https:// www.ietf.org /mailman/ listinfo / v6ops > --e89a8ff1ce266ac58504ba766526 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable


On Mar 4, 2012 6:32 PM, "Victor Kuarsingh" <victor.kuarsingh@gmail= .com> wrote:
>
> V6ops team, (Second Post of this message)
>
> A new version of "draft-ietf-v6ops-wireline-incremental-ipv6-01&q= uot; has been posted including feedback from the group. =A0This version has= some textual improvements and has made the following changes.
>
> We have removed some language which focused on the IPv4 connectivity p= henomenon (we did not remove all, but some). =A0The focus of this document = is about IPv6 introduction and evolution. =A0This is also based on other di= scussions such as the Intarea meeting in Taipei (ref -=A0http://www.ietf.org/proceedings/82/intarea.html)
> The third phase is no longer called tunnelled IPv4, but IPv6-only. =A0= This phase would include tunnelled mode IPv4 if required (I.e. DS-LITE)
> I would like WG feedback if the refined focus (which is based on comme= nts on/off list) is in line with how the WG thinks this document should pro= ceed. =A0As well, I would also like feedback on the inclusion/exclusion of = the following technologies in phase 3.
>
> NAT64. =A0Although this mode of operation will be difficult in the for= eseeable future (on it's own) in a Wireline network due to the massive = amounts of iPv4 equipment in the environment, it may be of consideration to= some wireline providers.

Understood, but there are places in wireline that can work ipv6-only in = time (ftth)

> Also, should we include discussion on 464 xlate (draft-ietf-v6ops-4= 64xlat-00) framework/architecture. =A0Although the document is focused on &= quot;commercially available" technology, it appears that the technolog= y for the 464 xlate is available (CLAT via some beta code and NAT64 is out = there)

Yes, there is the Android code.=A0 NEC also has a commercial home gatewa= y product with CLAT feature.=A0 I am also in the process of documenting pro= of of concept testing using the Cisco asr 1000 and Linux Tayga both functio= ning as CLAT.

As co-author of the 464xlat draft, I think it would be a relevant scenar= io for your draft to reference

Cb
> I would like to build in comments in the next rev =9602. =A0In that re= v, there will also be additional considerations discussion/information base= d on some additional input which is coming now.
>
> Regards,
>
> Victor K
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

--e89a8ff1ce266ac58504ba766526-- From john.mann@monash.edu Sun Mar 4 20:24:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E60021F866C for ; Sun, 4 Mar 2012 20:24:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.376 X-Spam-Level: X-Spam-Status: No, score=-5.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 zbdgRK353m0I for ; Sun, 4 Mar 2012 20:24:17 -0800 (PST) Received: from na3sys009aog126.obsmtp.com (na3sys009aog126.obsmtp.com [74.125.149.155]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD1521F8534 for ; Sun, 4 Mar 2012 20:24:17 -0800 (PST) Received: from mail-tul01m020-f178.google.com ([209.85.214.178]) (using TLSv1) by na3sys009aob126.postini.com ([74.125.148.12]) with SMTP ID DSNKT1Q/8Oy3BARKUXi+0Fn1D7FC/3U87UY2@postini.com; Sun, 04 Mar 2012 20:24:17 PST Received: by obbuo19 with SMTP id uo19so5832201obb.37 for ; Sun, 04 Mar 2012 20:24:16 -0800 (PST) Received-SPF: pass (google.com: domain of john.mann@monash.edu designates 10.60.26.133 as permitted sender) client-ip=10.60.26.133; Authentication-Results: mr.google.com; spf=pass (google.com: domain of john.mann@monash.edu designates 10.60.26.133 as permitted sender) smtp.mail=john.mann@monash.edu Received: from mr.google.com ([10.60.26.133]) by 10.60.26.133 with SMTP id l5mr7340424oeg.22.1330921456256 (num_hops = 1); Sun, 04 Mar 2012 20:24:16 -0800 (PST) Received: by 10.60.26.133 with SMTP id l5mr6446245oeg.22.1330921456161; Sun, 04 Mar 2012 20:24:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.154.39 with HTTP; Sun, 4 Mar 2012 20:23:56 -0800 (PST) In-Reply-To: <4F45B554.2060103@gmail.com> References: <4F45B554.2060103@gmail.com> From: John Mann Date: Mon, 5 Mar 2012 15:23:56 +1100 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=e89a8fb206b69e528104ba774c3c X-Gm-Message-State: ALoCoQnwxoqdfiXmDHqHFujFzHbLryNyAXACAoB2mst9SouiUboFlZyD0iWP6M/K8pXgMVGg+NT8 Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action: draft-carpenter-v6ops-icp-guidance-03.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 04:24:18 -0000 --e89a8fb206b69e528104ba774c3c Content-Type: text/plain; charset=ISO-8859-1 Hi, --- An important first step in every strategy is to determine from every hardware and software supplier details of their planned dates for providing full IPv6 support, with performance equivalent to IPv4, in their products and services. --- I disagree with this being a _first_ step. Asking _every_ hardware and software supplier can take a lot of time and effort, and can lead to ICP in-action e.g. if some suppliers are not ready. Also, "full IPv6 support" can be hard to specify and evaluate -- do you mean comply with all RFCs, pass specific certification tests, or just the specific list of features that you use with IPv4? My alternate view is a) Make a policy decision to avoid the creation of any new customer-facing networks or services that are IPv4-only b) Enable IPv6 on what you already have, with perhaps some tactical expenditure to: i) get some IPv6 traffic flowing ii) start work on the sections described below e.g. external connectivity, address plan, training, operations, and security. iii) get the first IPv6 service operational c) Build on the experience and success of the first service to plan and justify subsequent IPv6 steps. d) Triage your hardware and software i) legacy internal IPv4-only systems that don't ever need to support IPv6 ii) systems that can already support IPv6 iii) systems due to be replaced soon -- by systems that will support IPv6 (see (a) above) iv) systems that will require extra effort or expenditure to get IPv6 support v) problem systems -- e.g. none of the possible suppliers have an IPv6 roadmap. ==== I think some mention could be made in 5.2. Routing that running dual-stack could require twice the routing table space and forwarding TCAM in the routers And in 13. Security Considerations that running dual-stack could require twice the amount of permission lists, ACLs, TCAMs etc. The growth in table size hopefully won't be 5 times (32 bits to 32 + 128 bits), due to most IPv6 routing only going down to /64s, fewer IPv6 routes, shorter history of IPv6 exceptions, etc. Thanks, John On 23 February 2012 14:41, Brian E Carpenter wrote: > Hi, > > This version has various updates due to comments from the WG. > > We are not asking for a meeting slot in Paris, but we'd like the > chairs to put the question whether the WG wants to adopt this > draft. In any case we still want more input to correct and > expand the draft. > > Brian + Sheng > > -------- Original Message -------- > Subject: I-D Action: draft-carpenter-v6ops-icp-guidance-03.txt > Date: Wed, 22 Feb 2012 14:30:09 -0800 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > Title : IPv6 Guidance for Internet Content and > Application Service Providers > Author(s) : Brian Carpenter > Sheng Jiang > Filename : draft-carpenter-v6ops-icp-guidance-03.txt > Pages : 18 > Date : 2012-02-22 > > This document provides guidance and suggestions for Internet > Content > Providers and Application Service Providers who wish to offer > their > service to both IPv6 and IPv4 customers. Many of the points will > also apply to any enterprise network preparing for IPv6 users. > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > > ftp://ftp.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance-03.txt > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draftdirectories: > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --e89a8fb206b69e528104ba774c3c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

---
   An important first step in ever=
y strategy is to determine from every
   hardware and software supplier details of their planned dates for
   providing full IPv6 support, with performance equivalent to IPv4, in
   their products and services.
---
I disagree with this being a _fir=
st_ step.
Asking _every_ hardware and software supplier can take a lot o=
f time and effort,
and can lead to ICP in-action e.g. if some suppliers =
are not ready.


Also, "full IPv6 support" can be hard to specify and evaluate -- =
do you mean comply with all RFCs,
pass specific certification tests, or =
just the specific list of features that you use with IPv4?

My altern=
ate view is


a) Make a policy decision to avoid the creation of any new customer-facing =
networks or services that are IPv4-only
b) Enable IPv6 on what you alrea=
dy have, with perhaps some tactical expenditure to:
   i) get some IPv6 =
traffic flowing


   ii) start work on the sections described below e.g. external connectivit=
y, address plan, training, operations, and security.
   iii) get the fir=
st IPv6 service operational
c) Build on the experience and success of th=
e first service to plan and justify subsequent IPv6 steps.


d) Triage your hardware and software
   i) legacy internal IPv4-only sys=
tems that don't ever need to support IPv6
   ii) systems that can al=
ready support IPv6
   iii) systems due to be replaced soon -- by systems=
 that will support IPv6 (see (a) above)


   iv) systems that will require extra effort or expenditure to get IPv6 su=
pport
   v) problem systems -- e.g. none of the possible suppliers have =
an IPv6 roadmap.

=3D=3D=3D=3D

I think some mention could be m=
ade in 


   5.2. Routing
that running dual-stack could require twice the routing =
table space and forwarding TCAM in the routers

And in
   13. Secu=
rity Considerations
that running dual-stack could require twice the amou=
nt of permission lists, ACLs, TCAMs etc.



The growth in table size hopefully won't be 5 times (32 bits to 32 =
+ 128 bits),
due to most IPv6 routing only going down to /64s, fewer IPv=
6 routes, shorter history of IPv6 exceptions, etc.
Thanks,
=A0=A0=A0 John

On 23 February 2012 14:41,= Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
Hi,

This version has various updates due to comments from the WG.

We are not asking for a meeting slot in Paris, but we'd like the
chairs to put the question whether the WG wants to adopt this
draft. In any case we still want more input to correct and
expand the draft.

=A0 =A0Brian + Sheng

-------- Original Message --------
Subject: I-D Action: draft-carpenter-v6ops-icp-guidance-03.txt
Date: Wed, 22 Feb 2012 14:30:09 -0800
From: internet-drafts@ietf.org<= /a>
Reply-To: internet-drafts@ietf.= org
To: i-d-announce@ietf.org


A New Internet-Draft is available from the on-line
Internet-Drafts directories.

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : IPv6 Guidance for Internet Cont= ent and
Application Service Providers
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Brian Carpenter
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Sheng Jiang
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-carpenter-v6ops-icp-guidanc= e-03.txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 18
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-02-22

=A0 This document provides guidance and suggestions for Internet
Content
=A0 Providers and Application Service Providers who wish to offer
their
=A0 service to both IPv6 and IPv4 customers. =A0Many of the points will =A0 also apply to any enterprise network preparing for IPv6 users.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-= carpenter-v6ops-icp-guidance-03.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ca= rpenter-v6ops-icp-guidance-03.txt

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt


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

--e89a8fb206b69e528104ba774c3c-- From washam.fan@gmail.com Sun Mar 4 21:16:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1C021F85E3 for ; Sun, 4 Mar 2012 21:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.012 X-Spam-Level: X-Spam-Status: No, score=-3.012 tagged_above=-999 required=5 tests=[AWL=-0.013, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 I1Yh641v-bdD for ; Sun, 4 Mar 2012 21:16:01 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id DBEFC21F8613 for ; Sun, 4 Mar 2012 21:16:00 -0800 (PST) Received: by werb10 with SMTP id b10so2774543wer.31 for ; Sun, 04 Mar 2012 21:15:59 -0800 (PST) Received-SPF: pass (google.com: domain of washam.fan@gmail.com designates 10.180.86.9 as permitted sender) client-ip=10.180.86.9; Authentication-Results: mr.google.com; spf=pass (google.com: domain of washam.fan@gmail.com designates 10.180.86.9 as permitted sender) smtp.mail=washam.fan@gmail.com; dkim=pass header.i=washam.fan@gmail.com Received: from mr.google.com ([10.180.86.9]) by 10.180.86.9 with SMTP id l9mr12459574wiz.15.1330924559445 (num_hops = 1); Sun, 04 Mar 2012 21:15:59 -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=3IPEL1EMD/7qjbZ7DxxaXNWcB+QiBVZoCmJSWl+CsR8=; b=CiySb8suvo6YxvvPZkP7iYHtZfZM+PHtwKoPNcT1ntcqUnVDM3Kr674g2uzlSnALhg GVB/d00c5GRJw9lNWvZ3XOBvYmXxgKgeRAsTZZuUfrtRKcS3MJU/A9pApUkS1A1H/wWL +CMFVLuPwXDoDkGztcOzlvyk2lFSxwhhA2ns1yCrz8Z0e1diPfrxPdlddOn5hTbCMV38 SpbCwsAWom9ujiZ7S4ArzC2GpU4jNAwWIYDYlxkD4hmTjdZj4AjEpWoFKzgw8iKDrV/3 YnAe3mLYvvdxq/G4GZ1mOZt6IdtXnf8fyWvT/YsBTHUdBFmzl3tmSqgKrYal9mpucy8P 3TOA== MIME-Version: 1.0 Received: by 10.180.86.9 with SMTP id l9mr9926760wiz.15.1330924559400; Sun, 04 Mar 2012 21:15:59 -0800 (PST) Received: by 10.216.205.169 with HTTP; Sun, 4 Mar 2012 21:15:59 -0800 (PST) In-Reply-To: <201202141455.q1EEt1C04893@ftpeng-update.cisco.com> References: <201202141455.q1EEt1C04893@ftpeng-update.cisco.com> Date: Mon, 5 Mar 2012 13:15:59 +0800 Message-ID: From: Washam Fan To: fred@cisco.com Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org, draft-ietf-v6ops-ra-guard-implementation@tools.ietf.org Subject: Re: [v6ops] new draft: draft-ietf-v6ops-ra-guard-implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 05:16:01 -0000 Hi Author, I have a comment on rule#3 in section 3. It seems to me that the first fragment which can be recognized as non-RA could pass the RA-Guard. Is that the intent? I think we should also drop the first fragment even it can be recognized as non-RA, because we are going to drop the subsequent fragments. Otherwise, there would be a DoS implication on the receiving node. Of course, atomic fragment should be excluded. Thanks, washam 2012/2/14 : > > A new draft has been posted, at http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation. Please take a look at it and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Sun Mar 4 22:10:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C51F21F861C for ; Sun, 4 Mar 2012 22:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.673 X-Spam-Level: X-Spam-Status: No, score=-108.673 tagged_above=-999 required=5 tests=[AWL=1.926, 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 Ekt0Pv7FpUuv for ; Sun, 4 Mar 2012 22:10:36 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 39A5021F8601 for ; Sun, 4 Mar 2012 22:10:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=324; q=dns/txt; s=iport; t=1330927836; x=1332137436; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=nNS67+/WuJRIvr8Hw6CN+cMUArucdr/rxn00y2vgND8=; b=RTi+PoP4FCTYr1/LoAVOhyx3bSI6MmV9pCPGOXl4aMEGT24TDBtKy2To leWp2KUBg0nq1BcmvqHaTp+ZM11iOuDZVZoUWdgVpcY00Xx37BEwikMh+ ViUSwaRiIqCDW6g8hvGM3XdfceA15RbZtNIGkSGSO2zj9aa5GOl72cdfb g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAAJYVE+rRDoI/2dsb2JhbABDtFOBB4F9AQEBAwESASc/BQsLRlcGNYdgBKBVAZYkj3pjBIhOjHCFYYoxgnI X-IronPort-AV: E=Sophos;i="4.73,531,1325462400"; d="scan'208";a="34485063" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 05 Mar 2012 06:10:36 +0000 Received: from Freds-Computer.local (tky-vpn-client-230-223.cisco.com [10.70.230.223]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q256AWuA030278; Mon, 5 Mar 2012 06:10:34 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Mon, 05 Mar 2012 15:10:36 +0900 X-PGP-Universal: processed; by Freds-Computer.local on Mon, 05 Mar 2012 15:10:36 +0900 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Mon, 5 Mar 2012 15:10:10 +0900 Message-Id: References: <201202141455.q1EEt1C04893@ftpeng-update.cisco.com> To: Washam Fan X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, draft-ietf-v6ops-ra-guard-implementation@tools.ietf.org Subject: Re: [v6ops] new draft: draft-ietf-v6ops-ra-guard-implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 06:10:37 -0000 On Mar 5, 2012, at 2:15 PM, Washam Fan wrote: > I think we should also drop the first fragment even it can be > recognized as non-RA, because we are going to drop the subsequent > fragments. Otherwise, there would be a DoS implication on the > receiving node. So - you would like to drop all fragmented packets? From evyncke@cisco.com Sun Mar 4 22:56:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43ADF21F8513 for ; Sun, 4 Mar 2012 22:56:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.113 X-Spam-Level: X-Spam-Status: No, score=-10.113 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 5GAFjFkwnKqF for ; Sun, 4 Mar 2012 22:56:41 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3412F21F8512 for ; Sun, 4 Mar 2012 22:56:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=evyncke@cisco.com; l=14851; q=dns/txt; s=iport; t=1330930601; x=1332140201; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=7Ta7DB9WndNAdn3pVTxTM8cXcvvImsz51z9L1wEFv/I=; b=dJdQsqFlJtgb9Xb3TFOuKVMSxaG3jDu8FhAR8dJpzXS7rP1kr+122X3+ 0XSOBFhg54Vgrg7iBYbKwQp0PJ3U4StbNndQVx8jnjR7GUsYo55wBvbdf 2ar7vPK+/LZjqvy7YzP5rCriMb06FXYzqIC3yLvucQcIbDYSI26x1GDGe U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAEpjVE+Q/khN/2dsb2JhbAApGg6CN7IBgQeBfQEBAQQBAQEPAQkRAz4JAgwEAgEIEQQBAQsGFwEGASAGHwgBCAEBBBMIARmHZQspmTEBjl+PLYkthk1jBIgdmDkFhHWCLDg X-IronPort-AV: E=Sophos;i="4.73,532,1325462400"; d="scan'208,217";a="67645666" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 05 Mar 2012 06:56:05 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q256u5vO018675; Mon, 5 Mar 2012 06:56:05 GMT Received: from xmb-ams-110.cisco.com ([144.254.74.85]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Mar 2012 07:56:05 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCFA9D.08D7131A" Date: Mon, 5 Mar 2012 07:56:03 +0100 Message-ID: <317616CE96204D49B5A1811098BA895006C1A450@XMB-AMS-110.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] FW: New Version Notification for draft-vyncke-ipv6-traffic-in-p2p-networks-01.txt Thread-Index: Acz6en87iiSY1EuKTpeEPtZwMnG3QwAIfEMQ References: <317616CE96204D49B5A1811098BA895006B6DFDE@XMB-AMS-110.cisco.com> From: "Eric Vyncke (evyncke)" To: "John Mann" X-OriginalArrivalTime: 05 Mar 2012 06:56:05.0610 (UTC) FILETIME=[091544A0:01CCFA9D] Cc: v6ops@ietf.org Subject: Re: [v6ops] FW: New Version Notification for draft-vyncke-ipv6-traffic-in-p2p-networks-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 06:56:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFA9D.08D7131A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable John, =20 Thanks for your comments (I will fix the typos). =20 There is indeed a bias linked to which torrents the application tries to = download. This is the reason why it changes of torrents every 15 minutes = (10 torrents in parallel), so, in the course of 2 or 3 days, this makes = about 2000-3000 different torrents. The source of those torrents is = thepiratebay.com which is probably the source of a big bias there. =20 Also, BitTorrent is not used everywhere as in some countries it appears = that there are other P2P. =20 BTW, if there is another source / compilation of torrents, then I am = glad to add it to the next run in addition to the piratebay =20 The count is the number of discovered peers. =20 Regards =20 -=E9ric =20 From: John Mann [mailto:john.mann@monash.edu]=20 Sent: lundi 5 mars 2012 03:48 To: Eric Vyncke (evyncke) Cc: v6ops@ietf.org Subject: Re: [v6ops] FW: New Version Notification for = draft-vyncke-ipv6-traffic-in-p2p-networks-01.txt =20 Hi, --- The measurements were done in two periods: --- Three, or perhaps four periods. --- o May 2009 to July 2009: 5,000,000 peers were discovered but we were only able to to establish a BitTorrent connection with 1,500,000 peers; =20 o 1 day in October 2009: 100,000 peers were discovered; ... --- Are the IPv6 stats based on the total number of peers discovered, or on = the peers that you were able to establish connections to? If "establish connections to", then what were the numbers for the = subsequent tests? s/Chine/China/ I also wonder whether the choice of torrents effected which peers and = which countries were detected. For example, a torrent swarm for a particular language/type of software = or movie may mostly be of interest to people in particular countries. Or if a tracker inside China was only used mostly by users inside that = country, you may not get to know about those torrents or users. Thanks, John On 2 March 2012 23:21, Eric Vyncke (evyncke) wrote: Updated version with more recent statistics about BitTorrent peers = using or not IPv6. For a more graphical version: http://www.vyncke.org/ipv6status/p2p.php =09 -=E9ric =09 -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: vendredi 2 mars 2012 13:18 To: Eric Vyncke (evyncke) Cc: martin.defeche@gmail.com Subject: New Version Notification = fordraft-vyncke-ipv6-traffic-in-p2p-networks-01.txt =09 A new version of I-D, draft-vyncke-ipv6-traffic-in-p2p-networks-01.txt = has been successfully submitted by Eric Vyncke and posted to the IETF = repository. =09 Filename: draft-vyncke-ipv6-traffic-in-p2p-networks Revision: 01 Title: Measuring IPv6 Traffic in BitTorrent Networks Creation date: 2012-03-02 WG ID: Individual Submission Number of pages: 12 =09 Abstract: This document is a follow-up of a University thesis which aims to measure the evolution over time of IPv6 traffic and to analyze the geographical distribution of IPv6 nodes. The first measurements were done during the Summer 2009 using a specific-purpose program which connects to the BitTorrent peer-to-peer network and this document adds measurements done with the same program but in October 2011 and February 2012. =09 The study was made in Peer-to-Peer (P2P) networks because they are responsible for a big part of Internet traffic and because their structure and functioning permit a rapid discovery of a large number of nodes from all over the world. In addition, the P2P users are more likely to be interested by IPv6 as IPv6 does not have the same NAT problems as IPv4. =09 =09 =09 =09 The IETF Secretariat _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ------_=_NextPart_001_01CCFA9D.08D7131A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

John,

 

Thanks for your comments (I will fix the = typos).

 

There is indeed a bias linked to which torrents the = application tries to download. This is the reason why it changes of = torrents every 15 minutes (10 torrents in parallel), so, in the course = of 2 or 3 days, this makes about 2000-3000 different torrents. The = source of those torrents is thepiratebay.com which is probably the = source of a big bias there.

 

Also, BitTorrent is not used everywhere as in some = countries it appears that there are other P2P.

 

BTW, if there is another source / compilation of = torrents, then I am glad to add it to the next run in addition to the = piratebay

 

The = count is the number of discovered peers.

 

Regards

 

-=E9ric

 

From:= John Mann = [mailto:john.mann@monash.edu]
Sent: lundi 5 mars 2012 = 03:48
To: Eric Vyncke (evyncke)
Cc: = v6ops@ietf.org
Subject: Re: [v6ops] FW: New Version = Notification for = draft-vyncke-ipv6-traffic-in-p2p-networks-01.txt

 

Hi,

---
The measurements were done in two = periods:
---
Three, or perhaps four = periods.

---

=A0=A0 o=A0 May 2009 to July =
2009: 5,000,000 peers were discovered but we were
 =
=A0=A0=A0=A0=A0only able to to establish a BitTorrent connection with =
1,500,000
=A0=A0=A0=A0=A0 =
peers;
 
=A0=A0 o=A0 1 =
day in October 2009: 100,000 peers were discovered;

...
---
Are the IPv6 stats based on the total = number of peers discovered, or on the peers that you were able to = establish connections to?
If "establish connections to", = then what were the numbers for the subsequent = tests?

s/Chine/China/

I also wonder whether the choice of = torrents effected which peers and which countries were detected.
For = example, a torrent swarm for a particular language/type of software or = movie may mostly be of interest to people in particular countries.
Or = if a tracker inside China was only used mostly by users inside that = country, you may not get to know about those torrents or = users.

Thanks,
    John

On 2 March 2012 = 23:21, Eric Vyncke (evyncke) <evyncke@cisco.com> = wrote:

Updated = version with more recent statistics about BitTorrent peers using or not = IPv6. For a more graphical version:
http://www.vyncke.org/ipv6status/p2p.php

-=E9= ric

-----Original Message-----
From: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]Sent: vendredi 2 mars 2012 13:18
To: Eric Vyncke (evyncke)
Cc: martin.defeche@gmail.com
= Subject: New Version Notification = fordraft-vyncke-ipv6-traffic-in-p2p-networks-01.txt

A new version = of I-D, draft-vyncke-ipv6-traffic-in-p2p-networks-01.txt has been = successfully submitted by Eric Vyncke and posted to the IETF = repository.

Filename:       =  draft-vyncke-ipv6-traffic-in-p2p-networks
Revision:   =      01
Title:           = Measuring IPv6 Traffic in BitTorrent Networks
Creation date:   = 2012-03-02
WG ID:           Individual = Submission
Number of pages: 12

Abstract:
  This = document is a follow-up of a University thesis which aims to
  = measure the evolution over time of IPv6 traffic and to analyze = the
  geographical distribution of IPv6 nodes.  The first = measurements were
  done during the Summer 2009 using a = specific-purpose program which
  connects to the BitTorrent = peer-to-peer network and this document
  adds measurements done = with the same program but in October 2011 and
  February = 2012.

  The study was made in Peer-to-Peer (P2P) networks = because they are
  responsible for a big part of Internet = traffic and because their
  structure and functioning permit a = rapid discovery of a large number
  of nodes from all over the = world.  In addition, the P2P users are
  more likely to be = interested by IPv6 as IPv6 does not have the same
  NAT problems = as IPv4.




The IETF = Secretariat
_______________________________________________
v6ops = mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

 

------_=_NextPart_001_01CCFA9D.08D7131A-- From washam.fan@gmail.com Mon Mar 5 01:02:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6810221F867A for ; Mon, 5 Mar 2012 01:02:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.311 X-Spam-Level: X-Spam-Status: No, score=-3.311 tagged_above=-999 required=5 tests=[AWL=0.288, 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 rCxaXHGWdRok for ; Mon, 5 Mar 2012 01:02:46 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7DE21F864C for ; Mon, 5 Mar 2012 01:02:46 -0800 (PST) Received: by werb10 with SMTP id b10so2896825wer.31 for ; Mon, 05 Mar 2012 01:02:45 -0800 (PST) Received-SPF: pass (google.com: domain of washam.fan@gmail.com designates 10.180.88.199 as permitted sender) client-ip=10.180.88.199; Authentication-Results: mr.google.com; spf=pass (google.com: domain of washam.fan@gmail.com designates 10.180.88.199 as permitted sender) smtp.mail=washam.fan@gmail.com; dkim=pass header.i=washam.fan@gmail.com Received: from mr.google.com ([10.180.88.199]) by 10.180.88.199 with SMTP id bi7mr13572736wib.12.1330938165536 (num_hops = 1); Mon, 05 Mar 2012 01:02: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=0jPPgPH4H7xW0CzeKB9aKHBP7kSB8ygt5UdsAMXyVfg=; b=UXU+e39Iz0sqixZ+MBuyz8wHn7aRjG7OhkIk3BUCGP2GKdrSxOfB2QAJEA/d0Eubio wZGKm+pHwZojh+WgMcE5++e/+F0fXDYLZTghDtyPM15Qr/yQ+1F94bD/Z7pxE01lyUez MhtGYQA9hB5G1/mpk/9shV4OUpz7lTp/s2FGb3/mLbhQAJ037qUf8Ac1xOertcgROsK6 Q5xViXHf2yS//u/JJKDwqJXDCjhqgQIeKrm7LTQvFDxhkERy93YMJnXuEUPVdQUnCBgK P1BkAexQb+TcTJb3vXcoOTpUnxjZlXof32eRFmM2ZZRvebTha7TCegJOiQBeQvlS15nQ bkPQ== MIME-Version: 1.0 Received: by 10.180.88.199 with SMTP id bi7mr10783495wib.12.1330938165420; Mon, 05 Mar 2012 01:02:45 -0800 (PST) Received: by 10.216.205.169 with HTTP; Mon, 5 Mar 2012 01:02:45 -0800 (PST) In-Reply-To: References: <201202141455.q1EEt1C04893@ftpeng-update.cisco.com> Date: Mon, 5 Mar 2012 17:02:45 +0800 Message-ID: From: Washam Fan To: Fred Baker Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org, draft-ietf-v6ops-ra-guard-implementation@tools.ietf.org Subject: Re: [v6ops] new draft: draft-ietf-v6ops-ra-guard-implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 09:02:47 -0000 Hi Fred, 2012/3/5 Fred Baker : > > On Mar 5, 2012, at 2:15 PM, Washam Fan wrote: > >> I think we should also drop the first fragment even it can be >> recognized as non-RA, because we are going to drop the subsequent >> fragments. Otherwise, there would be a DoS implication on the >> receiving node. > > So - you would like to drop all fragmented packets? Yes. Because if you forward the first fragment and drop all the remaining fragments, the receiving node would always receive the first fragment but no others. Is that considered as an attack? Thanks, washam From fred@cisco.com Mon Mar 5 01:22:14 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57C621F8717 for ; Mon, 5 Mar 2012 01:22:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.707 X-Spam-Level: X-Spam-Status: No, score=-108.707 tagged_above=-999 required=5 tests=[AWL=1.892, 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 CVA4ekrnfmrA for ; Mon, 5 Mar 2012 01:22:14 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4E73C21F8704 for ; Mon, 5 Mar 2012 01:22:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=442; q=dns/txt; s=iport; t=1330939334; x=1332148934; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=/tu+ebE6qkzed+VzLlgVqMSyIn4yx0S91xv6TECtNaI=; b=e4C8E6SYTTUINUv+8t4A0Lw9DU86SLatntLu5Ngiykn8ZywbW+MBLeRd lDAfqEW3r/F1igvDFIEB5TQ5pA/fbyxdJCBIhlvbjJ1AzUoZsDbphTRzV qGa0Fl90Fmicq6esynE10GqDDzFntExhaDQSd+VbsILBlFZaTb3Lf6sNJ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAK+EVE+rRDoI/2dsb2JhbABDtEeBB4F9AQEBAwESASc/EAtGVwY1h2AEmg4BniWPemMEiE6McIVhijGCcg X-IronPort-AV: E=Sophos;i="4.73,533,1325462400"; d="scan'208";a="31927618" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-1.cisco.com with ESMTP; 05 Mar 2012 09:22:13 +0000 Received: from Freds-Computer.local (tky-vpn-client-230-223.cisco.com [10.70.230.223]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q259LAVt014221; Mon, 5 Mar 2012 09:22:10 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Mon, 05 Mar 2012 18:22:12 +0900 X-PGP-Universal: processed; by Freds-Computer.local on Mon, 05 Mar 2012 18:22:12 +0900 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Mon, 5 Mar 2012 18:22:09 +0900 Message-Id: <73B1997A-E0C0-469D-B41E-D5874E45FBA0@cisco.com> References: <201202141455.q1EEt1C04893@ftpeng-update.cisco.com> To: Washam Fan X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org, draft-ietf-v6ops-ra-guard-implementation@tools.ietf.org Subject: Re: [v6ops] new draft: draft-ietf-v6ops-ra-guard-implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 09:22:14 -0000 On Mar 5, 2012, at 6:02 PM, Washam Fan wrote: >> So - you would like to drop all fragmented packets? >=20 > Yes. Because if you forward the first fragment and drop all the > remaining fragments, the receiving node would always receive the first > fragment but no others. Is that considered as an attack? it is in IPv4 networks, and this disables a defined end-to-end IPv6 = service. I think you would get comments from 6man...= From fred@cisco.com Mon Mar 5 06:55:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B809221F8549 for ; Mon, 5 Mar 2012 06:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.799 X-Spam-Level: X-Spam-Status: No, score=-109.799 tagged_above=-999 required=5 tests=[AWL=0.800, 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 QgKcRUEVzDZM for ; Mon, 5 Mar 2012 06:55:01 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id B370B21F853C for ; Mon, 5 Mar 2012 06:55:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=130; q=dns/txt; s=iport; t=1330959301; x=1332168901; h=date:from:message-id:to:subject:cc; bh=VZgJHp9oxcAzI0zBCaUfmmD1gZrw9/OlCclkZZiXdwE=; b=VPgzuakbNl+rDHzv/rh9wx9tBCCvegk10j2qySXdAgRG0G9KCRW9qhif tzQi4KuYSLrDuP+Zt44YzUmVf3aELl12VENl+e+cxIfH5uvaHFTN++Gzx U+aiTxMkuygDtjmF8jM8BUpVyS/3Bo36bfbX12iPaGuQRoF6iSJK3E0Hc 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4IACfTVE+rRDoG/2dsb2JhbABDoy8BkSqBB4IWAWY8LYEKh2QMmRMBnlSNO4MiBIhQnQCDBA X-IronPort-AV: E=Sophos;i="4.73,534,1325462400"; d="scan'208";a="34559370" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 05 Mar 2012 14:55:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q25Et1Qc020949; Mon, 5 Mar 2012 14:55:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id q25Et1V04869; Mon, 5 Mar 2012 06:55:01 -0800 (PST) Date: Mon, 5 Mar 2012 06:55:01 -0800 (PST) From: Message-Id: <201203051455.q25Et1V04869@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-ma-v6ops-terminal-test@tools.ietf.org Subject: [v6ops] new draft: draft-ma-v6ops-terminal-test X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 14:55:02 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ma-v6ops-terminal-test. Please take a look at it and comment. From iesg-secretary@ietf.org Mon Mar 5 09:22:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A98A21F8767; Mon, 5 Mar 2012 09:22:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 hQg-yJloVD0v; Mon, 5 Mar 2012 09:22:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28EA21F8787; Mon, 5 Mar 2012 09:22:26 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120305172226.508.98908.idtracker@ietfa.amsl.com> Date: Mon, 05 Mar 2012 09:22:26 -0800 Cc: v6ops mailing list , v6ops chair , RFC Editor Subject: [v6ops] Document Action: 'Operational Neighbor Discovery Problems' to Informational RFC (draft-ietf-v6ops-v6nd-problems-04.txt) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 17:22:27 -0000 The IESG has approved the following document: - 'Operational Neighbor Discovery Problems' (draft-ietf-v6ops-v6nd-problems-04.txt) as an Informational RFC This document is the product of the IPv6 Operations Working Group. The IESG contact persons are Ronald Bonica and Dan Romascanu. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6nd-problems/ Technical Summary In IPv4, subnets are generally small, made just large enough to cover the actual number of machines on the subnet. In contrast, the default IPv6 subnet size is a /64, a number so large it covers trillions of addresses, the overwhelming number of which will be unassigned. Consequently, simplistic implementations of Neighbor Discovery can be vulnerable to deliberate or accidental denial of service, whereby they attempt to perform address resolution for large numbers of unassigned addresses. Such denial of attacks can be launched intentionally (by an attacker), or result from legitimate operational tools or accident conditions. As a result of these vulnerabilities, new devices may not be able to "join" a network, it may be impossible to establish new IPv6 flows, and existing IPv6 transported flows may be interrupted. This document describes the potential for DOS in detail and suggests possible implementation improvements as well as operational mitigation techniques that can in some cases be used to protect against or at least alleviate the impact of such attacks. Working Group Summary The topic was discussed in v6ops, with essentially smooth consensus supporting the document. Document Quality This is a problem statement. As such, one doesn't expect an implementation... Personnel Fred Baker is shepherd. From shemant@cisco.com Mon Mar 5 11:49:48 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFBF521F884E for ; Mon, 5 Mar 2012 11:49:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.995 X-Spam-Level: X-Spam-Status: No, score=-8.995 tagged_above=-999 required=5 tests=[AWL=1.003, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 Fgdt7Aib0Ymo for ; Mon, 5 Mar 2012 11:49:48 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5BD21F87ED for ; Mon, 5 Mar 2012 11:49:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=13508; q=dns/txt; s=iport; t=1330976988; x=1332186588; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=ViSnLT4PMzKl+q4Ow/UCCz/YJ2BanFcIP8a/g4Mm8Hc=; b=iNZhDAniDhWiF21MdfZOnAAB5tcsjGVdrZZDpzocOmwFrE3kfRE3lMYx hAJBaTBVwSY1Joo+EHK1IvdgbZ5UXdSIyYzq+EpuvS9v4wnYq48Ytph4V P0vdWhOiEOgyB0eowPsQH8JPJOjwlI4jTLhJt0FHQMsHINuW+vEkX5ev4 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAE8YVU+rRDoH/2dsb2JhbABDgkWCb6YiAYgUeoEHgX0BAQEEAQEBDwEJBwoDPgsQAgEGAhEEAQELBhcBAgICAQElHwkIAQEEARIIGodkAQuZRgGMZZISj0czYwSIUJ0AgwI X-IronPort-AV: E=Sophos;i="4.73,535,1325462400"; d="scan'208,217";a="34499219" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 05 Mar 2012 19:49:47 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q25JnlpF000971; Mon, 5 Mar 2012 19:49:47 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Mar 2012 13:49:47 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCFB09.1E650518" Date: Mon, 5 Mar 2012 13:49:42 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30426476E@XMB-RCD-109.cisco.com> In-Reply-To: <5E8BCCE6-E48A-4D67-BB4C-3CD7AD029BAD@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6204bis and WAN disappearing Thread-Index: AczxSH/llDecLU9WSvehuGkrVOMgcwJwGcTQ References: <021601ccf0f3$812952f0$837bf8d0$@com><4F44A67D.2070203@redpill-linpro.com> <5E8BCCE6-E48A-4D67-BB4C-3CD7AD029BAD@cisco.com> From: "Hemant Singh (shemant)" To: "Rajiv Asati (rajiva)" , "Tore Anderson" X-OriginalArrivalTime: 05 Mar 2012 19:49:47.0389 (UTC) FILETIME=[1E9E9AD0:01CCFB09] Cc: v6ops@ietf.org, draft-ietf-v6ops-6204bis@tools.ietf.org Subject: Re: [v6ops] 6204bis and WAN disappearing X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 19:49:48 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFB09.1E650518 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmFqaXYgYW5kIERhbiwNCg0KIA0KDQpUaGFua3MuICBIZXJlIGlzIHRoZSBuZXcgRy0zLg0KDQog DQoNCkctMzogIFRoZSBJUHY2IENFIHJvdXRlciBNVVNUIE5PVCBmb3J3YXJkIGFueSBJUHY2IHRy YWZmaWMgYmV0d2Vlbg0KDQogICAgICAgICBpdHMgTEFOIGludGVyZmFjZShzKSBhbmQgaXRzIFdB TiBpbnRlcmZhY2UgdW50aWwgdGhlIHJvdXRlciBoYXMNCg0KICAgICAgICAgc3VjY2Vzc2Z1bGx5 IGNvbXBsZXRlZCB0aGUgSVB2NiBhZGRyZXNzIGFuZCB0aGUgZGVsZWdhdGVkDQoNCiAgICAgICAg IHByZWZpeCBhY3F1aXNpdGlvbiBwcm9jZXNzLg0KDQogDQoNCkhlbWFudA0KDQogDQoNCkZyb206 IHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgUmFqaXYgQXNhdGkgKHJhaml2YSkNClNlbnQ6IFdlZG5lc2RheSwgRmVicnVh cnkgMjIsIDIwMTIgNDo1OCBBTQ0KVG86IFRvcmUgQW5kZXJzb24NCkNjOiB2Nm9wc0BpZXRmLm9y ZzsgZHJhZnQtaWV0Zi12Nm9wcy02MjA0YmlzQHRvb2xzLmlldGYub3JnDQpTdWJqZWN0OiBSZTog W3Y2b3BzXSA2MjA0YmlzIGFuZCBXQU4gZGlzYXBwZWFyaW5nDQoNCiANCg0KSSBhZ3JlZS4gU2Vw YXJhdGVseSwgc2hvdWxkbid0IEczIGFsc28gc2F5IHByZWZpeCBhY3F1aXNpdGlvbiA/DQoNCiAN Cg0KICBHLTM6IFRoZSBJUHY2IENFIHJvdXRlciBNVVNUIE5PVCBmb3J3YXJkIGFueSBJUHY2IHRy YWZmaWMgYmV0d2VlbiBpdHMgTEFOIGludGVyZmFjZShzKSBhbmQgaXRzIFdBTiBpbnRlcmZhY2Ug dW50aWwgdGhlIHJvdXRlciBoYXMgc3VjY2Vzc2Z1bGx5IGNvbXBsZXRlZCB0aGUgSVB2NiBhZGRy ZXNzIGFjcXVpc2l0aW9uIHByb2Nlc3MuDQoNCiANCg0KDQpDaGVlcnMsDQoNClJhaml2DQoNCiAN Cg0KU2VudCBmcm9tIG15IFBob25lDQoNCg0KT24gRmViIDIyLCAyMDEyLCBhdCAzOjI1IEFNLCAi VG9yZSBBbmRlcnNvbiIgPHRvcmUuYW5kZXJzb25AcmVkcGlsbC1saW5wcm8uY29tPiB3cm90ZToN Cg0KCSogRGFuIFdpbmcNCgkNCgkNCgkNCg0KCVJlYWRpbmcgZHJhZnQtaWV0Zi12Nm9wcy02MjA0 YmlzLTA1LCBJIGNvdWxkbid0IGRldGVybWluZSB3aGF0IHRoZSBDRSByb3V0ZXINCg0KCQlzaG91 bGQgZG8gaWYsIGFmdGVyIGl0IGFjcXVpcmVzIGFuIElQdjYgcHJlZml4IGZyb20gaXRzIFdBTiBp bnRlcmZhY2UsIHRoZQ0KDQoJCVdBTiBpbnRlcmZhY2UgbGF0ZXIgZ29lcyBkb3duLiAgUmVxdWly ZW1lbnQgRy00IGluIHRoZSBzcGVjaWZpY2F0aW9uDQoNCgkJKGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtdjZvcHMtNjIwNGJpcy0wNSNzZWN0aW9uLTQuMSkNCg0KCQlyZXF1 aXJlcyB0aGUgQ0Ugcm91dGVyIChpbW1lZGlhdGVseT8pIHdpdGhkcmF3IHRoZSBwcmVmaXggb24g dGhlIExBTg0KDQoJCWludGVyZmFjZQ0KDQoJDQoJRGFuLA0KCQ0KCVRoYXQncyBub3Qgd2hhdCBH LTQgKG9yIEctNSkgc2F5cy4gSXQgc2F5cyB0aGF0IGlmIHRoZSBDRSByb3V0ZXIgbG9zZXMNCglp dHMgV0FOIGludGVyZmFjZSAob3IgZGVmYXVsdCByb3V0ZSBvbiBhIHN0aWxsLWVuYWJsZWQgV0FO IGludGVyZmFjZSBmb3INCgl0aGF0IG1hdHRlciksIGl0IG5lZWRzIHRvIHdpdGhkcmF3IGl0c2Vs ZiBhcyBhICpkZWZhdWx0IHJvdXRlciogZm9yIHRoZQ0KCW5vZGVzIGNvbm5lY3RlZCB0byB0aGUg TEFOLg0KCQ0KCUl0IGRvZXMgKm5vdCogc2F5IGFueXRoaW5nIGFib3V0IHRoZSBwcmVmaXhlcy9h ZGRyZXNzZXMgYWR2ZXJ0aXNlZCB0bw0KCXRoZSBMQU4gLSB0aGV5IHNob3VsZCBub3QgYmUgaW1w YWN0ZWQgYnkgdGhlIFdBTiBpbnRlcmZhY2UgZ29pbmcgZG93biwNCglleGNlcHQgZm9yIHRoZSBm YWN0IHRoYXQgdGhlIHRoZSBESENQdjYtUEQgbGVhc2UgY2Fubm90IGJlIHJlbmV3ZWQsDQoJd2hp Y2ggbWVhbnMgdGhhdCB0aGUgbGlmZXRpbWVzIG9mIHRoZSBsZWFzZSBhbmQgdGhlIGFkZHJlc3Nl cyB0aGVtc2VsdmVzDQoJd2lsbCBldmVudHVhbGx5IHJlYWNoIHplcm8uDQoJDQoJLS0gDQoJVG9y ZSBBbmRlcnNvbg0KCVJlZHBpbGwgTGlucHJvIEFTIC0gaHR0cDovL3d3dy5yZWRwaWxsLWxpbnBy by5jb20NCglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K CXY2b3BzIG1haWxpbmcgbGlzdA0KCXY2b3BzQGlldGYub3JnDQoJaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcw0KDQo= ------_=_NextPart_001_01CCFB09.1E650518 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUaW1lczsNCglwYW5vc2UtMToyIDIgNiAz IDUgNCA1IDIgMyA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGku TXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl ZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5hcHBsZS1zdHls ZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uSFRNTFByZWZvcm1h dHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQi Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPjwvaGVhZD48 Ym9keSBiZ2NvbG9yPXdoaXRlIGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2 IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz5SYWpp diBhbmQgRGFuLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjoj MUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29s b3I6IzFGNDk3RCc+VGhhbmtzLsKgIEhlcmUgaXMgdGhlIG5ldyBHLTMuPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+Ry0zOsKgIFRoZSBJUHY2IENFIHJvdXRlciBN VVNUIE5PVCBmb3J3YXJkIGFueSBJUHY2IHRyYWZmaWMgYmV0d2VlbjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+wqDCoMKgwqDCoMKgwqDCoCBpdHMgTEFOIGludGVyZmFj ZShzKSBhbmQgaXRzIFdBTiBpbnRlcmZhY2UgdW50aWwgdGhlIHJvdXRlciBoYXM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyInPsKgwqDCoMKgwqDCoMKgwqAgc3VjY2Vzc2Z1 bGx5IGNvbXBsZXRlZCB0aGUgSVB2NiBhZGRyZXNzIGFuZCB0aGUgZGVsZWdhdGVkPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciJz7CoMKgwqDCoMKgwqDCoMKgIHByZWZpeCBh Y3F1aXNpdGlvbiBwcm9jZXNzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Iic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOiMx RjQ5N0QnPkhlbWFudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2 IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhv bWEiLCJzYW5zLXNlcmlmIic+IHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzp2Nm9wcy1i b3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPlJhaml2IEFzYXRpIChyYWppdmEp PGJyPjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDIyLCAyMDEyIDQ6NTggQU08YnI+ PGI+VG86PC9iPiBUb3JlIEFuZGVyc29uPGJyPjxiPkNjOjwvYj4gdjZvcHNAaWV0Zi5vcmc7IGRy YWZ0LWlldGYtdjZvcHMtNjIwNGJpc0B0b29scy5pZXRmLm9yZzxicj48Yj5TdWJqZWN0OjwvYj4g UmU6IFt2Nm9wc10gNjIwNGJpcyBhbmQgV0FOIGRpc2FwcGVhcmluZzxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SSBhZ3JlZS4gU2VwYXJhdGVseSwgc2hvdWxkbid0IEcz IGFsc28gc2F5IHByZWZpeCBhY3F1aXNpdGlvbiA/PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+Jm5ic3A7IEctMzogVGhlIElQdjYgQ0Ugcm91dGVyIE1VU1QgTk9UIGZvcndh cmQgYW55IElQdjYgdHJhZmZpYyBiZXR3ZWVuJm5ic3A7PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUt c3Bhbj5pdHMgTEFOIGludGVyZmFjZShzKSBhbmQgaXRzIFdBTiBpbnRlcmZhY2UgdW50aWwgdGhl IHJvdXRlciBoYXMgc3VjY2Vzc2Z1bGx5IGNvbXBsZXRlZCB0aGUgSVB2NiBhZGRyZXNzIGFjcXVp c2l0aW9uIHByb2Nlc3MuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiJUaW1lcyIsInNl cmlmIic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48YnI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlJhaml2 PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+U2VudCBmcm9tIG15IFBob25l PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9 J21hcmdpbi1ib3R0b206MTIuMHB0Jz48YnI+T24gRmViIDIyLCAyMDEyLCBhdCAzOjI1IEFNLCAm cXVvdDtUb3JlIEFuZGVyc29uJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86dG9yZS5hbmRlcnNv bkByZWRwaWxsLWxpbnByby5jb20iPnRvcmUuYW5kZXJzb25AcmVkcGlsbC1saW5wcm8uY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ KiBEYW4gV2luZzxicj48YnI+PGJyPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5S ZWFkaW5nIGRyYWZ0LWlldGYtdjZvcHMtNjIwNGJpcy0wNSwgSSBjb3VsZG4ndCBkZXRlcm1pbmUg d2hhdCB0aGUgQ0Ugcm91dGVyPG86cD48L286cD48L3A+PGJsb2NrcXVvdGUgc3R5bGU9J21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+PHAgY2xhc3M9TXNvTm9ybWFsPnNob3Vs ZCBkbyBpZiwgYWZ0ZXIgaXQgYWNxdWlyZXMgYW4gSVB2NiBwcmVmaXggZnJvbSBpdHMgV0FOIGlu dGVyZmFjZSwgdGhlPG86cD48L286cD48L3A+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHN0eWxl PSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxwIGNsYXNzPU1zb05vcm1h bD5XQU4gaW50ZXJmYWNlIGxhdGVyIGdvZXMgZG93bi4gJm5ic3A7UmVxdWlyZW1lbnQgRy00IGlu IHRoZSBzcGVjaWZpY2F0aW9uPG86cD48L286cD48L3A+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3Rl IHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPjxwIGNsYXNzPU1z b05vcm1hbD4oPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi12 Nm9wcy02MjA0YmlzLTA1I3NlY3Rpb24tNC4xIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLXY2b3BzLTYyMDRiaXMtMDUjc2VjdGlvbi00LjE8L2E+KTxvOnA+PC9vOnA+PC9w PjwvYmxvY2txdW90ZT48YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Jz48cCBjbGFzcz1Nc29Ob3JtYWw+cmVxdWlyZXMgdGhlIENFIHJvdXRlciAo aW1tZWRpYXRlbHk/KSB3aXRoZHJhdyB0aGUgcHJlZml4IG9uIHRoZSBMQU48bzpwPjwvbzpwPjwv cD48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCc+PHAgY2xhc3M9TXNvTm9ybWFsPmludGVyZmFjZTxvOnA+PC9vOnA+PC9w PjwvYmxvY2txdW90ZT48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPkRhbiw8YnI+PGJyPlRoYXQncyBu b3Qgd2hhdCBHLTQgKG9yIEctNSkgc2F5cy4gSXQgc2F5cyB0aGF0IGlmIHRoZSBDRSByb3V0ZXIg bG9zZXM8YnI+aXRzIFdBTiBpbnRlcmZhY2UgKG9yIGRlZmF1bHQgcm91dGUgb24gYSBzdGlsbC1l bmFibGVkIFdBTiBpbnRlcmZhY2UgZm9yPGJyPnRoYXQgbWF0dGVyKSwgaXQgbmVlZHMgdG8gd2l0 aGRyYXcgaXRzZWxmIGFzIGEgKmRlZmF1bHQgcm91dGVyKiBmb3IgdGhlPGJyPm5vZGVzIGNvbm5l Y3RlZCB0byB0aGUgTEFOLjxicj48YnI+SXQgZG9lcyAqbm90KiBzYXkgYW55dGhpbmcgYWJvdXQg dGhlIHByZWZpeGVzL2FkZHJlc3NlcyBhZHZlcnRpc2VkIHRvPGJyPnRoZSBMQU4gLSB0aGV5IHNo b3VsZCBub3QgYmUgaW1wYWN0ZWQgYnkgdGhlIFdBTiBpbnRlcmZhY2UgZ29pbmcgZG93biw8YnI+ ZXhjZXB0IGZvciB0aGUgZmFjdCB0aGF0IHRoZSB0aGUgREhDUHY2LVBEIGxlYXNlIGNhbm5vdCBi ZSByZW5ld2VkLDxicj53aGljaCBtZWFucyB0aGF0IHRoZSBsaWZldGltZXMgb2YgdGhlIGxlYXNl IGFuZCB0aGUgYWRkcmVzc2VzIHRoZW1zZWx2ZXM8YnI+d2lsbCBldmVudHVhbGx5IHJlYWNoIHpl cm8uPGJyPjxicj4tLSA8YnI+VG9yZSBBbmRlcnNvbjxicj5SZWRwaWxsIExpbnBybyBBUyAtIDxh IGhyZWY9Imh0dHA6Ly93d3cucmVkcGlsbC1saW5wcm8uY29tIj5odHRwOi8vd3d3LnJlZHBpbGwt bGlucHJvLmNvbTwvYT48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+djZvcHMgbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzp2Nm9wc0Bp ZXRmLm9yZyI+djZvcHNAaWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdjZvcHM8L2E+PG86cD48L286cD48L3A+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2 PjwvYm9keT48L2h0bWw+ ------_=_NextPart_001_01CCFB09.1E650518-- From brian.e.carpenter@gmail.com Mon Mar 5 12:47:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9AF21F881D for ; Mon, 5 Mar 2012 12:47:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.133 X-Spam-Level: X-Spam-Status: No, score=-103.133 tagged_above=-999 required=5 tests=[AWL=-0.134, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, 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 sctCtzTuv7Zm for ; Mon, 5 Mar 2012 12:47:09 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED9321F8817 for ; Mon, 5 Mar 2012 12:47:09 -0800 (PST) Received: by iazz13 with SMTP id z13so7055567iaz.31 for ; Mon, 05 Mar 2012 12:47:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=YqVWdZY4B5FCa4JbmC5EavpD6FmfZxMQbRmtrYFbKrQ=; b=q9W5c5TLz+d5mlLJR9DQ+rcDWJ8ZZKdAv8p1885Ykw4QdWNDlsO6AXLk0ZOZlf6xBy Hm4nA1CDM7lN5Ccm/0TYqf3Y40TwsKoPi4L5DrkrGvZSJb6/B8U+8FqGvJlzSRQDFUdh j4B7eakPqCvUpaS1LhYzAi7qVdGXA0iVC/+hEeyG99R/WIY3rb8A5yp7sLKwzZ50hKl+ AY5IMsrhWUfOdJpfVKhWMgbKfwlqoxy7UwPvzOS95KLEHd9WXdTmgQMT5BbTs6i6iFHU jNHtKD24Gsl7e8clHpt+xinbgVIk0oglrdf0jq7lBVulX2PsC9ZPGPaJi1bNefWYTcew iqvQ== Received: by 10.50.217.163 with SMTP id oz3mr6903136igc.6.1330980429275; Mon, 05 Mar 2012 12:47:09 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id vr4sm19608020igb.1.2012.03.05.12.47.06 (version=SSLv3 cipher=OTHER); Mon, 05 Mar 2012 12:47:08 -0800 (PST) Message-ID: <4F552645.2010003@gmail.com> Date: Tue, 06 Mar 2012 09:47:01 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: John Mann References: <4F45B554.2060103@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action: draft-carpenter-v6ops-icp-guidance-03.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 20:47:10 -0000 Hi John, thanks for the review, On 2012-03-05 17:23, John Mann wrote: > Hi, > > --- > > An important first step in every strategy is to determine from every > hardware and software supplier details of their planned dates for > providing full IPv6 support, with performance equivalent to IPv4, in > their products and services. > --- > I disagree with this being a _first_ step. Personally I disagree, but it's certainly a debatable point and I'd like to hear from other people. My experience with IT managers is that they hate surprises, and discovering late in the game that a key component doesn't work is the worst kind of surprise. > Asking _every_ hardware and software supplier can take a lot of time and effort, > and can lead to ICP in-action e.g. if some suppliers are not ready. Correct. I would certainly modify the statement to refer specifically to determining critical path items - but your exact deployment plan might change according to which components will be available when. > > Also, "full IPv6 support" can be hard to specify and evaluate -- do > you mean comply with all RFCs, > pass specific certification tests, or just the specific list of > features that you use with IPv4? That is very variable. Enterprises labouring under some stupid set of auditable requirements might have to be very strict; others might be very pragmatic. Either way, the criterion is functionality needed for IPv6, not an IPv4-driven feature list. I agree that this should be more carefully phrased. > > My alternate view is > > a) Make a policy decision to avoid the creation of any new > customer-facing networks or services that are IPv4-only > b) Enable IPv6 on what you already have, with perhaps some tactical > expenditure to: > i) get some IPv6 traffic flowing What traffic? There won't be any revenue-generating traffic unless you make the user-facing service support IPv6. > > ii) start work on the sections described below e.g. external > connectivity, address plan, training, operations, and security. > iii) get the first IPv6 service operational > c) Build on the experience and success of the first service to plan > and justify subsequent IPv6 steps. That's not very different from what the draft proposes. > > d) Triage your hardware and software > i) legacy internal IPv4-only systems that don't ever need to support IPv6 > ii) systems that can already support IPv6 > iii) systems due to be replaced soon -- by systems that will > support IPv6 (see (a) above) > > iv) systems that will require extra effort or expenditure to get IPv6 support > v) problem systems -- e.g. none of the possible suppliers have an > IPv6 roadmap. You should certainly do all that; I don't understand how it can be done at the end. > > ==== > > I think some mention could be made in > > 5.2. Routing > that running dual-stack could require twice the routing table space > and forwarding TCAM in the routers Well, more space, indeed. > > And in > 13. Security Considerations > that running dual-stack could require twice the amount of permission > lists, ACLs, TCAMs etc. Yes, which is why a lot of people want feature-equivalence, so that they only have to maintain a single config to drive both protocols. > The growth in table size hopefully won't be 5 times (32 bits to 32 + 128 bits), > due to most IPv6 routing only going down to /64s, fewer IPv6 routes, > shorter history of IPv6 exceptions, etc. Agreed Brian > > Thanks, > John > > On 23 February 2012 14:41, Brian E Carpenter wrote: > >> Hi, >> >> This version has various updates due to comments from the WG. >> >> We are not asking for a meeting slot in Paris, but we'd like the >> chairs to put the question whether the WG wants to adopt this >> draft. In any case we still want more input to correct and >> expand the draft. >> >> Brian + Sheng >> >> -------- Original Message -------- >> Subject: I-D Action: draft-carpenter-v6ops-icp-guidance-03.txt >> Date: Wed, 22 Feb 2012 14:30:09 -0800 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> >> Title : IPv6 Guidance for Internet Content and >> Application Service Providers >> Author(s) : Brian Carpenter >> Sheng Jiang >> Filename : draft-carpenter-v6ops-icp-guidance-03.txt >> Pages : 18 >> Date : 2012-02-22 >> >> This document provides guidance and suggestions for Internet >> Content >> Providers and Application Service Providers who wish to offer >> their >> service to both IPv6 and IPv4 customers. Many of the points will >> also apply to any enterprise network preparing for IPv6 users. >> >> >> A URL for this Internet-Draft is: >> >> http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance-03.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> >> ftp://ftp.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance-03.txt >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draftdirectories: >> http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > From gvandeve@cisco.com Mon Mar 5 13:51:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2390E21F8790 for ; Mon, 5 Mar 2012 13:51:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.229 X-Spam-Level: X-Spam-Status: No, score=-10.229 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 DMPuYjYdcgk7 for ; Mon, 5 Mar 2012 13:51:30 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id C392521F8794 for ; Mon, 5 Mar 2012 13:51:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=333; q=dns/txt; s=iport; t=1330984289; x=1332193889; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=DxJDJ/L71hw+pgoc2bvugoNXbZT0RXP+h0N+fAzC8IE=; b=DwGkzBWBGkLOtxftDyS03q3Z6Lp0IO4PCXKEU5uyehULj4uyqGZS05Vm Zhnl3oXPi9gFrAGjQIWGcct/Xxr//87UmpfCkf5/y7MRydfJgfsO9msT1 EqAMMGaDmgbXz/kgQYc455HZviaSM8+1fWT63pwYumvJ/f3Hi7SnDnZgj o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EADE1VU+Q/khM/2dsb2JhbABDtGeBB4F/AQQSAR0KUQEqBhgHVwEEGxqHZZg6gScBnnGPbGMEpVCCZA X-IronPort-AV: E=Sophos;i="4.73,536,1325462400"; d="scan'208";a="67734471" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 05 Mar 2012 21:51:28 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q25LpSJ4012291 for ; Mon, 5 Mar 2012 21:51:28 GMT Received: from xmb-ams-102.cisco.com ([144.254.74.77]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 5 Mar 2012 22:51:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: ANWZ BCgb BlFJ B/46 CO6d ECxA Evf6 FmQ9 Fp4S Ghnn IDs4 IMv1 JHEC JrHg J4+B J7AG; 1; dgA2AG8AcABzAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {B52736E6-3B62-43A7-83D2-ED4DB1E79C08}; ZwB2AGEAbgBkAGUAdgBlAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Mon, 05 Mar 2012 21:51:25 GMT; UwBvAG0AZQAgAG4AZQB3ACAASQBQAHYANgAgAHIAZQBsAGEAdABlAGQAIABkAHIAYQBmAHQAcwAgAHIAZQBsAGEAdABlAGQAIAB0AG8AIABJAFAAdgA2ACAAdABoAGEAdAAgAGgAYQB2AGUAIABqAHUAcwB0ACAAYgBlAGUAbgAgAHMAdQBiAG0AaQB0AHQAZQBkACAAdABvACAAdABoAGUAIABPAFAAUwBFAEMAIABXAEcA MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {B52736E6-3B62-43A7-83D2-ED4DB1E79C08} Content-class: urn:content-classes:message Date: Mon, 5 Mar 2012 22:51:25 +0100 Message-ID: <5C99EC8C99D9BB45AC51D20DC2AD2DC50705C91E@XMB-AMS-102.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Some new IPv6 related drafts related to IPv6 that have just been submitted to the OPSEC WG Thread-Index: Acz7GhyGqBPd0Y8sT+6RragQaRItnw== From: "Gunter Van de Velde (gvandeve)" To: "v6ops v6ops WG" X-OriginalArrivalTime: 05 Mar 2012 21:51:28.0708 (UTC) FILETIME=[1E8B7840:01CCFB1A] Subject: [v6ops] Some new IPv6 related drafts related to IPv6 that have just been submitted to the OPSEC WG X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 21:51:31 -0000 Hi All, Some new drafts submitted at OPSEC WG have quite some IPv6 related elements. Additional review from the v6ops crew could be useful. draft-baker-opsec-passive-ip-address-00 draft-yourtchenko-opsec-humansafe-ipv6 draft-jdurand-bgp-security-00.txt draft-vyncke-opsec-v6 draft-behringer-lla-only Greetings, G/ From john.mann@monash.edu Mon Mar 5 14:32:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0CA421E8057 for ; Mon, 5 Mar 2012 14:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.376 X-Spam-Level: X-Spam-Status: No, score=-5.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 bhEP-MOWo+hL for ; Mon, 5 Mar 2012 14:32:23 -0800 (PST) Received: from na3sys009aog125.obsmtp.com (na3sys009aog125.obsmtp.com [74.125.149.153]) by ietfa.amsl.com (Postfix) with ESMTP id CEE2F21E804E for ; Mon, 5 Mar 2012 14:32:22 -0800 (PST) Received: from mail-gy0-f169.google.com ([209.85.160.169]) (using TLSv1) by na3sys009aob125.postini.com ([74.125.148.12]) with SMTP ID DSNKT1U+9ouAfaPNJ3eNTLNavxql9z9Ifqww@postini.com; Mon, 05 Mar 2012 14:32:22 PST Received: by mail-gy0-f169.google.com with SMTP id r18so2033621ghr.28 for ; Mon, 05 Mar 2012 14:32:22 -0800 (PST) Received-SPF: pass (google.com: domain of john.mann@monash.edu designates 10.60.29.10 as permitted sender) client-ip=10.60.29.10; Authentication-Results: mr.google.com; spf=pass (google.com: domain of john.mann@monash.edu designates 10.60.29.10 as permitted sender) smtp.mail=john.mann@monash.edu Received: from mr.google.com ([10.60.29.10]) by 10.60.29.10 with SMTP id f10mr3241636oeh.32.1330986742245 (num_hops = 1); Mon, 05 Mar 2012 14:32:22 -0800 (PST) Received: by 10.60.29.10 with SMTP id f10mr2871957oeh.32.1330986742171; Mon, 05 Mar 2012 14:32:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.154.39 with HTTP; Mon, 5 Mar 2012 14:32:02 -0800 (PST) In-Reply-To: <4F552645.2010003@gmail.com> References: <4F45B554.2060103@gmail.com> <4F552645.2010003@gmail.com> From: John Mann Date: Tue, 6 Mar 2012 09:32:02 +1100 Message-ID: To: Brian E Carpenter Content-Type: multipart/alternative; boundary=e89a8ff1c89af7c98004ba867f46 X-Gm-Message-State: ALoCoQlssTetJHPOCgpFRt4VoL88aiJ5WQLn+KNBVeqRmZAwZWtolvgt8y7mRs29uEljvbySRjKE Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action: draft-carpenter-v6ops-icp-guidance-03.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 22:32:24 -0000 --e89a8ff1c89af7c98004ba867f46 Content-Type: text/plain; charset=ISO-8859-1 Hi, On 6 March 2012 07:47, Brian E Carpenter wrote: > Hi John, thanks for the review, > > On 2012-03-05 17:23, John Mann wrote: > > Hi, > > > > --- > > > > An important first step in every strategy is to determine from every > > hardware and software supplier details of their planned dates for > > providing full IPv6 support, with performance equivalent to IPv4, in > > their products and services. > > --- > > I disagree with this being a _first_ step. > > Personally I disagree, but it's certainly a debatable point and I'd > like to hear from other people. My experience with IT managers is that > they hate surprises, and discovering late in the game that a key component > doesn't work is the worst kind of surprise. Yes, late surprises are bad. My view is to start trying to use IPv6 as early as possible so that you can discover early the things that don't work (the way you expected them to). IPv6 is different enough that there will be things that you know you need to plan for, and other things that you *don't know* that you have to deal with until after you have completed the previous steps. > Asking _every_ hardware and software supplier can take a lot of time and > effort, > > and can lead to ICP in-action e.g. if some suppliers are not ready. > > Correct. I would certainly modify the statement to refer specifically to > determining critical path items - but your exact deployment plan might > change according to which components will be available when. May I suggest -- several deployment phases, each of which will have critical path items that will need IPv6 support. > Also, "full IPv6 support" can be hard to specify and evaluate -- do > > you mean comply with all RFCs, > > pass specific certification tests, or just the specific list of > > features that you use with IPv4? > > That is very variable. Enterprises labouring under some stupid set of > auditable requirements might have to be very strict; others might be > very pragmatic. Either way, the criterion is functionality needed > for IPv6, not an IPv4-driven feature list. I agree that this should > be more carefully phrased. > > > > > My alternate view is > > > > a) Make a policy decision to avoid the creation of any new > > customer-facing networks or services that are IPv4-only > > b) Enable IPv6 on what you already have, with perhaps some tactical > > expenditure to: > > i) get some IPv6 traffic flowing > > What traffic? There won't be any revenue-generating traffic unless > you make the user-facing service support IPv6. Sorry, I wasn't implying revenue-generating user-facing IPv6 traffic. I just meant _some_ IPv6 traffic -- preferably communicating with the IPv6 Internet. It could be as simple as dual-stacking a test FTP server in the DMZ. Or IPv6-enabling a test user subnet. It doesn't matter if it is only 100 packets per day! My point was that once you have _some_ IPv6 traffic, it enables the following steps. IPv6 has become tangible, it is no longer hypothetical. Getting the first bit of IPv6 working can also dispel FUD. It shows that adding IPv6 doesn't cause the world to end, that IPv4 and IPv6 are ships-in-the-night protocols. > ii) start work on the sections described below e.g. external > > connectivity, address plan, training, operations, and security. > > iii) get the first IPv6 service operational > > c) Build on the experience and success of the first service to plan > > and justify subsequent IPv6 steps. > > That's not very different from what the draft proposes. Agreed. > > d) Triage your hardware and software > > i) legacy internal IPv4-only systems that don't ever need to support > IPv6 > > ii) systems that can already support IPv6 > > iii) systems due to be replaced soon -- by systems that will > > support IPv6 (see (a) above) > > > > iv) systems that will require extra effort or expenditure to get IPv6 > support > > v) problem systems -- e.g. none of the possible suppliers have an > > IPv6 roadmap. > > You should certainly do all that; I don't understand how it can be done at > the end. > > > > > ==== > > > > I think some mention could be made in > > > > 5.2. Routing > > that running dual-stack could require twice the routing table space > > and forwarding TCAM in the routers > > Well, more space, indeed. > > > > > And in > > 13. Security Considerations > > that running dual-stack could require twice the amount of permission > > lists, ACLs, TCAMs etc. > > Yes, which is why a lot of people want feature-equivalence, so that > they only have to maintain a single config to drive both protocols. > > > The growth in table size hopefully won't be 5 times (32 bits to 32 + 128 > bits), > > due to most IPv6 routing only going down to /64s, fewer IPv6 routes, > > shorter history of IPv6 exceptions, etc. > > Agreed > Another issue is mentioned in several places in the draft, but I didn't see it pulled together in one spot: For tactical reasons it may be necessary to use different infrastructure to support IPv6 than IPv4, but there are major advantages in simplicity and maintainability if shared common infrastructure can be used for ISP links, routers, firewalls, load balancers, web servers, network monitoring, security management, IPAM etc John Brian > > > > > Thanks, > > John > > > > On 23 February 2012 14:41, Brian E Carpenter < > brian.e.carpenter@gmail.com>wrote: > > > >> Hi, > >> > >> This version has various updates due to comments from the WG. > >> > >> We are not asking for a meeting slot in Paris, but we'd like the > >> chairs to put the question whether the WG wants to adopt this > >> draft. In any case we still want more input to correct and > >> expand the draft. > >> > >> Brian + Sheng > >> > >> -------- Original Message -------- > >> Subject: I-D Action: draft-carpenter-v6ops-icp-guidance-03.txt > >> Date: Wed, 22 Feb 2012 14:30:09 -0800 > >> From: internet-drafts@ietf.org > >> Reply-To: internet-drafts@ietf.org > >> To: i-d-announce@ietf.org > >> > >> > >> A New Internet-Draft is available from the on-line > >> Internet-Drafts directories. > >> > >> Title : IPv6 Guidance for Internet Content and > >> Application Service Providers > >> Author(s) : Brian Carpenter > >> Sheng Jiang > >> Filename : draft-carpenter-v6ops-icp-guidance-03.txt > >> Pages : 18 > >> Date : 2012-02-22 > >> > >> This document provides guidance and suggestions for Internet > >> Content > >> Providers and Application Service Providers who wish to offer > >> their > >> service to both IPv6 and IPv4 customers. Many of the points will > >> also apply to any enterprise network preparing for IPv6 users. > >> > >> > >> A URL for this Internet-Draft is: > >> > >> > http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance-03.txt > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> This Internet-Draft can be retrieved at: > >> > >> > ftp://ftp.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance-03.txt > >> > >> _______________________________________________ > >> I-D-Announce mailing list > >> I-D-Announce@ietf.org > >> https://www.ietf.org/mailman/listinfo/i-d-announce > >> Internet-Draft< > https://www.ietf.org/mailman/listinfo/i-d-announce%0AInternet-Draft > >directories: > >> http://www.ietf.org/shadow.html > >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >> > > > --e89a8ff1c89af7c98004ba867f46 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

On 6 March 2012 07:47, Brian E Carpen= ter <br= ian.e.carpenter@gmail.com> wrote:
Hi John, thanks for the review,

On 2012-03-05 17:23, John Mann wrote:
> Hi,
>
> ---
>
> =A0 =A0An important first step in every strategy is to determine from = every
> =A0 =A0hardware and software supplier details of their planned dates f= or
> =A0 =A0providing full IPv6 support, with performance equivalent to IPv= 4, in
> =A0 =A0their products and services.
> ---
> I disagree with this being a _first_ step.

Personally I disagree, but it's certainly a debatable point and I= 'd
like to hear from other people. My experience with IT managers is that
they hate surprises, and discovering late in the game that a key component<= br> doesn't work is the worst kind of surprise.

=
Yes, late surprises are bad.
My view is to start trying to u= se IPv6 as early as possible so that you can discover early the things that= don't work (the way you expected them to).

IPv6 is different enough that there will be things that= you know you need to plan for,
and other things that you *don= 9;t know* that you have to deal with until after you have completed the pre= vious steps.=A0

> Asking _every_ hardware and software supplier can take a lot of time a= nd effort,
> and can lead to ICP in-action e.g. if some suppliers are not ready.
Correct. I would certainly modify the statement to refer specifically= to
determining critical path items - but your exact deployment plan might
change according to which components will be available when.

May I suggest -- several deployment phases, each of which= will have critical path items that will need IPv6 support.

> Also, "full IPv6 support" can be hard to specify and evaluat= e -- do
> you mean comply with all RFCs,
> pass specific certification tests, or just the specific list of
> features that you use with IPv4?

That is very variable. Enterprises labouring under some stupid set of=
auditable requirements might have to be very strict; others might be
very pragmatic. Either way, the criterion is functionality needed
for IPv6, not an IPv4-driven feature list. I agree that this should
be more carefully phrased.

>
> My alternate view is
>
> a) Make a policy decision to avoid the creation of any new
> customer-facing networks or services that are IPv4-only
> b) Enable IPv6 on what you already have, with perhaps some tactical > expenditure to:
> =A0 =A0i) get some IPv6 traffic flowing

What traffic? There won't be any revenue-generating traffic unles= s
you make the user-facing service support IPv6.

<= div>Sorry, I wasn't implying revenue-generating user-facing IPv6 traffi= c.

I just meant _some_ IPv6 traffic -- preferably = communicating with the IPv6 Internet.
It could be as simple as dual-stacking a test FTP server in the DMZ.
Or IPv6-enabling a test user subnet. =A0It doesn't matter if i= t is only 100 packets per day!

My point was that o= nce you have _some_ IPv6 traffic, it enables the following steps.
IPv6 has become tangible, it is no longer hypothetical.

=
Getting the first bit of IPv6 working can also dispel FUD.
=
It shows that adding IPv6 doesn't cause the world to end, that IPv= 4 and IPv6 are ships-in-the-night protocols.

> =A0 =A0ii) start work on the sections described below e.g. external > connectivity, address plan, training, operations, and security.
> =A0 =A0iii) get the first IPv6 service operational
> c) Build on the experience and success of the first service to plan > and justify subsequent IPv6 steps.

That's not very different from what the draft proposes.

Agreed.
=A0
> d) Triage your hardware and software
> =A0 =A0i) legacy internal IPv4-only systems that don't ever need t= o support IPv6
> =A0 =A0ii) systems that can already support IPv6
> =A0 =A0iii) systems due to be replaced soon -- by systems that will > support IPv6 (see (a) above)
>
> =A0 =A0iv) systems that will require extra effort or expenditure to ge= t IPv6 support
> =A0 =A0v) problem systems -- e.g. none of the possible suppliers have = an
> IPv6 roadmap.

You should certainly do all that; I don't understand how it can b= e done at
the end.

>
> =3D=3D=3D=3D
>
> I think some mention could be made in
>
> =A0 =A05.2. Routing
> that running dual-stack could require twice the routing table space > and forwarding TCAM in the routers

Well, more space, indeed.

>
> And in
> =A0 =A013. Security Considerations
> that running dual-stack could require twice the amount of permission > lists, ACLs, TCAMs etc.

Yes, which is why a lot of people want feature-equivalence, so that they only have to maintain a single config to drive both protocols.

> The growth in table size hopefully won't be 5 times (32 bits to 32= + 128 bits),
> due to most IPv6 routing only going down to /64s, fewer IPv6 routes, > shorter history of IPv6 exceptions, etc.

Agreed

Another issue is mentioned= in several places in the draft, but I didn't see it pulled together in= one spot:
For tactical reasons it may be necessary to use differ= ent infrastructure to support IPv6 than IPv4,
but there are major advantages in simplicity and maintainability if sh= ared common infrastructure can be used for
ISP links, routers, fi= rewalls, load balancers, web servers, network monitoring, security manageme= nt, IPAM etc

=A0 =A0 John

=A0 =A0Brian

>
> Thanks,
> =A0 =A0 John
>
> On 23 February 2012 14:41, Brian E Carpenter <brian.e.carpenter@gmail.com>wrote:
>
>> Hi,
>>
>> This version has various updates due to comments from the WG.
>>
>> We are not asking for a meeting slot in Paris, but we'd like t= he
>> chairs to put the question whether the WG wants to adopt this
>> draft. In any case we still want more input to correct and
>> expand the draft.
>>
>> =A0 =A0Brian + Sheng
>>
>> -------- Original Message --------
>> Subject: I-D Action: draft-carpenter-v6ops-icp-guidance-03.txt
>> Date: Wed, 22 Feb 2012 14:30:09 -0800
>> From: internet-drafts@= ietf.org
>> Reply-To: internet-dra= fts@ietf.org
>> To: i-d-announce@ietf.org=
>>
>>
>> A New Internet-Draft is available from the on-line
>> Internet-Drafts directories.
>>
>> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : IPv6 Guidance for Inter= net Content and
>> Application Service Providers
>> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Brian Carpenter
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Sheng Jiang
>> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-carpenter-v6ops-icp= -guidance-03.txt
>> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 18
>> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-02-22
>>
>> =A0 This document provides guidance and suggestions for Internet >> Content
>> =A0 Providers and Application Service Providers who wish to offer<= br> >> their
>> =A0 service to both IPv6 and IPv4 customers. =A0Many of the points= will
>> =A0 also apply to any enterprise network preparing for IPv6 users.=
>>
>>
>> A URL for this Internet-Draft is:
>>
>> http://www.ietf.org/internet-draf= ts/draft-carpenter-v6ops-icp-guidance-03.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> = ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>>
>> ftp://ftp.ietf.org/internet-drafts= /draft-carpenter-v6ops-icp-guidance-03.txt
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org=
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft<https://www.i= etf.org/mailman/listinfo/i-d-announce%0AInternet-Draft>directories:<= br>
>> http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>

--e89a8ff1c89af7c98004ba867f46-- From fgont@si6networks.com Mon Mar 5 18:17:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8567B21E802F for ; Mon, 5 Mar 2012 18:17:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, 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 ed9vF2im5JTy for ; Mon, 5 Mar 2012 18:17:30 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id D494121E8018 for ; Mon, 5 Mar 2012 18:17:29 -0800 (PST) Received: from [2001:5c0:1000:a::91f] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1S4jxq-0004do-Jm; Tue, 06 Mar 2012 03:17:22 +0100 Message-ID: <4F5573AD.7000101@si6networks.com> Date: Mon, 05 Mar 2012 23:17:17 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Washam Fan References: <201202141455.q1EEt1C04893@ftpeng-update.cisco.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, draft-ietf-v6ops-ra-guard-implementation@tools.ietf.org Subject: Re: [v6ops] new draft: draft-ietf-v6ops-ra-guard-implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 02:17:30 -0000 On 03/05/2012 02:15 AM, Washam Fan wrote: > I have a comment on rule#3 in section 3. It seems to me that the first > fragment which can be recognized as non-RA could pass the RA-Guard. Is > that the intent? Yes, of course. -- otherwise we'd be blocking legitimate fragmented traffic. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fgont@si6networks.com Mon Mar 5 18:18:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4268021E805E for ; Mon, 5 Mar 2012 18:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, 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 s7rAvMyEYgiN for ; Mon, 5 Mar 2012 18:18:07 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id B63DF21E8018 for ; Mon, 5 Mar 2012 18:18:07 -0800 (PST) Received: from [2001:5c0:1000:a::91f] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1S4jyV-0004eN-Ff; Tue, 06 Mar 2012 03:18:03 +0100 Message-ID: <4F557028.6030801@si6networks.com> Date: Mon, 05 Mar 2012 23:02:16 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Joel jaeggli References: <20120303200905.31106.67929.idtracker@ietfa.amsl.com> <4F529C37.9090900@bogus.com> <4F52AE79.9020504@si6networks.com> <4F53E2DF.6090904@bogus.com> In-Reply-To: <4F53E2DF.6090904@bogus.com> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IPv6 Ops WG Subject: Re: [v6ops] Fwd: ID Tracker State Update Notice: X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 02:18:08 -0000 Hi, Joel, On 03/04/2012 06:47 PM, Joel jaeggli wrote: > the prefix scanning ease issue is something I would dispute... common > address assignment methods already greatly facilitate subnet and > particularly router discover greatly. this doesn't seem likely to alter > that. But this would make scanning attacks even simpler. If anything, we should move away from predictable addresses, rather than moving *to* predictable addresses. > theres still the opportunity for nit language fixes in auth48 so ew > should consider that. Please note that I made other suggestions other than the one you're referring to above. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From washam.fan@gmail.com Mon Mar 5 19:05:36 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65F8A21F867E for ; Mon, 5 Mar 2012 19:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.479 X-Spam-Level: X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 BJRmYilYII8S for ; Mon, 5 Mar 2012 19:05:35 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 986C021F8668 for ; Mon, 5 Mar 2012 19:05:35 -0800 (PST) Received: by wicr5 with SMTP id r5so2259261wic.31 for ; Mon, 05 Mar 2012 19:05:34 -0800 (PST) Received-SPF: pass (google.com: domain of washam.fan@gmail.com designates 10.216.139.229 as permitted sender) client-ip=10.216.139.229; Authentication-Results: mr.google.com; spf=pass (google.com: domain of washam.fan@gmail.com designates 10.216.139.229 as permitted sender) smtp.mail=washam.fan@gmail.com; dkim=pass header.i=washam.fan@gmail.com Received: from mr.google.com ([10.216.139.229]) by 10.216.139.229 with SMTP id c79mr4177659wej.16.1331003134873 (num_hops = 1); Mon, 05 Mar 2012 19:05:34 -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=9h2gmy6MR6gJ/j1YRz+TOsSlVD2/XSg8LWyV6o7SOwE=; b=UoNVV/LfljLwMFokOTv+f/vLEqsIHkV1/cBwSGWl9+xGU/4YKY3ZGd1T1OeM8JAT4F +f+Devn/ibJHiym2denTdRLNUaijPDmJs0vMU4CxR2vUrjsEOxCSn/Ex2xEbZ/ZISC1B Maqh1qhGtt+SpLgKxBrriwrXFn0EgJ9DIqAf8ZUC4uSMQRxPudWKZuC9vcZUEBJIAyuQ MBjuk4/wF59FOX+TZ7050sFE8PubF9CwzZBBifB7hxyYh8DYj5U8oFy5L+WoRYKP0kXa /ACr6dmzuXsDW6bbulcTJrNARTLXb6lKHLFuSjrk2AzND6bkWQeGVmV8TipqL/Z3yrN/ A8cg== MIME-Version: 1.0 Received: by 10.216.139.229 with SMTP id c79mr3361376wej.16.1331003134755; Mon, 05 Mar 2012 19:05:34 -0800 (PST) Received: by 10.216.205.169 with HTTP; Mon, 5 Mar 2012 19:05:34 -0800 (PST) In-Reply-To: <4F5573AD.7000101@si6networks.com> References: <201202141455.q1EEt1C04893@ftpeng-update.cisco.com> <4F5573AD.7000101@si6networks.com> Date: Tue, 6 Mar 2012 11:05:34 +0800 Message-ID: From: Washam Fan To: Fernando Gont Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org, draft-ietf-v6ops-ra-guard-implementation@tools.ietf.org Subject: Re: [v6ops] new draft: draft-ietf-v6ops-ra-guard-implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 03:05:36 -0000 Hi Fernando, 2012/3/6 Fernando Gont : > On 03/05/2012 02:15 AM, Washam Fan wrote: >> I have a comment on rule#3 in section 3. It seems to me that the first >> fragment which can be recognized as non-RA could pass the RA-Guard. Is >> that the intent? > > Yes, of course. -- otherwise we'd be blocking legitimate fragmented traffic. My point was, you are blocking legitimate traffic eventually. For example, if there is a non-RA datagram split into 2 fragments, you will pass the first fragment because it is recognized as a non-RA. you will block the second fragment because you can not recognize it as a RA or not. I assume the non-RA datagram is shipping LL src and 255 hop limits. The receiving node would always receive the first fragment but no others, is that a DoS attack? Thanks, washam From fgont@si6networks.com Mon Mar 5 19:58:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D70D921F8736 for ; Mon, 5 Mar 2012 19:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.54 X-Spam-Level: X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.060, 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 d07mPCfu+cqY for ; Mon, 5 Mar 2012 19:58:30 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 0D46B21F8734 for ; Mon, 5 Mar 2012 19:58:30 -0800 (PST) Received: from [2001:5c0:1000:a::91f] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1S4lXZ-0006BL-6t; Tue, 06 Mar 2012 04:58:21 +0100 Message-ID: <4F558B55.4030602@si6networks.com> Date: Tue, 06 Mar 2012 00:58:13 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Washam Fan References: <201202141455.q1EEt1C04893@ftpeng-update.cisco.com> <4F5573AD.7000101@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, draft-ietf-v6ops-ra-guard-implementation@tools.ietf.org Subject: Re: [v6ops] new draft: draft-ietf-v6ops-ra-guard-implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 03:58:30 -0000 Hi, Washam, On 03/06/2012 12:05 AM, Washam Fan wrote: > My point was, you are blocking legitimate traffic eventually. For > example, if there is a non-RA datagram split into 2 fragments, you > will pass the first fragment because it is recognized as a non-RA. you > will block the second fragment because you can not recognize it as a > RA or not. The second fragment *can* be determined as non-RA (from the Next Header field of the fragment header). -- Maybe I should explicitly note that that non-first fragments should always be passed? > I assume the non-RA datagram is shipping LL src and 255 hop > limits. The receiving node would always receive the first fragment but > no others, is that a DoS attack? If it's a non-RA datagram, all the fragments will be passed. If it is *not* a fragmented RA, the first fragment will be dropped, and the rest of the fragments will be passed. This could certainly be exploited for a DoS... but an attacker could always perform the same attack by forging fragmented datagrams without sending one of the fragments -- i.e., an IPv6 implementation should be able to handle this case, already. I could add a small paragraph clarifying this in the Security Considerations section if you think this would be appropriate/necessary. Thanks! Best regards, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fred@cisco.com Mon Mar 5 20:46:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15F6B21E808B for ; Mon, 5 Mar 2012 20:46:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.771 X-Spam-Level: X-Spam-Status: No, score=-108.771 tagged_above=-999 required=5 tests=[AWL=1.828, 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 Zia9Ji0sjZEq for ; Mon, 5 Mar 2012 20:46:38 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7007021E8089 for ; Mon, 5 Mar 2012 20:46:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2062; q=dns/txt; s=iport; t=1331009198; x=1332218798; h=from:subject:date:message-id:to:mime-version: content-transfer-encoding; bh=Jh8SVoJOUglEAr5y6jRgmBVEIpm/UCElOhczoQxJwZY=; b=CPU+hnNgr9BVg4WV9Lcfv244wfJkQpzZPelM2J4k6Ueyw2dVrwkHYq/a TWGNPJbdgUcLtKXXr5Se0IwtR2/tnV74DGZkBHFVjSqBaQa9UvTt3DB1A lmYnjXyQgfGk4G1wTrffg1zkIjYAIj5QOzwz6+iDCyzbSO4jrb50qukmq 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAK+VVU+rRDoG/2dsb2JhbABDtGuBB4ISBAEnK4FSNYdkDJhTgScBnwWPe2MEiE6McIVjijOCcg X-IronPort-AV: E=Sophos;i="4.73,538,1325462400"; d="scan'208";a="32085996" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 06 Mar 2012 04:46:38 +0000 Received: from Freds-Computer.local (tky-vpn-client-230-217.cisco.com [10.70.230.217]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q264jgvm013286 for ; Tue, 6 Mar 2012 04:46:37 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Tue, 06 Mar 2012 13:46:37 +0900 X-PGP-Universal: processed; by Freds-Computer.local on Tue, 06 Mar 2012 13:46:37 +0900 From: Fred Baker Date: Tue, 6 Mar 2012 13:46:37 +0900 Message-Id: <25E067CE-65BF-462E-9A45-2D09451256F9@cisco.com> To: v6ops v6ops WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [v6ops] Agenda discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 04:46:39 -0000 Stated in no particular order, we have the following documents that meet = these criteria: - not in the IESG process somewhere - posted or updated since IETF 82 - have had list discussion since IETF 82 or responds to discussion at = IETF 82 At this point, I take them as our agenda at IETF 83. If I am missing a = document (if you have posted it since Sunday, I may well be missing it), = please remind me. http://tools.ietf.org/html/draft-carpenter-v6ops-icp-guidance "IPv6 Guidance for Internet Content and Application Service = Providers", Brian Carpenter, Sheng Jiang, 22-Feb-12 No presentation expected, but the authors would like working group = adoption. We need to decide whether we want to do that. http://tools.ietf.org/html/draft-carpenter-v6ops-label-balance "Using the IPv6 Flow Label for Server Load Balancing", Brian = Carpenter, Sheng Jiang, Willy Tarreau, 17-Jan-12 http://tools.ietf.org/html/draft-ietf-v6ops-464xlat "464XLAT: Combination of Stateful and Stateless Translation", Masataka Mawatari, Masanobu Kawashima, Cameron Byrne, 14-Feb-12 http://tools.ietf.org/html/draft-ietf-v6ops-6204bis "Basic Requirements for IPv6 Customer Edge Routers", Barbara Stark, Chris Donley, Hemant Singh, Ole Troan, Wes Beebee, 22-Dec-11 http://tools.ietf.org/html/draft-ietf-v6ops-ivi-icmp-address "Stateless Source Address Mapping for ICMPv6 Packets", Xing Li, = Congxiao Bao, Dan Wing, Ramji Vaithianathan, Geoff Huston, 24-Feb-12 http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation "Implementation Advice for IPv6 Router Advertisement Guard = (RA-Guard)", Fernando Gont, 3-Mar-12 http://tools.ietf.org/html/draft-ietf-v6ops-wireline-incremental-ipv6 "Wireline Incremental IPv6", Victor Kuarsingh, Lee Howard, 1-Feb-12 In the coming week, I am told to expect one additional -00 draft, and I = could imagine other drafts being updated. I will be looking for those = drafts to meet the criteria above as well, but please drop the chairs a = note.= From fred@cisco.com Mon Mar 5 20:59:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E5421E8096 for ; Mon, 5 Mar 2012 20:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.149 X-Spam-Level: X-Spam-Status: No, score=-108.149 tagged_above=-999 required=5 tests=[AWL=1.850, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 11m0TdwtPbwQ for ; Mon, 5 Mar 2012 20:59:28 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 74F2121E8091 for ; Mon, 5 Mar 2012 20:59:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2888; q=dns/txt; s=iport; t=1331009967; x=1332219567; h=mime-version:subject:from:in-reply-to:date:message-id: references:to:content-transfer-encoding; bh=RuXPd1GuoxdX7Oxb8lIW5HMwnNdQ+XPHCiSI/OXBnWM=; b=M37vkXsakC0CLK/hpjrnpIfhSeVLcgY72q6TvevqeE7vnDQcYQ4Rwo1z +rVkXn9D9Kb2VLpBqjp1E/8LQ87U/ycIapjII1SJH6lHa8ju+0IOeZYDE mgI8PqrhXcjO4KnbJxfDw2rEQ7kN+Mzi5Uo32UBDzMXHzN0W0VpVYiiNh U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EADeZVU9Io8UY/2dsb2JhbABDtXKBfQEBAQMBAQEBCwQBJysJEAsLRicwBhMUDodgBQuaEwGfBY97YwSIToxwhWOKM4Jy X-IronPort-AV: E=Sophos;i="4.73,538,1325462400"; d="scan'208";a="7176879" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 06 Mar 2012 04:59:25 +0000 Received: from Freds-Computer.local (tky-vpn-client-230-217.cisco.com [10.70.230.217]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q264xOAb013143 for ; Tue, 6 Mar 2012 04:59:25 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Tue, 06 Mar 2012 13:59:25 +0900 X-PGP-Universal: processed; by Freds-Computer.local on Tue, 06 Mar 2012 13:59:25 +0900 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <25E067CE-65BF-462E-9A45-2D09451256F9@cisco.com> Date: Tue, 6 Mar 2012 13:59:11 +0900 Message-Id: References: <25E067CE-65BF-462E-9A45-2D09451256F9@cisco.com> To: v6ops v6ops WG X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] Agenda discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 04:59:28 -0000 Downloading the new drafts, I observe three new ones: -rw-rw-r-- 1 fred fred 10823 Mar 5 17:46 = draft-ma-v6ops-terminal-test-00.txt -rw-rw-r-- 1 fred fred 18058 Mar 6 08:44 = draft-gundavelli-v6ops-community-wifi-svcs-00.txt -rw-rw-r-- 1 fred fred 21172 Mar 6 10:08 = draft-lopez-v6ops-dc-ipv6-00.txt (the date/time stamp reflects the fact that I'm in Japan and therefore a = day ahead) In each case, I will be looking for list traffic related to them as my = cue for agenda time. Authors, please provoke list traffic... On Mar 6, 2012, at 1:46 PM, Fred Baker wrote: > Stated in no particular order, we have the following documents that = meet these criteria: > - not in the IESG process somewhere > - posted or updated since IETF 82 > - have had list discussion since IETF 82 or responds to discussion at = IETF 82 >=20 > At this point, I take them as our agenda at IETF 83. If I am missing a = document (if you have posted it since Sunday, I may well be missing it), = please remind me. >=20 >=20 > http://tools.ietf.org/html/draft-carpenter-v6ops-icp-guidance > "IPv6 Guidance for Internet Content and Application Service = Providers", > Brian Carpenter, Sheng Jiang, 22-Feb-12 >=20 > No presentation expected, but the authors would like working group = adoption. We need to decide whether we want to do that. >=20 > http://tools.ietf.org/html/draft-carpenter-v6ops-label-balance > "Using the IPv6 Flow Label for Server Load Balancing", Brian = Carpenter, > Sheng Jiang, Willy Tarreau, 17-Jan-12 >=20 > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat > "464XLAT: Combination of Stateful and Stateless Translation", = Masataka > Mawatari, Masanobu Kawashima, Cameron Byrne, 14-Feb-12 >=20 > http://tools.ietf.org/html/draft-ietf-v6ops-6204bis > "Basic Requirements for IPv6 Customer Edge Routers", Barbara Stark, > Chris Donley, Hemant Singh, Ole Troan, Wes Beebee, 22-Dec-11 >=20 > http://tools.ietf.org/html/draft-ietf-v6ops-ivi-icmp-address > "Stateless Source Address Mapping for ICMPv6 Packets", Xing Li, = Congxiao > Bao, Dan Wing, Ramji Vaithianathan, Geoff Huston, 24-Feb-12 >=20 > http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation > "Implementation Advice for IPv6 Router Advertisement Guard = (RA-Guard)", > Fernando Gont, 3-Mar-12 >=20 > http://tools.ietf.org/html/draft-ietf-v6ops-wireline-incremental-ipv6 > "Wireline Incremental IPv6", Victor Kuarsingh, Lee Howard, 1-Feb-12 >=20 > In the coming week, I am told to expect one additional -00 draft, and = I could imagine other drafts being updated. I will be looking for those = drafts to meet the criteria above as well, but please drop the chairs a = note. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From washam.fan@gmail.com Mon Mar 5 22:13:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9650B21F86A0 for ; Mon, 5 Mar 2012 22:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 fUsyPxjlufC2 for ; Mon, 5 Mar 2012 22:13:43 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA9321F869E for ; Mon, 5 Mar 2012 22:13:43 -0800 (PST) Received: by wicr5 with SMTP id r5so2329964wic.31 for ; Mon, 05 Mar 2012 22:13:42 -0800 (PST) Received-SPF: pass (google.com: domain of washam.fan@gmail.com designates 10.216.139.229 as permitted sender) client-ip=10.216.139.229; Authentication-Results: mr.google.com; spf=pass (google.com: domain of washam.fan@gmail.com designates 10.216.139.229 as permitted sender) smtp.mail=washam.fan@gmail.com; dkim=pass header.i=washam.fan@gmail.com Received: from mr.google.com ([10.216.139.229]) by 10.216.139.229 with SMTP id c79mr4456278wej.16.1331014422756 (num_hops = 1); Mon, 05 Mar 2012 22:13:42 -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=f8L2sQKmf7gLXq/zDlbof0LDhXOGS/81ytoc+xDiyfs=; b=sZwrwCfL4qNT4J73DywTldefKtnfyafkSNEulFCgTYTMfcRvI2Pr3Faf8EJ09P33Vx pDfHnVW1THMwZc3WjoL4fdVlYYsT6SmWxPA1sg78/13CWL8u/RIfqyuIIxvrUBqkHI/9 fmnrPjNwtqhz4jy9zylafhU/vpPZ/txb48bvZPsuR1E69n2Txxz9SOB8UZHXX+gQ4j6S 6qfZp04szGkySto2ffnh+VWbcLeWQagfSxI72+J8NiU2KNQlUeSEjj9GWpQAxEn+C1Uv bM+pcacly/cs7m387shFqXAkI3l5jqhaXF3087OrHvvSFw94yxlZn9OvSyCghiY6Cd5j noZw== MIME-Version: 1.0 Received: by 10.216.139.229 with SMTP id c79mr3586627wej.16.1331014422625; Mon, 05 Mar 2012 22:13:42 -0800 (PST) Received: by 10.216.205.169 with HTTP; Mon, 5 Mar 2012 22:13:42 -0800 (PST) In-Reply-To: <4F558B55.4030602@si6networks.com> References: <201202141455.q1EEt1C04893@ftpeng-update.cisco.com> <4F5573AD.7000101@si6networks.com> <4F558B55.4030602@si6networks.com> Date: Tue, 6 Mar 2012 14:13:42 +0800 Message-ID: From: Washam Fan To: Fernando Gont Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org, draft-ietf-v6ops-ra-guard-implementation@tools.ietf.org Subject: Re: [v6ops] new draft: draft-ietf-v6ops-ra-guard-implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 06:13:44 -0000 Hi Fernando, 2012/3/6 Fernando Gont : > Hi, Washam, > > On 03/06/2012 12:05 AM, Washam Fan wrote: >> My point was, you are blocking legitimate traffic eventually. For >> example, if there is a non-RA datagram split into 2 fragments, you >> will pass the first fragment because it is recognized as a non-RA. you >> will block the second fragment because you can not recognize it as a >> RA or not. > > The second fragment *can* be determined as non-RA (from the Next Header > field of the fragment header). Sorry, I am confused here. you don't know how many bytes should be skipped to reach the next header, per section 2.2. > -- Maybe I should explicitly note that > that non-first fragments should always be passed? Yes, please. Then I have no confusion. > >> I assume the non-RA datagram is shipping LL src and 255 hop >> limits. The receiving node would always receive the first fragment but >> no others, is that a DoS attack? > > If it's a non-RA datagram, all the fragments will be passed. > > If it is *not* a fragmented RA, the first fragment will be dropped, and I think you meant 'if it *IS* a fragmented RA', didn't you? > the rest of the fragments will be passed. This could certainly be > exploited for a DoS... but an attacker could always perform the same > attack by forging fragmented datagrams without sending one of the > fragments -- i.e., an IPv6 implementation should be able to handle this > case, already. I could add a small paragraph clarifying this in the > Security Considerations section if you think this would be > appropriate/necessary. Yes, that would address my concern. Thanks, washam From fernando.gont.netbook.win@gmail.com Mon Mar 5 22:48:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73FF921E80A3 for ; Mon, 5 Mar 2012 22:48:49 -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 YFBNDIANSA6I for ; Mon, 5 Mar 2012 22:48:48 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id CF9A021E8081 for ; Mon, 5 Mar 2012 22:48:48 -0800 (PST) Received: by yhpp34 with SMTP id p34so2316791yhp.31 for ; Mon, 05 Mar 2012 22:48:48 -0800 (PST) Received-SPF: pass (google.com: domain of fernando.gont.netbook.win@gmail.com designates 10.236.192.138 as permitted sender) client-ip=10.236.192.138; Authentication-Results: mr.google.com; spf=pass (google.com: domain of fernando.gont.netbook.win@gmail.com designates 10.236.192.138 as permitted sender) smtp.mail=fernando.gont.netbook.win@gmail.com; dkim=pass header.i=fernando.gont.netbook.win@gmail.com Received: from mr.google.com ([10.236.192.138]) by 10.236.192.138 with SMTP id i10mr32034555yhn.3.1331016528562 (num_hops = 1); Mon, 05 Mar 2012 22:48:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=yL1/5MqD6gLEhTAw71Aw8E8KHoqhr2FcWkjpO/Ki6j4=; b=r3CAT8uUOKlvmT8LbcrG1xgUXwN7z855Z11taoUR++j6/X4W9n7VQ+2cJK0YIDxQw6 RiDT9zbT4pyXt2BE80BxlapLlIrWZDv594+27uizUEF3eP/eJkZ52G1FatL80mfStdWw BmwkGz9jsxp2ChJ/6GahGOPQef3amhnH3VxBBPO1nd4xXNkv5PA4HWRBd9nOZmtGAzMj nNBdV24tEG1sQf2yxYQwHhixfGwlVWH3Xo1neQrAly4QwFjzjCZSLJIRIWz/do8i9wvn iGb8jxUloAcJa7JAJ9D5xTkx56YuBxmQwW7CIoJGV0FOvA7R14EEDJrihp8+Giswldjx IUMA== Received: by 10.236.192.138 with SMTP id i10mr25274732yhn.3.1331016528508; Mon, 05 Mar 2012 22:48:48 -0800 (PST) Received: from [192.168.123.102] ([186.134.8.162]) by mx.google.com with ESMTPS id e8sm1739323yhk.0.2012.03.05.22.48.45 (version=SSLv3 cipher=OTHER); Mon, 05 Mar 2012 22:48:47 -0800 (PST) Sender: Fernando Gont Message-ID: <4F55B34B.6090300@gont.com.ar> Date: Tue, 06 Mar 2012 03:48:43 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Washam Fan References: <201202141455.q1EEt1C04893@ftpeng-update.cisco.com> <4F5573AD.7000101@si6networks.com> <4F558B55.4030602@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, draft-ietf-v6ops-ra-guard-implementation@tools.ietf.org Subject: Re: [v6ops] new draft: draft-ietf-v6ops-ra-guard-implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 06:48:49 -0000 Hi, Washam, On 03/06/2012 03:13 AM, Washam Fan wrote: >> The second fragment *can* be determined as non-RA (from the Next Header >> field of the fragment header). > > Sorry, I am confused here. you don't know how many bytes should be > skipped to reach the next header, per section 2.2. Sorry, I don't really know why I wrote what I wrote. You're right about this one. >> -- Maybe I should explicitly note that >> that non-first fragments should always be passed? > > Yes, please. Then I have no confusion. Great. Will clarify this and update the I-D before the cutoff. -- thanks! >>> I assume the non-RA datagram is shipping LL src and 255 hop >>> limits. The receiving node would always receive the first fragment but >>> no others, is that a DoS attack? >> >> If it's a non-RA datagram, all the fragments will be passed. >> >> If it is *not* a fragmented RA, the first fragment will be dropped, and > > I think you meant 'if it *IS* a fragmented RA', didn't you? Yes (it's clear I should go to bed now :-) ) -- sorry for the confusion! >> the rest of the fragments will be passed. This could certainly be >> exploited for a DoS... but an attacker could always perform the same >> attack by forging fragmented datagrams without sending one of the >> fragments -- i.e., an IPv6 implementation should be able to handle this >> case, already. I could add a small paragraph clarifying this in the >> Security Considerations section if you think this would be >> appropriate/necessary. > > Yes, that would address my concern. Will address this one in the next rev, then (before the cutoff). Thanks so much! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From v6ops@globis.net Tue Mar 6 00:18:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE2A21E80BD for ; Tue, 6 Mar 2012 00:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.043, 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 MlWEWkHjpRRZ for ; Tue, 6 Mar 2012 00:18:52 -0800 (PST) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 84DEA21E80BA for ; Tue, 6 Mar 2012 00:18:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 3AAA38700EE; Tue, 6 Mar 2012 09:18:50 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GkILqK9GYvWu; Tue, 6 Mar 2012 09:18:37 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 0FE7587002E; Tue, 6 Mar 2012 09:18:37 +0100 (CET) Message-ID: <4F55C85C.1060601@globis.net> Date: Tue, 06 Mar 2012 09:18:36 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Washam Fan References: <201202141455.q1EEt1C04893@ftpeng-update.cisco.com> <4F5573AD.7000101@si6networks.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010801060307070700030706" Cc: Fernando Gont , v6ops@ietf.org, draft-ietf-v6ops-ra-guard-implementation@tools.ietf.org Subject: Re: [v6ops] new draft: draft-ietf-v6ops-ra-guard-implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 08:18:53 -0000 This is a multi-part message in MIME format. --------------010801060307070700030706 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks for your interest. I think your cases might be clearer if rather than using the term "non RA datagram" you actually included a full example of the header properties that can be identified after parsing e.g. src address, hop count, fragment header present or not, ICMP header present or not. To my understanding, I suspect what you're describing is simply a false positive, which comes as a side-effect risk of implementing RA-Guard, and is covered by the warning in the draft. Case 1: fragmented traffic where the upper layer header is not present in the first fragment. Possible false positive Fragment 1 with i) fragment header = present & fragment offset => first fragment ii) Source Address = link-local address or unspecified address (::) iii) Hop Limit is 255 iv) no ICMPv6 or TCP/UDP or other top layer header in this fragment will be dropped by Rule 3 as it cannot be positively identified as not being ICMPv6 RA. Fragment 2 with i) fragment header = present & fragment offset => 2nd or later fragment ii) Source Address = link-local address or unspecified address (::) iii) Hop Limit is 255 iv) don't care NB TCP header or ICMPv6 header + RA message may be present in this fragment (but cannot be determined because the header length of the previous header is contained in the first fragment) will not be dropped by Rule 3, as filtering rules are defined for packets. Will be passed via rule4. Packet will fail re-assembly at the receiving end node. So this case could well be legitimate traffic (TCP header in fragment 2) that ideally should not be dropped => false positive, or it could be RA (ICMPv6 header + RA message in fragment 2) which should have been dropped. For RA Guard to be able to protect existing implementations you have no choice but to drop unidentifiable packets as the default rule. But can you think of a use for such traffic? This is traffic that is limited to the link only. The nodes *know* the MTU by definition. So why are they sending fragments? If you can answer that then you know whether the false positives will be truly harmful. There could be valid use cases of course, which is why I'd encourage you to think of them and discuss. NB router ports are not subject to these filtering rules, as they are valid sources of RA. So false positives would probably be end-node traffic like unsolicited service announcements limited to link only and sourced from the link-local address and where the upper-layer protocol header is not contained in the 1st fragment. Case 2 : Fragmented packet where the TCP or other upper layer header is present in the first fragment (and it it is not RA) = nominal case of non-RA message passed Fragment 1 with i) fragment header = present & fragment offset => first fragment ii) Source Address = link-local address or unspecified address (::) iii) Hop Limit is 255 iv) TCP/UDP or other top layer header present in this fragment so the parser can identify that this packet is not RA will not be dropped by Rule 3 as it can be positively identified as not being ICMPv6 RA, and will be passed via Rule 4. Fragment 2 with i) fragment header = present & fragment offset => 2nd or later fragment ii) Source Address = link-local address or unspecified address (::) iii) Hop Limit is 255 iv) data will not be dropped by Rule 3 and will be passed via rule 4, as the filtering rules are defined for packets (not fragments). Case 3 fragmented RA in stateless RA Guard, where the ICMPv6 header and start of the RA message are in the first fragment = nominal case of RA message blocked: Fragment 1 with i) fragment header = present & fragment offset => first fragment ii) Source Address = link-local address or unspecified address (::) iii) Hop Limit is 255 iv) ICMPv6 RA message will be dropped by Rule 3 as it can be positively identified as being ICMPv6 RA. Fragment 2 with i) fragment header = present & fragment offset => 2nd or later fragment ii) Source Address = link-local address or unspecified address (::) iii) Hop Limit is 255 iv) data (continuation of RA message) will not be dropped by Rule 3 and will be passed via rule 4, as the filtering rules are defined for packets (not fragments). The packet will fail re-assembly at the end node and thus the RA message is effectively blocked. regards, RayH Washam Fan wrote: > Hi Fernando, > > 2012/3/6 Fernando Gont: > >> On 03/05/2012 02:15 AM, Washam Fan wrote: >> >>> I have a comment on rule#3 in section 3. It seems to me that the first >>> fragment which can be recognized as non-RA could pass the RA-Guard. Is >>> that the intent? >>> >> Yes, of course. -- otherwise we'd be blocking legitimate fragmented traffic. >> > > My point was, you are blocking legitimate traffic eventually. For > example, if there is a non-RA datagram split into 2 fragments, you > will pass the first fragment because it is recognized as a non-RA. you > will block the second fragment because you can not recognize it as a > RA or not. I assume the non-RA datagram is shipping LL src and 255 hop > limits. The receiving node would always receive the first fragment but > no others, is that a DoS attack? > > Thanks, > washam > > --------------010801060307070700030706 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks for your interest.

I think your cases might be clearer if rather than using the term "non RA datagram" you actually included a full example of the header properties that can be identified after parsing e.g. src address, hop count, fragment header present or not, ICMP header present or not.

To my understanding, I suspect what you're describing is simply a false positive, which comes as a side-effect risk of implementing RA-Guard, and is covered by the warning in the draft.

Case 1: fragmented traffic where the upper layer header is not present in the first fragment. Possible false positive

Fragment 1 with
i) fragment header = present & fragment offset => first fragment
ii) Source Address = link-local address or unspecified address (::)
iii) Hop Limit is 255
iv) no ICMPv6 or TCP/UDP or other top layer header in this fragment

will be dropped by Rule 3 as it cannot be positively identified as not being ICMPv6 RA.

Fragment 2 with
i) fragment header = present & fragment offset => 2nd or later fragment
ii) Source Address = link-local address or unspecified address (::)
iii) Hop Limit is 255
iv) don't care

NB TCP header or ICMPv6 header + RA message may be present in this fragment (but cannot be determined because the header length of the previous header is contained in the first fragment)

will not be dropped by Rule 3, as filtering rules are defined for packets. Will be passed via rule4.
Packet will fail re-assembly at the receiving end node.

So this case could well be legitimate traffic (TCP header in fragment 2) that ideally should not be dropped => false positive, or it could be RA (ICMPv6 header + RA message in fragment 2) which should have been dropped.

For RA Guard to be able to protect existing implementations you have no choice but to drop unidentifiable packets as the default rule.

But can you think of a use for such traffic? This is traffic that is limited to the link only. The nodes *know* the MTU by definition. So why are they sending fragments? If you can answer that then you know whether the false positives will be truly harmful.

There could be valid use cases of course, which is why I'd encourage you to think of them and discuss. NB router ports are not subject to these filtering rules, as they are valid sources of RA. So false positives would probably be end-node traffic like unsolicited service announcements limited to link only and sourced from the link-local address and where the upper-layer protocol header is not contained in the 1st fragment.



Case 2 : Fragmented packet where the TCP or other upper layer header is present in the first fragment (and it it is not RA) = nominal case of non-RA message passed

Fragment 1 with
i) fragment header = present & fragment offset => first fragment
ii) Source Address = link-local address or unspecified address (::)
iii) Hop Limit is 255
iv) TCP/UDP or other top layer header present in this fragment so the parser can identify that this packet is not RA

will not be dropped by Rule 3 as it can be positively identified as not being ICMPv6 RA, and will be passed via Rule 4.

Fragment 2 with
i) fragment header = present & fragment offset => 2nd or later fragment
ii) Source Address = link-local address or unspecified address (::)
iii) Hop Limit is 255
iv) data

will not be dropped by Rule 3 and will be passed via rule 4, as the filtering rules are defined for packets (not fragments).


Case 3 fragmented RA in stateless RA Guard, where the ICMPv6 header and start of the RA message are in the first fragment = nominal case of RA message blocked:

Fragment 1 with
i) fragment header = present & fragment offset => first fragment
ii) Source Address = link-local address or unspecified address (::)
iii) Hop Limit is 255
iv) ICMPv6 RA message

will be dropped by Rule 3 as it can be positively identified as being ICMPv6 RA.

Fragment 2 with
i) fragment header = present & fragment offset => 2nd or later fragment
ii) Source Address = link-local address or unspecified address (::)
iii) Hop Limit is 255
iv) data (continuation of RA message)

will not be dropped by Rule 3 and will be passed via rule 4, as the filtering rules are defined for packets (not fragments).
The packet will fail re-assembly at the end node and thus the RA message is effectively blocked.

regards,
RayH

Washam Fan wrote: 
Hi Fernando,

2012/3/6 Fernando Gont <fgont@si6networks.com>:
  
On 03/05/2012 02:15 AM, Washam Fan wrote:
    
I have a comment on rule#3 in section 3. It seems to me that the first
fragment which can be recognized as non-RA could pass the RA-Guard. Is
that the intent?
      
Yes, of course. -- otherwise we'd be blocking legitimate fragmented traffic.
    

My point was, you are blocking legitimate traffic eventually. For
example, if there is a non-RA datagram split into 2 fragments, you
will pass the first fragment because it is recognized as a non-RA. you
will block the second fragment because you can not recognize it as a
RA or not. I assume the non-RA datagram is shipping LL src and 255 hop
limits. The receiving node would always receive the first fragment but
no others, is that a DoS attack?

Thanks,
washam
--------------010801060307070700030706-- From fgont@si6networks.com Tue Mar 6 00:41:14 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2E521F8786 for ; Tue, 6 Mar 2012 00:41:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.050, 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 eGBL+T2R4f3o for ; Tue, 6 Mar 2012 00:41:13 -0800 (PST) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2AD21F8781 for ; Tue, 6 Mar 2012 00:41:13 -0800 (PST) Received: from [2001:5c0:1000:a::91f] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1S4pxF-000053-0P; Tue, 06 Mar 2012 09:41:09 +0100 Message-ID: <4F55CD92.9010107@si6networks.com> Date: Tue, 06 Mar 2012 05:40:50 -0300 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Ray Hunter References: <201202141455.q1EEt1C04893@ftpeng-update.cisco.com> <4F5573AD.7000101@si6networks.com> <4F55C85C.1060601@globis.net> In-Reply-To: <4F55C85C.1060601@globis.net> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, draft-ietf-v6ops-ra-guard-implementation@tools.ietf.org Subject: Re: [v6ops] new draft: draft-ietf-v6ops-ra-guard-implementation X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 08:41:14 -0000 Hi, Ray, Please find my comments inline... On 03/06/2012 05:18 AM, Ray Hunter wrote: > Case 1: fragmented traffic where the upper layer header is not present > in the first fragment. Possible false positive > > Fragment 1 with > i) fragment header = present & fragment offset => first fragment > ii) Source Address = link-local address or unspecified address (::) > iii) Hop Limit is 255 > iv) no ICMPv6 or TCP/UDP or other top layer header in this fragment > > will be dropped by Rule 3 as it cannot be positively identified as not > being ICMPv6 RA. [....] > But can you think of a use for such traffic? This is traffic that is > limited to the link only. The nodes *know* the MTU by definition. So why > are they sending fragments? If you can answer that then you know whether > the false positives will be truly harmful. +1 Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fred@cisco.com Tue Mar 6 06:55:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F5021F86B0 for ; Tue, 6 Mar 2012 06:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.932 X-Spam-Level: X-Spam-Status: No, score=-109.932 tagged_above=-999 required=5 tests=[AWL=0.667, 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 Z-0q7MMgJPQ4 for ; Tue, 6 Mar 2012 06:55:01 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7823821F86A3 for ; Tue, 6 Mar 2012 06:55:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=144; q=dns/txt; s=iport; t=1331045701; x=1332255301; h=date:from:message-id:to:subject:cc; bh=Swmn6b2WGcH/9CkOsEZMemqWaw+PLr7k8I+0LA+BZi0=; b=Ek9SakaBFkhH2pfhnmi6qJfoH30sFVyy+/c5oJa0AS4Z28NbeYZ6gFle H+NYlSfHUSayR7YzAF3oCBxJZbInwIeWcvFdGYQ/gID7E8Uhe4dX/Rnk6 C30FugZbzjgKUXG0d2g/aXJODzU9guBEBvLFDzVjHpNwlw4qIUbTvvObQ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAJAMEkVk+rRDoJ/2dsb2JhbABDo00BkR2BB4IWAWY8LXwOh2QMmg4Bnw+NPIMiBIhSnQODBA X-IronPort-AV: E=Sophos;i="4.73,540,1325462400"; d="scan'208";a="34656384" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 06 Mar 2012 14:55:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q26Et1xD004428; Tue, 6 Mar 2012 14:55:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id q26Et1N03840; Tue, 6 Mar 2012 06:55:01 -0800 (PST) Date: Tue, 6 Mar 2012 06:55:01 -0800 (PST) From: Message-Id: <201203061455.q26Et1N03840@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-gundavelli-v6ops-community-wifi-svcs@tools.ietf.org Subject: [v6ops] new draft: draft-gundavelli-v6ops-community-wifi-svcs X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 14:55:02 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-gundavelli-v6ops-community-wifi-svcs. Please take a look at it and comment. From fred@cisco.com Tue Mar 6 06:55:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3EB21F86EB for ; Tue, 6 Mar 2012 06:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.028 X-Spam-Level: X-Spam-Status: No, score=-110.028 tagged_above=-999 required=5 tests=[AWL=0.571, 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 r4nz68xJhmqu for ; Tue, 6 Mar 2012 06:55:03 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id A47DD21F8495 for ; Tue, 6 Mar 2012 06:55:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=127; q=dns/txt; s=iport; t=1331045701; x=1332255301; h=date:from:message-id:to:subject:cc; bh=gOEmSkF364ONxR/ZNveAFdAW6rR3nRvAJg9u1zpXLk4=; b=N0S2v2qho+O79FHbicgC7N9Ce68mjJIEd0r2KEpduh2QRyVIRO7+2A+M B3G8RRHFHlQmjpqRyZHV942vOykRUPAShgQE9XjqBNd1YYe7+fhg5uahb OLkvRxtFReui86xenP3ArriT9fIVt/PM8i/QCO/cp8UrTU5gUdkL6p7nv Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8IAMEkVk+rRDoJ/2dsb2JhbABDo00BkR2BB4IWAWY8LYEKh2QMmg4Bnw+NPIMiBIhSnQODBA X-IronPort-AV: E=Sophos;i="4.73,540,1325462400"; d="scan'208";a="32136590" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 06 Mar 2012 14:55:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q26Et1g2004429; Tue, 6 Mar 2012 14:55:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id q26Et1u03846; Tue, 6 Mar 2012 06:55:01 -0800 (PST) Date: Tue, 6 Mar 2012 06:55:01 -0800 (PST) From: Message-Id: <201203061455.q26Et1u03846@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-lopez-v6ops-dc-ipv6@tools.ietf.org Subject: [v6ops] new draft: draft-lopez-v6ops-dc-ipv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 14:55:03 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-lopez-v6ops-dc-ipv6. Please take a look at it and comment. From internet-drafts@ietf.org Tue Mar 6 07:50:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D995321F8843; Tue, 6 Mar 2012 07:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 PjDV3C3K1mj5; Tue, 6 Mar 2012 07:50:55 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7BE621F8722; Tue, 6 Mar 2012 07:50:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120306155052.23211.48854.idtracker@ietfa.amsl.com> Date: Tue, 06 Mar 2012 07:50:52 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-06.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 15:50:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : Basic Requirements for IPv6 Customer Edge Routers Author(s) : Hemant Singh Wes Beebee Chris Donley Barbara Stark Ole Troan Filename : draft-ietf-v6ops-6204bis-06.txt Pages : 21 Date : 2012-03-06 This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers IP transition technologies. Two transition technologies in RFC 5969's 6rd and RFC 6333's DS-Lite. are covered in the document. The document obsoletes RFC 6204, if approved. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6204bis-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-6204bis-06.txt From brian.e.carpenter@gmail.com Tue Mar 6 14:40:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8039421E804F for ; Tue, 6 Mar 2012 14:40:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.425 X-Spam-Level: X-Spam-Status: No, score=-103.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 WQLI6swP86eH for ; Tue, 6 Mar 2012 14:40:33 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id EF25721E8014 for ; Tue, 6 Mar 2012 14:40:32 -0800 (PST) Received: by ggmi1 with SMTP id i1so2903446ggm.31 for ; Tue, 06 Mar 2012 14:40:32 -0800 (PST) Received-SPF: pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.236.157.9 as permitted sender) client-ip=10.236.157.9; Authentication-Results: mr.google.com; spf=pass (google.com: domain of brian.e.carpenter@gmail.com designates 10.236.157.9 as permitted sender) smtp.mail=brian.e.carpenter@gmail.com; dkim=pass header.i=brian.e.carpenter@gmail.com Received: from mr.google.com ([10.236.157.9]) by 10.236.157.9 with SMTP id n9mr36985751yhk.96.1331073632686 (num_hops = 1); Tue, 06 Mar 2012 14:40:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=EsY/Mq/dmPL4anOd79rEbx6rC3W7XwOkT7QkxztoyNw=; b=b1QCEeY7tFK/Bl+H1xAEifcrA/MxBL6sc37jOrb3DbKLjddeG5O9J+yQw0QBDV2F30 NcKMq+NXGj/U79ZG2H9+qC5bwv/EQ4TxWeHUPw4TxxsLyGCmblh1Ijfkcfykod/pIpPG GDgjJ7gFK8GqM3zWgcHKA7YIyYmTlgSESv1fSAcsVTJequgnsnTTa0KzFp/ea4p+viPw iZf+iA6iUYmh2nIw1RLB5OmkKmsZnl8jEHxKcRyCJpFDwOd4AUUMMb0etM0Yi512WRdR SA4C/XuRGmUN80X9IjyCzCcUNVcxGmbEURW+U17XmSluyC47M/AY3NWu2oPMYiyDK5Fe hcTg== Received: by 10.236.157.9 with SMTP id n9mr29366624yhk.96.1331073632623; Tue, 06 Mar 2012 14:40:32 -0800 (PST) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id b73sm52664590yhj.22.2012.03.06.14.40.30 (version=SSLv3 cipher=OTHER); Tue, 06 Mar 2012 14:40:31 -0800 (PST) Message-ID: <4F56925B.1060607@gmail.com> Date: Wed, 07 Mar 2012 11:40:27 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [v6ops] [Fwd: I-D Action: draft-carpenter-v6ops-label-balance-02.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 22:40:33 -0000 Hi, Willy has made some changes to this version to clarify points that have been discussed on the list recently. Brian -------- Original Message -------- Subject: I-D Action: draft-carpenter-v6ops-label-balance-02.txt Date: Tue, 06 Mar 2012 14:38:07 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using the IPv6 Flow Label for Server Load Balancing Author(s) : Brian Carpenter Sheng Jiang Willy Tarreau Filename : draft-carpenter-v6ops-label-balance-02.txt Pages : 12 Date : 2012-03-06 This document describes how the IPv6 flow label can be used in support of layer 3/4 load distribution and balancing for large server farms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-label-balance-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-carpenter-v6ops-label-balance-02.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From Tina.Tsou.Zouting@huawei.com Tue Mar 6 21:31:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B56421E8013 for ; Tue, 6 Mar 2012 21:31:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=-3.989, BAYES_00=-2.599, DEAR_SOMETHING=1.605, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_14=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24] 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 uPUTrKT2I5Cb for ; Tue, 6 Mar 2012 21:30:59 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id E07F921F8518 for ; Tue, 6 Mar 2012 21:30:58 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0I00AKJ1X663@szxga04-in.huawei.com> for v6ops@ietf.org; Wed, 07 Mar 2012 13:29:30 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0I0085P1X4ST@szxga04-in.huawei.com> for v6ops@ietf.org; Wed, 07 Mar 2012 13:29:30 +0800 (CST) Received: from szxeml213-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHH26603; Wed, 07 Mar 2012 13:29:29 +0800 Received: from SZXEML415-HUB.china.huawei.com (10.82.67.154) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 07 Mar 2012 13:28:47 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.28]) by szxeml415-hub.china.huawei.com ([10.82.67.154]) with mapi id 14.01.0323.003; Wed, 07 Mar 2012 13:29:17 +0800 Date: Wed, 07 Mar 2012 05:29:17 +0000 From: Tina TSOU In-reply-to: To: "v6ops@ietf.org" Message-id: <00AD42F5-8522-405F-813D-8082BED177A3@huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_z0KX2vkVBgjFpGBbpE6EfQ)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: Some questions on draft-lopez-v6ops-dc-ipv6 Thread-index: AQHM+6oepjk0GNLkSku2HErpGR87K5ZeQJao//99YgCAAJEuaA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <201203061455.q26Et1H03849@ftpeng-update.cisco.com> <1A3B210F-CE75-4443-8595-B0455F02D72B@cisco.com> Subject: [v6ops] Fwd: Some questions on draft-lopez-v6ops-dc-ipv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 05:31:02 -0000 --Boundary_(ID_z0KX2vkVBgjFpGBbpE6EfQ) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 DQoNClNlbnQgZnJvbSBteSBpUGFkDQoNCkJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOg0KDQpGcm9t OiBGcmVkIEJha2VyIDxmcmVkQGNpc2NvLmNvbTxtYWlsdG86ZnJlZEBjaXNjby5jb20+Pg0KRGF0 ZTogTWFyY2ggNiwgMjAxMiA4OjQ5OjQwIFBNIFBTVA0KVG86ICJDYXRoeSBaaG91KFFpYW4pIiA8 Y2F0aHkuemhvdUBodWF3ZWkuY29tPG1haWx0bzpjYXRoeS56aG91QGh1YXdlaS5jb20+Pg0KQ2M6 IDxkcmFmdC1sb3Blei12Nm9wcy1kYy1pcHY2QHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1s b3Blei12Nm9wcy1kYy1pcHY2QHRvb2xzLmlldGYub3JnPj4sICJ2Nm9wcy1jaGFpcnNAdG9vbHMu aWV0Zi5vcmc8bWFpbHRvOnY2b3BzLWNoYWlyc0B0b29scy5pZXRmLm9yZz4gQ2hhaXJzIiA8djZv cHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPG1haWx0bzp2Nm9wcy1jaGFpcnNAdG9vbHMuaWV0Zi5v cmc+Pg0KU3ViamVjdDogUmU6IFNvbWUgcXVlc3Rpb25zIG9uIGRyYWZ0LWxvcGV6LXY2b3BzLWRj LWlwdjYNCg0KTGV0IG1lIHJlbWluZCB5b3UgLSB0aGUgY3JpdGVyaWEgdGhlIFdHIGFza2VkIG1l IHRvIGFwcGx5IGFyZToNCiAtIHJlY2VudCBvciByZWNlbnRseSB1cGRhdGVkIGRyYWZ0DQogLSB3 aXRoaW4gY2hhcnRlcg0KIC0gcmVzdWx0cyBpbiBjb25zdHJ1Y3RpdmUgZGlzY3Vzc2lvbiBvbiB0 aGUgbWFpbGluZyBsaXN0DQoNCkkgdGhpbmsgdGhlIGZpcnN0IHR3byBhcmUgZmluZSAtIGl0J3Mg bmV3IGFuZCBpdCdzIHJlbGV2YW50LiBJIG5lZWQgZm9yIHlvdSB0byBwcm92b2tlIGRpc2N1c3Np b24gb24gdGhlIGxpc3QuDQoNCk9uIE1hciA3LCAyMDEyLCBhdCAxOjM2IFBNLCBGcmVkIEJha2Vy IHdyb3RlOg0KDQpUaGFua3MuIFNpbmNlIG9uZSBvZiB1cyBpcyBhIERhdGFDZW50ZXIgb3BlcmF0 b3IuLi4NCg0KT24gTWFyIDcsIDIwMTIsIGF0IDEyOjMyIFBNLCBDYXRoeSBaaG91KFFpYW4pIHdy b3RlOg0KDQpEZWFyIENoYWlycywNClpob25naHVhIGhhZCBzb21lIHByb2JsZW0gdG8gcmVwbHkg eW91ciBlbWFpbHMuIEkgZm9yd2FyZCBpdCBmb3IgaGltLg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLo7ogs8LW2buqDQq3osvNyrG85KO6IDIwMTItMDMt MDcgMTA6NTA6MjINCsrVvP7Iy6O6IGRyYWZ0LWxvcGV6LXY2b3BzLWRjLWlwdjYNCrOty82juiB2 Nm9wcy1jaGFpcnMNCtb3zOKjuiBSZTogU29tZSBxdWVzdGlvbnMgb24gZHJhZnQtbG9wZXotdjZv cHMtZGMtaXB2Ng0KDQpkZWFyIHNpcjoNCg0KSW4gdGhpcyBkcmFmdCAsd2UgdHJ5IHRvIGRlc2Ny aWJlIHRoZSBkaWZmZXJlbnQgc3RhZ2Ugb2YgdGhlIERDIG1pZ3JhdGlvbiB0byBpcHY2LiBUaGlz IGlzIHZlcnkgaW1wb3J0YW50IGluIHRoZSBvcGVyYXRvcidzIG5ldHdvcmsgZm9yIHRoZSBEQyBz ZXJ2aWNlIGlzIHJlYWxseSBhIGJpZyBidXNpbmVzcy4NCg0KVHJhbnNmZXIgREMgZnJvbSBJUHY0 IHRvIElQdjYgaXMgYSBsYXJnZSBzY2FsZSBwcm9qZWN0LCB3ZSBjYW4ndCBmaW5pc2ggaXQgaW4g YSBzaG9ydCB0ZXJtLiBTbyB3ZSBzaG91bGQgYnJlYWsgaXQgaW50byBzbWFsbCBjYXNlcyBhbmQg c3RhZ2VzLiBFdmVyeSBzdGFnZSB3ZSBjYW4gZ2V0IHRvIHNvbWUgcG9pbnQsIHByb3ZpZGUgc29t ZSBJUHY2IHNlcnZpY2UsIGFuZCAga2VlcCB0aGUgbWlncmF0aW9uIHNtb290aGx5LiBGdXJ0aGVy bW9yZSwgd2UgYWxzbyB0cnkgdG8gcG9pbnQgb3V0IHdoaWNoIHRyYW5zZmVyIHRlY2hub2xvZ3kg YW5kIGhvdyBpdCBjb3VsZCBiZSB1c2VkIGluIHRoZSBzcGVjaWFsIHN0YWdlLg0KDQpUaGlzIGlz IGEgZmlyc3QgZWRpdGlvbiBvZiB0aGUgcHJvcG9zYWwsIHdlIHdpbGwgdHJ5IG91ciBiZXN0IHRv IG1ha2UgaXQgcGVyZmVjdCBpbiB0aGUgZnV0dXJlLiBBbmQgd2UgYWxzbyBhcHByZWNpYXRlIHRv IGdldCBzb21lIGFkdmljZXMgZnJvbSB0aGUgcGVyc29uIHdobyBjb25jZXJucyB0aGUgREMgSVB2 NiBtaWdyYXRpb24gd29ya2luZy4NCg0KVGhhbmtzIGZvciB5b3VyIGFkdmljZS4NCg0KMjAxMi0w My0wNw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kei5jaGVuDQpD aGluYSBUZWxlY29tDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGZyZWRA Y2lzY28uY29tPG1haWx0bzpmcmVkQGNpc2NvLmNvbT4gW21haWx0bzpmcmVkQGNpc2NvLmNvbV0N ClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDA2LCAyMDEyIDEwOjU1IFBNDQpUbzogZHJhZnQtbG9wZXot djZvcHMtZGMtaXB2NkB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtbG9wZXotdjZvcHMtZGMt aXB2NkB0b29scy5pZXRmLm9yZz4NCkNjOiB2Nm9wcy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc8bWFp bHRvOnY2b3BzLWNoYWlyc0B0b29scy5pZXRmLm9yZz4NClN1YmplY3Q6IFNvbWUgcXVlc3Rpb25z IG9uIGRyYWZ0LWxvcGV6LXY2b3BzLWRjLWlwdjYNCg0KTGV0IG1lIGFzayBzb21lIHF1ZXN0aW9u cy4gVGhpcyBpcyBub3QgaW50ZW5kZWQgdG8gcHV0IHlvdSBvZmYgb3Igb2ZmZW5kLCBidXQgdG8g aGVscCB0aGUgY2hhaXJzIGluIHVuZGVyc3RhbmRpbmcgd2hlcmUgdGhlIGRyYWZ0IGZpdHMgaW4g dGhlIGJpZyBzY2hlbWUgb2YgdGhpbmdzLg0KDQoxKSBQbGVhc2UgcHJvdmlkZSBhIHN1Y2NpbmN0 IHByb2JsZW0gc3RhdGVtZW50IGZvciB5b3VyIGRyYWZ0LiBXaGF0IHByb2JsZW0vaXNzdWUgaXMg dGhpcyBkcmFmdCBkaXNjdXNzaW5nPyBXaGF0IG9wZXJhdGlvbmFsIHByb2JsZW1zIGRvZXMgdGhl IHByb3Bvc2FsIGFkZHJlc3MgaW4gcmVhbCBsaWZlIG5ldHdvcmtzPw0KDQoyKSBXaGVyZSBkb2Vz IHRoaXMgZHJhZnQgb3IgcHJlc2VudGF0aW9uIGZpdHMgaW50byB2Nm9wcycgY3VycmVudCBjaGFy dGVyIChodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvdjZvcHMvY2hhcnRlci8pPyBDaXRp bmcgc3BlY2lmaWMgYSBzZWN0aW9uKHMpIG9mIHRoZSBjaGFydGVyIGlzIHByZWZlcmFibGUuDQoN CjMpIFdobyBpcyB0aGlzIGRyYWZ0J3MgYXVkaWVuY2U/DQoNCjQpIEhhdmUgYW55IG9wZXJhdG9y cyBleHByZXNzZWQgaW50ZXJlc3QgaW4gdGhpcyBkcmFmdCBvciBpdHMgcHJvYmxlbSBzcGFjZSwg ZWl0aGVyIHZpYSByZXZpZXcgb3Igb3RoZXIgZGlzY3Vzc2lvbj8NCg0KNSkgSXMgdGhpcyBkcmFm dCBwdXJzdWluZyBkaXNjdXNzaW9uIGluIGFueSBvdGhlciBXR3M/IElmIHNvLCBwbGVhc2UgbGlz dCB0aGVtIGhlcmUsIGFsb25nIHdpdGggcmF0aW9uYWxlIGZvciB0aGUgaW50ZXJhY3Rpb24gd2l0 aCBtdWx0aXBsZSBXR3MgaW4gcGFyYWxsZWwuDQoNCjYpIElzIGFueSBwcm90b2NvbCB3b3JrIGJl aW5nIHJlY29tbWVuZGVkIGluIHRoZSBkcmFmdD8NCg0KDQo= --Boundary_(ID_z0KX2vkVBgjFpGBbpE6EfQ) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable


Sent from my iPad

Begin forwarded message:

From: Fred Baker <fred@cis= co.com>
Date: March 6, 2012 8:49:40 PM PST
To: "Cathy Zhou(Qian)" <cathy.zhou@huawei.com>
Cc: <= draft-lopez-v6ops-dc-ipv6@tools.ietf.org>, "v6ops-chairs@tools.ietf.org Chairs" &l= t;v6ops-chairs@tools.ietf.or= g>
Subject: Re: Some questions on draft-lopez-v6ops-dc-ipv6

Let me remind you - the criteria the WG asked me to apply are:
 - recent or recently updated draft
 - within charter
 - results in constructive discussion on the mailing list=

I think the first two are fine - it's new and it's relevant. I need f= or you to provoke discussion on the list.

On Mar 7, 2012, at 1:36 PM, Fred Baker wrote:

Thanks. Since one of us is a DataCenter ope= rator...

On Mar 7, 2012, at 12:32 PM, Cathy Zhou(Qia= n) wrote:

Dear Chairs,
Zhonghua had some problem to reply your ema= ils. I forward it for him.
________________________________________
=B7=A2=BC=FE=C8=CB=A3=BA =B3=C2=D6=D9=BB=AA=
=B7=A2=CB=CD=CA=B1=BC=E4=A3=BA 2012-03-07 1= 0:50:22
=CA=D5=BC=FE=C8=CB=A3=BA draft-lopez-v6ops-= dc-ipv6
=B3=AD=CB=CD=A3=BA v6ops-chairs
=D6=F7=CC=E2=A3=BA Re: Some questions on dr= aft-lopez-v6ops-dc-ipv6

dear sir:

In this draft ,we try to describe the diffe= rent stage of the DC migration to ipv6. This is very important in the opera= tor's network for the DC service is really a big business.

Transfer DC from IPv4 to IPv6 is a large sc= ale project, we can't finish it in a short term. So we should break it into= small cases and stages. Every stage we can get to some point, provide some= IPv6 service, and  keep the migration smoothly. Furthermore, we also try to point out which transfer technology = and how it could be used in the special stage.

This is a first edition of the proposal, we= will try our best to make it perfect in the future. And we also appreciate= to get some advices from the person who concerns the DC IPv6 migration wor= king.

Thanks for your advice.

2012-03-07
________________________________________
z.chen
China Telecom


-----Original Message-----
From: fre= d@cisco.com [mailto:fred@cisco.com]
Sent: Tuesday, March 06, 2012 10:55 PM
To: draft-lopez-v6ops-dc-ipv6@tools.ietf.org
Cc: v6ops-chairs@tools.ietf.org
Subject: Some questions on draft-lopez-v6op= s-dc-ipv6

Let me ask some questions. This is not inte= nded to put you off or offend, but to help the chairs in understanding wher= e the draft fits in the big scheme of things.

1) Please provide a succinct problem statem= ent for your draft. What problem/issue is this draft discussing? What opera= tional problems does the proposal address in real life networks?

2) Where does this draft or presentation fi= ts into v6ops' current charter (http://datatracker.ietf.org/wg/v6ops/charter/)? Citing s= pecific a section(s) of the charter is preferable.

3) Who is this draft's audience?

4) Have any operators expressed interest in= this draft or its problem space, either via review or other discussion?

5) Is this draft pursuing discussion in any= other WGs? If so, please list them here, along with rationale for the inte= raction with multiple WGs in parallel.

6) Is any protocol work being recommended i= n the draft?


--Boundary_(ID_z0KX2vkVBgjFpGBbpE6EfQ)-- From washam.fan@gmail.com Tue Mar 6 21:38:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E3C21E8066 for ; Tue, 6 Mar 2012 21:38:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.04 X-Spam-Level: X-Spam-Status: No, score=-3.04 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 YVeRctLhoWkM for ; Tue, 6 Mar 2012 21:38:34 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 4ABC421E8059 for ; Tue, 6 Mar 2012 21:38:34 -0800 (PST) Received: by wgbds11 with SMTP id ds11so261398wgb.1 for ; Tue, 06 Mar 2012 21:38:33 -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:content-transfer-encoding; bh=ATu91Rk75CdoRimnXhlK+6S8CbuUD9otHfXX8OXa1ds=; b=d60HAh0+qwqlOJ7kLPgqlu8R7KbyRwXqbndHyIAaYGaId3i/SuVBf5qL5+gInfNG3E 3qYxZyNyDfWdJ9xH46tygZnikkCUDY8m3hWeqOI5tfE6OIXB+QTQ11Qlrl+pode+7a9C vEIAiaquMCR8XgVYMXgyJJ7tC+0ZOhdhcNAUnrPkb9JRwZpq8FL9yx081jJBUlgA/yW9 IaFsc0m9vFpqzAy0t3JfOSJC+OGEUI5Bx+o2nsOEFYucUk2qMkkV9UZtRRF2Mc2vq955 xYysbIoIPFHgrqeH59Lt785lPW8XIFf651vovBTh9yDyyJo7CaZM5ZwJav75AUO5yJD8 GLPw== MIME-Version: 1.0 Received: by 10.180.95.34 with SMTP id dh2mr1253520wib.15.1331098713422; Tue, 06 Mar 2012 21:38:33 -0800 (PST) Received: by 10.216.205.169 with HTTP; Tue, 6 Mar 2012 21:38:33 -0800 (PST) In-Reply-To: References: Date: Wed, 7 Mar 2012 13:38:33 +0800 Message-ID: From: Washam Fan To: Victor Kuarsingh Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] Updated Feedback on Wireline Incremental IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 05:38:38 -0000 Hi Victor, I am aware of this draft http://tools.ietf.org/html/draft-ietf-softwire-dslite-deployment-02, and think that it should be referenced in section 5.5.1. The paragraph just before section 5.5.1 is talking about the scenario where NAT444 CGN co-located with AFTR. Could you elaborate on this scenario? I could not come up with any cases for this scenario. Thanks, washam 2012/2/26 Victor Kuarsingh : > V6ops team, > > A new version of "draft-ietf-v6ops-wireline-incremental-ipv6-01" has been > posted including feedback from the group. =A0This version has some textua= l > improvements and has made the following changes. > > We have removed some language which focused on the IPv4 connectivity > phenomenon (we did not remove all, but some). =A0The focus of this docume= nt is > about IPv6 introduction and evolution. =A0This is also based on other > discussions such as the Intarea meeting in Taipei (ref > -=A0http://www.ietf.org/proceedings/82/intarea.html) > The third phase is no longer called tunnelled IPv4, but IPv6-only. =A0Thi= s > phase would include tunnelled mode IPv4 if required (I.e. DS-LITE) > > I would like WG feedback if the refined focus (which is based on comments > on/off list) is in line with how the WG thinks this document should proce= ed. > =A0As well, I would also like feedback on the inclusion/exclusion of the > following technologies in phase 3. > > NAT64. =A0Although this mode of operation will be difficult in the forese= eable > future (on it's own) in a Wireline network due to the massive amounts of > iPv4 equipment in the environment, it may be of consideration to some > wireline providers. > Also, should we include discussion on 464 xlate > (draft-ietf-v6ops-464xlat-00) framework/architecture. =A0Although the doc= ument > is focused on "commercially available" technology, it appears that the > technology for the 464 xlate is available (CLAT via some beta code and NA= T64 > is out there) > > I would like to build in comments in the next rev =9602. =A0In that rev, = there > will also be additional considerations discussion/information based on so= me > additional input which is coming now. > > Regards, > > Victor K > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From internet-drafts@ietf.org Tue Mar 6 21:56:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490B121E807A; Tue, 6 Mar 2012 21:56:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 AriuRUafvzhk; Tue, 6 Mar 2012 21:56:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50A1621E8066; Tue, 6 Mar 2012 21:56:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120307055644.22348.78646.idtracker@ietfa.amsl.com> Date: Tue, 06 Mar 2012 21:56:44 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-v6nd-problems-05.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 05:56:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : Operational Neighbor Discovery Problems Author(s) : Igor Gashinsky Joel Jaeggli Warren Kumari Filename : draft-ietf-v6ops-v6nd-problems-05.txt Pages : 13 Date : 2012-03-03 In IPv4, subnets are generally small, made just large enough to cover the actual number of machines on the subnet. In contrast, the default IPv6 subnet size is a /64, a number so large it covers trillions of addresses, the overwhelming number of which will be unassigned. Consequently, simplistic implementations of Neighbor Discovery (ND) can be vulnerable to deliberate or accidental denial of service, whereby they attempt to perform address resolution for large numbers of unassigned addresses. Such denial of attacks can be launched intentionally (by an attacker), or result from legitimate operational tools or accident conditions. As a result of these vulnerabilities, new devices may not be able to "join" a network, it may be impossible to establish new IPv6 flows, and existing IPv6 transported flows may be interrupted. This document describes the potential for DOS in detail and suggests possible implementation improvements as well as operational mitigation techniques that can in some cases be used to protect against or at least alleviate the impact of such attacks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-v6nd-problems-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-v6nd-problems-05.txt From Tina.Tsou.Zouting@huawei.com Tue Mar 6 22:38:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADDB921E801F for ; Tue, 6 Mar 2012 22:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.41 X-Spam-Level: X-Spam-Status: No, score=-6.41 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 To5IvLtUEmrp for ; Tue, 6 Mar 2012 22:38:01 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id BB8D921E8013 for ; Tue, 6 Mar 2012 22:38:00 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0I00CQM4Z29S@szxga04-in.huawei.com> for v6ops@ietf.org; Wed, 07 Mar 2012 14:35:27 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0I00NK64YR0R@szxga04-in.huawei.com> for v6ops@ietf.org; Wed, 07 Mar 2012 14:35:26 +0800 (CST) Received: from szxeml213-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHH32431; Wed, 07 Mar 2012 14:35:26 +0800 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by szxeml213-edg.china.huawei.com (172.24.2.30) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 07 Mar 2012 14:34:44 +0800 Received: from SZXEML526-MBX.china.huawei.com ([169.254.2.28]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.003; Wed, 07 Mar 2012 14:35:20 +0800 Date: Wed, 07 Mar 2012 06:35:19 +0000 From: Tina TSOU In-reply-to: <4F52AE79.9020504@si6networks.com> To: "v6ops@ietf.org" Message-id: <2D31D894-5885-4BDB-B082-036517FDE0BE@huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_h5S8aOOHoQPSsNOEdXhfbQ)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: New Version Notification for draft-lopez-v6ops-dc-ipv6-00.txt Thread-index: AQHM/Cx3lJHQ8dC1gkS8IJjFp5TA8g== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20120303200905.31106.67929.idtracker@ietfa.amsl.com> <4F529C37.9090900@bogus.com> <4F52AE79.9020504@si6networks.com> Subject: [v6ops] Fwd: New Version Notification for draft-lopez-v6ops-dc-ipv6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 06:38:01 -0000 --Boundary_(ID_h5S8aOOHoQPSsNOEdXhfbQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT For your comments. http://datatracker.ietf.org/doc/draft-lopez-v6ops-dc-ipv6/ Sent from my iPad Begin forwarded message: From: > Date: March 5, 2012 5:09:49 PM PST To: > Cc: >, >, <18918588897@189.cn> Subject: New Version Notification for draft-lopez-v6ops-dc-ipv6-00.txt A new version of I-D, draft-lopez-v6ops-dc-ipv6-00.txt has been successfully submitted by Tina Tsou and posted to the IETF repository. Filename: draft-lopez-v6ops-dc-ipv6 Revision: 00 Title: DC Migration to IPv6 Creation date: 2012-03-05 WG ID: Individual Submission Number of pages: 10 Abstract: This document describes the issues, possible solutions, and opportunities in Data Center (DC) migration from IPv4 to IPv6. It focuses on the DC infrastructure itself, its operation, and the aspects related to DC interconnection through IPv6. It does not consider the particular mechanisms for making Internet services provided by applications hosted in the DC available through IPv6 beyond the specific aspects related to how their deployed on the DC infrastructure. Apart from facilitating the migration procedure itself, the mechanisms outlined here are intended to make this migration as transparent as possible (if not completely transparent) to applications and services running on the DC infrastructure, as well as to take advantage of IPv6 features to simplify DC operations, internally and across the Internet. The IETF Secretariat --Boundary_(ID_h5S8aOOHoQPSsNOEdXhfbQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT
For your comments.

Sent from my iPad

Begin forwarded message:

From: <internet-drafts@ietf.org>
Date: March 5, 2012 5:09:49 PM PST
To: <tina.tsou.zouting@huawei.com>
Cc: <cathy.zhou@huawei.com>, <diego@tid.es>, <18918588897@189.cn>
Subject: New Version Notification for draft-lopez-v6ops-dc-ipv6-00.txt

A new version of I-D, draft-lopez-v6ops-dc-ipv6-00.txt has been successfully submitted by Tina Tsou and posted to the IETF repository.

Filename:     draft-lopez-v6ops-dc-ipv6
Revision:     00
Title:         DC Migration to IPv6
Creation date:     2012-03-05
WG ID:         Individual Submission
Number of pages: 10

Abstract:
  This document describes the issues, possible solutions, and
  opportunities in Data Center (DC) migration from IPv4 to IPv6.  It
  focuses on the DC infrastructure itself, its operation, and the
  aspects related to DC interconnection through IPv6.  It does not
  consider the particular mechanisms for making Internet services
  provided by applications hosted in the DC available through IPv6
  beyond the specific aspects related to how their deployed on the DC
  infrastructure.

  Apart from facilitating the migration procedure itself, the
  mechanisms outlined here are intended to make this migration as
  transparent as possible (if not completely transparent) to
  applications and services running on the DC infrastructure, as well
  as to take advantage of IPv6 features to simplify DC operations,
  internally and across the Internet.




The IETF Secretariat
--Boundary_(ID_h5S8aOOHoQPSsNOEdXhfbQ)-- From wdec.ietf@gmail.com Wed Mar 7 05:49:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E27E21F8802 for ; Wed, 7 Mar 2012 05:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.887 X-Spam-Level: X-Spam-Status: No, score=-2.887 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 2L-hFJh2xS0e for ; Wed, 7 Mar 2012 05:49:30 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 43BED21F87F5 for ; Wed, 7 Mar 2012 05:49:30 -0800 (PST) Received: by qcsq13 with SMTP id q13so4022603qcs.31 for ; Wed, 07 Mar 2012 05:49: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=x3JPOGTAuvxk1U/4n1fVRNLXojNbAU7Ia106yMjtv3M=; b=uFRfAEzFbpnCNAyfxExvgP9YDK6CO6lY+xoGIWhH4fHYkIOrKeIKTZilYxPWP6u+lE PU15iZTMwdFITimyZ4ZhrYMGUNEbo40j8m1IvlfON5W/CQn7GPovbzGmKLjuB80cMtTI eRAlTUJL3dV7pM/sH4CgZw9EnVRqKbZPkKEo/PNd4ctxOmDGJueXZZKX0DbZCGoYC/5H TGjI5L8jzF7MPs0n9XmLXC9spS3iNik6YjFzuEJr2qcXPruKguxkfU1vvx0w6LxXRpdm AzOtbhkcc9cGzZtEMkm2/28nxBB3O1FORWfRlrp7X5qJleBL9tuzj1VcGlISG3LaZNqC 9jXw== MIME-Version: 1.0 Received: by 10.224.197.198 with SMTP id el6mr1336125qab.7.1331128169778; Wed, 07 Mar 2012 05:49:29 -0800 (PST) Received: by 10.229.231.203 with HTTP; Wed, 7 Mar 2012 05:49:29 -0800 (PST) In-Reply-To: References: Date: Wed, 7 Mar 2012 14:49:29 +0100 Message-ID: From: Wojciech Dec To: Cameron Byrne Content-Type: multipart/alternative; boundary=20cf300fb153b5ce1c04baa76d43 Cc: IPv6 Ops WG Subject: Re: [v6ops] Nomative language in draft-ietf-v6ops-464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 13:49:31 -0000 --20cf300fb153b5ce1c04baa76d43 Content-Type: text/plain; charset=ISO-8859-1 The draft contains text like "In the 464XLAT environment, the PLAT and CLAT SHOULD include an IPv6 Fragment Header, since IPv4 host does not set the DF bit. " What more it contains specific text in Section 6.1 like " IPv6 address format in 464XLAT is presented in the following format. +-----------------------------------------------+---------------+ | XLAT prefix(96) | IPv4(32) | +-----------------------------------------------+---------------+ Source address and destination address have IPv4 address embedded in the low-order 32 bits of the IPv6 address. " NAT64 RFCs does not make such requirements or place such a prefix restriction, and IMO these effectively become normative for an implementation. If they're not needed then they shouldn't be there. Way of resolving the issue(s) would be to: - Document the experiment, the set-up and the results. - Separately document any/all specific requirements, assumptions or operations that are not covered by existing RFCs (eg the requirement for XLAT to use a /96 prefix) -Woj. On 27 February 2012 18:36, Cameron Byrne wrote: > V6ops, > > We received some feedback that draft-ietf-v6ops-464xlat-00 has > normative language which is not correct for an informational draft. > > When pressed on where the normative language was, we were told that > the issue was use of RFC 2119 key words. > > In reviewing RFC 2119, I could not find any limitation on how the > keywords are used > > In reviewing RFC 4677, it seems the RFC 2119 drives clarity and > therefore should be used to "tell it like it is" > > Further review of published Informational work, i see that RFC 6092 is > informational and uses RFC 2119 key words > > My preference is to keep the key words in 464XLAT for clarity of the > document. > > Does the WG have an issue with this or statement on how this violates > for complies with norms? > > Thanks, > > Cameron > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --20cf300fb153b5ce1c04baa76d43 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The draft contains text like
 "In the 464XLA=
T environment, the PLAT and CLAT SHOULD include an IPv6
   Fragment Header, since IPv4 host does not set the DF bit. "
Wh= at more it contains specific text in Section 6.1 like

"
IPv6 address format in 464XLAT is presented in the foll= owing format. +-----------------------------------------------+---------------+ | XLAT prefix(96) | IPv4(32) | +-----------------------------------------------+---------------+ Source address and destination address have IPv4 address embedded in the low-order 32 bits of the IPv6 address. "

NAT64 RFCs does= not make such requirements or place such a prefix restriction, and IMO the= se effectively become normative for an implementation. If they're not n= eeded then they shouldn't be there.

Way of resolving the issue(s) would be to:
- Document the experiment= , the set-up=A0 and the results.
- Separately document any/all specific = requirements, assumptions or operations that are not covered by existing RF= Cs (eg the requirement for XLAT to use a /96 prefix)

-Woj.
=A0

On 27 February 2012 18:3= 6, Cameron Byrne <cb.list6@gmail.com> wrote:
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--20cf300fb153b5ce1c04baa76d43-- From washam.fan@gmail.com Wed Mar 7 05:56:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C9C21F87E0 for ; Wed, 7 Mar 2012 05:56:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.913 X-Spam-Level: X-Spam-Status: No, score=-2.913 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_74=0.6, 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 bpf4Hy9oavAL for ; Wed, 7 Mar 2012 05:56:28 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDB321F87DB for ; Wed, 7 Mar 2012 05:56:17 -0800 (PST) Received: by wicr5 with SMTP id r5so3555707wic.31 for ; Wed, 07 Mar 2012 05:56:16 -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:content-transfer-encoding; bh=aXwbaJYRMf4AB9/KnNkeOKB3sutPtTwWJB4KOUexV34=; b=CFZAQEA8Hoip7OgQP9zltcBcX5vbE8OjkRM/pVjWKf4LnCTkLfV7XwuB1xQQqaMr6P /YrQ5vrTQRjHy6OtP2/j7AUx3mGe9SnXv8kAoQhtdW7/U4WNpr4XYafvaisIyiPcbLQU 64IicXDgppHjZ+PPL3RMP1oX40a3KYouVf+3IQ9CC7HrEWuG/30EYny9Zx1N22P1PdsX 25aHe6ZkHyjVxRAMja44gMK1VVb5ntOXQTvkm6BMy5OIy1vhpg3WEX+PipJM4nWtVb2X 9vsPN9sAVUIsiLuEQoeTCd92V5DTsS0P4eM5274JpswzDtpccr/Eox4hQ1ImFDvTyoR7 +eAg== MIME-Version: 1.0 Received: by 10.216.139.229 with SMTP id c79mr1288434wej.16.1331128576523; Wed, 07 Mar 2012 05:56:16 -0800 (PST) Received: by 10.216.205.169 with HTTP; Wed, 7 Mar 2012 05:56:16 -0800 (PST) In-Reply-To: <2D31D894-5885-4BDB-B082-036517FDE0BE@huawei.com> References: <20120303200905.31106.67929.idtracker@ietfa.amsl.com> <4F529C37.9090900@bogus.com> <4F52AE79.9020504@si6networks.com> <2D31D894-5885-4BDB-B082-036517FDE0BE@huawei.com> Date: Wed, 7 Mar 2012 21:56:16 +0800 Message-ID: From: Washam Fan To: Tina TSOU Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: New Version Notification for draft-lopez-v6ops-dc-ipv6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 13:56:29 -0000 Hi, I don't think the problem the draft is trying to address is clear. Deduced from the solution, It seems to me the problem is to address the IPv6 Internet accessing IPv4 network scenario. The solution seems to me, is a variant of stateful NAT64. Compared to stateful NAT64, the proposal is doing address translation whileas the statefull NAT64 is doing address+port translation. And I don't know why the proposal is integral to LB. It could have been an individual module even it could be co-located with LB. Finally, I feel it would be some overlap between this draft and draft-carpenter-v6ops-icp-guidance. Thanks, washam 2012/3/7 Tina TSOU : > For your comments. > http://datatracker.ietf.org/doc/draft-lopez-v6ops-dc-ipv6/ > > Sent from my iPad > > Begin forwarded message: > > From: > Date: March 5, 2012 5:09:49 PM PST > To: > Cc: , , <18918588897@189.cn> > Subject: New Version Notification for draft-lopez-v6ops-dc-ipv6-00.txt > > A new version of I-D, draft-lopez-v6ops-dc-ipv6-00.txt has been successfu= lly > submitted by Tina Tsou and posted to the IETF repository. > > Filename: =A0 =A0 draft-lopez-v6ops-dc-ipv6 > Revision: =A0 =A0 00 > Title: =A0 =A0 =A0 =A0 DC Migration to IPv6 > Creation date: =A0 =A0 2012-03-05 > WG ID: =A0 =A0 =A0 =A0 Individual Submission > Number of pages: 10 > > Abstract: > =A0=A0This document describes the issues, possible solutions, and > =A0=A0opportunities in Data Center (DC) migration from IPv4 to IPv6. =A0I= t > =A0=A0focuses on the DC infrastructure itself, its operation, and the > =A0=A0aspects related to DC interconnection through IPv6. =A0It does not > =A0=A0consider the particular mechanisms for making Internet services > =A0=A0provided by applications hosted in the DC available through IPv6 > =A0=A0beyond the specific aspects related to how their deployed on the DC > =A0=A0infrastructure. > > =A0=A0Apart from facilitating the migration procedure itself, the > =A0=A0mechanisms outlined here are intended to make this migration as > =A0=A0transparent as possible (if not completely transparent) to > =A0=A0applications and services running on the DC infrastructure, as well > =A0=A0as to take advantage of IPv6 features to simplify DC operations, > =A0=A0internally and across the Internet. > > > > > The IETF Secretariat > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From victor.kuarsingh@gmail.com Wed Mar 7 06:14:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD12E21F86F2 for ; Wed, 7 Mar 2012 06:14:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, 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 n-Is3DXYuPcb for ; Wed, 7 Mar 2012 06:14:12 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id C112E21F86BB for ; Wed, 7 Mar 2012 06:14:11 -0800 (PST) Received: by lagj5 with SMTP id j5so8940321lag.31 for ; Wed, 07 Mar 2012 06:14:10 -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=VsTxoFC29LGx6F0Dc9SQT6GORN5/vQNNGjVNMfcAL4k=; b=gvBJ0kB3dTABR11gr9vsN+H6ZOOFNyV6QuS629iJzZ6YtISYupxUxBosTecOP4VdJR 7A0Hal12CbdLl45wARuu4M8EgB7yOMEefKM+RC8oNwPJ0YEOI2ZIuXOKLiiJ1TKrQ9dq NHaVxmaOpkA1C6aGR1pjJnmE0hVll/8d3PzVZssU9XoUZMRnPTa8N9DCB5m5zxEKD3lP VhFfdQcg4EB032yaV+tlOsA7me5nNNXbtlKTwzUUE+gMv8nTTkCxEr9nAIZrQ7CTilaW E2KgEkC1VoW+fUZQSm880JSTPhxB6ak/Xzms4G1wvH3xpHPaUZpmPNUKxoTSfuIuTxRH 6AOA== MIME-Version: 1.0 Received: by 10.152.147.202 with SMTP id tm10mr1606791lab.49.1331129179770; Wed, 07 Mar 2012 06:06:19 -0800 (PST) Received: by 10.112.35.18 with HTTP; Wed, 7 Mar 2012 06:06:19 -0800 (PST) In-Reply-To: References: Date: Wed, 7 Mar 2012 09:06:19 -0500 Message-ID: From: Victor Kuarsingh To: Washam Fan Content-Type: multipart/alternative; boundary=e89a8f235311e90f4e04baa7a9a3 Cc: v6ops@ietf.org Subject: Re: [v6ops] Updated Feedback on Wireline Incremental IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 14:14:13 -0000 --e89a8f235311e90f4e04baa7a9a3 Content-Type: text/plain; charset=ISO-8859-1 Washam, On Wed, Mar 7, 2012 at 12:38 AM, Washam Fan wrote: > Hi Victor, > > I am aware of this draft > http://tools.ietf.org/html/draft-ietf-softwire-dslite-deployment-02, > and think that it should be referenced in section 5.5.1. > Yes, I have already spoken to those authors and am planning to include the reference in the next revision. > > The paragraph just before section 5.5.1 is talking about the scenario > where NAT444 CGN co-located with AFTR. Could you elaborate on this > scenario? I could not come up with any cases for this scenario. > I can expand on this point if you like. The use case is for operators which may start with NAT444 and then begin to support DS-LIte as a follow-up. In this case, not all devices will support/ or be moved to DS-Lite (AFTR supported) services. In this case, the operator *may* want to co-locate such services. Since these devices will be managed by the operator in a special way (vs. standard network routers) and will have logging and other requirements, keeping theses functions in a common place it advantageous (but not necessarily required). regards, Victor K --e89a8f235311e90f4e04baa7a9a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Washam,

On Wed, Mar 7, 2012 at 12:38 AM, = Washam Fan <wa= sham.fan@gmail.com> wrote:
Hi Victor,

I am aware of this draft
http://tools.ietf.org/html/draft-ietf-softwire-dslit= e-deployment-02,
and think that it should be referenced in section 5.5.1.

Yes, I have already spoken to those authors and am planning to inclu= de the reference in the next revision.
=A0

The paragraph just before section 5.5.1 is talking about the scenario
where NAT444 CGN co-located with AFTR. Could you elaborate on this
scenario? I could not come up with any cases for this scenario.

I can expand on this point if you like. The use case is for o= perators which may start with NAT444 and then begin to support DS-LIte as a= follow-up.=A0 In this case, not all devices will support/ or be moved to D= S-Lite (AFTR supported) services.=A0 In this case, the operator *may* want = to co-locate such services.

Since these devices will be managed by the operator in a special way (v= s. standard network routers) and will have logging and other requirements, = keeping theses functions in a common place it advantageous (but not necessa= rily required).

regards,

Victor K

--e89a8f235311e90f4e04baa7a9a3-- From washam.fan@gmail.com Wed Mar 7 06:40:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D195A21F867B for ; Wed, 7 Mar 2012 06:39:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.336 X-Spam-Level: X-Spam-Status: No, score=-3.336 tagged_above=-999 required=5 tests=[AWL=0.263, 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 YVGbC3Q1OJ4p for ; Wed, 7 Mar 2012 06:39:59 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5D78B21F8678 for ; Wed, 7 Mar 2012 06:39:56 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so3977644wgb.13 for ; Wed, 07 Mar 2012 06:39:53 -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:content-transfer-encoding; bh=89L98yN8GuZz2ywFXS8Nc4yxKdQj74sGR05pjmSbmDk=; b=ROaN8AuFVVbZTkDWTB3y/HZPlB+N+wDMV76CUBxp/u/bFmrP2w6oF4Q+EIZPwpGpn0 L0RvysnEhjy5tGsYUGIauZOCz28TZiOn4r9gSnrawltDLzwemBle+QryeqeDvSC+EO9q eLCRFT1c3b1va2OrI3ARM/EDZmyDISGZnW5qLGzmU9Nv0VryEsVE72tXhnAO0b+McxJ9 V+iQZWkJCDEgzkwdSIOH9uyA1BR+I70hpC+YEmbCG878Tdq6qtCBQJWCGZaFbqV3on2o //0UglvwZZq34VF7ipTlcxSwO2PbY+Ac77EsJrk/2WQXRZEKCNoijQn5Q4ET3qlRazPX TYQg== MIME-Version: 1.0 Received: by 10.180.90.212 with SMTP id by20mr4422659wib.12.1331131193728; Wed, 07 Mar 2012 06:39:53 -0800 (PST) Received: by 10.216.205.169 with HTTP; Wed, 7 Mar 2012 06:39:53 -0800 (PST) In-Reply-To: References: Date: Wed, 7 Mar 2012 22:39:53 +0800 Message-ID: From: Washam Fan To: Victor Kuarsingh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] Updated Feedback on Wireline Incremental IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 14:40:00 -0000 Hi Victor, 2012/3/7 Victor Kuarsingh : > Washam, > > On Wed, Mar 7, 2012 at 12:38 AM, Washam Fan wrote: >> >> Hi Victor, >> >> I am aware of this draft >> http://tools.ietf.org/html/draft-ietf-softwire-dslite-deployment-02, >> and think that it should be referenced in section 5.5.1. > > > Yes, I have already spoken to those authors and am planning to include th= e > reference in the next revision. > >> >> >> The paragraph just before section 5.5.1 is talking about the scenario >> where NAT444 CGN co-located with AFTR. Could you elaborate on this >> scenario? I could not come up with any cases for this scenario. > > > I can expand on this point if you like. The use case is for operators whi= ch > may start with NAT444 and then begin to support DS-LIte as a follow-up.= =A0 In > this case, not all devices will support/ or be moved to DS-Lite (AFTR > supported) services.=A0 In this case, the operator *may* want to co-locat= e > such services. > > Since these devices will be managed by the operator in a special way (vs. > standard network routers) and will have logging and other requirements, > keeping theses functions in a common place it advantageous (but not > necessarily required). I got what you said. But what does "co-located" mean here? Are you meaning combination of CGN part of NAT444 and CGN part of AFTR into a generic CGN? These two parts are a slight different since CGN of AFTR depends on IPv6 addresses in addition to IPv4 addresses for translation. If these two parts are still separate instead of combined into one, I think "co-located" is only meaning CGN and AFTR are connected within a chassis instead of via cable or fibre. Thanks, washam From victor.kuarsingh@gmail.com Wed Mar 7 06:46:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDCBA21F8802 for ; Wed, 7 Mar 2012 06:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, 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 IhPokZDXQ7o8 for ; Wed, 7 Mar 2012 06:46:16 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 492FA21F86B5 for ; Wed, 7 Mar 2012 06:46:16 -0800 (PST) Received: by lagj5 with SMTP id j5so8978858lag.31 for ; Wed, 07 Mar 2012 06:46:15 -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=2FqdO+7eRKzY/YX5wyXMbJ9QPk+U0afteES+r/ZDuGU=; b=sU9VaCj9NMqKv3RTpVARULWiYQdU6TMRGXSDs5Ry9EO1T3qeLcrUH4l6yD0wY6JZXZ IMpfPTZ5B2q8/wKA2ZeGKunojEpWdjfYLqyDoW6czB9ET8zHhIqo5XLxEbeeTj2P2VjT 9RjJKYIQEG2yAzSLdHDtca9VyXMTsNxOr4Gi8fQZ/gar3Y+Ac//8J/d3IZlvtrMXsI1j WExj2PNE3rQJtuiEvcMA6pXO+iBGbNluoP1w6BETHNpZOzoI51mYnDJuH2c/OP2iJleD PZrsS/lhomyIbZr7IVY26wnNnGSCiUD6iQGPTC/eqryelmj9ACtIpbNnzsfbyYAfY3ls DzMg== MIME-Version: 1.0 Received: by 10.152.133.144 with SMTP id pc16mr1640891lab.0.1331131575258; Wed, 07 Mar 2012 06:46:15 -0800 (PST) Received: by 10.112.35.18 with HTTP; Wed, 7 Mar 2012 06:46:15 -0800 (PST) In-Reply-To: References: Date: Wed, 7 Mar 2012 09:46:15 -0500 Message-ID: From: Victor Kuarsingh To: Washam Fan Content-Type: multipart/alternative; boundary=f46d042dfea9b1500a04baa838a3 Cc: v6ops@ietf.org Subject: Re: [v6ops] Updated Feedback on Wireline Incremental IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 14:46:18 -0000 --f46d042dfea9b1500a04baa838a3 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 7, 2012 at 9:39 AM, Washam Fan wrote: > > > > I got what you said. But what does "co-located" mean here? Are you > meaning combination of CGN part of NAT444 and CGN part of AFTR into a > generic CGN? These two parts are a slight different since CGN of AFTR > depends on IPv6 addresses in addition to IPv4 addresses for > translation. If these two parts are still separate instead of combined > into one, I think "co-located" is only meaning CGN and AFTR are > connected within a chassis instead of via cable or fibre. > Washam, Ok, I see what your question was. My intent was to describe that the two functions would be geographically co-located and/or could be in a common chassis. I was not intending to describe an integration of the two technologies. I am not saying a vendor may not be crafty and do this, but that is out of my control or interest. I could clean up the text to be more specific. If I addressed this (with sufficient text), would you be ok with that? regards, Victor K --f46d042dfea9b1500a04baa838a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Mar 7, 2012 at 9:39 AM, Washam F= an <washam.fan= @gmail.com> wrote:



I got what you said. But what does "co-located" m= ean here? Are you
meaning combination of CGN part of NAT444 and CGN part of AFTR into a
generic CGN? These two parts are a slight different since CGN of AFTR
depends on IPv6 addresses in addition to IPv4 addresses for
translation. If these two parts are still separate instead of combined
into one, I think "co-located" is only meaning CGN and AFTR are connected within a chassis instead of via cable or fibre.
<= div>
Washam,

Ok, I see what your question was.=A0 My intent was t= o describe that the two functions would be geographically co-located and/or= could be in a common chassis.=A0 I was not intending to describe an integr= ation of the two technologies.=A0 I am not saying a vendor may not be craft= y and do this, but that is out of my control or interest.

I could clean up the text to be more specific.=A0 If I addressed this (= with sufficient text), would you be ok with that?

regards,

Vi= ctor K

--f46d042dfea9b1500a04baa838a3-- From cb.list6@gmail.com Wed Mar 7 07:31:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31CD21F86E0 for ; Wed, 7 Mar 2012 07:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.437 X-Spam-Level: X-Spam-Status: No, score=-3.437 tagged_above=-999 required=5 tests=[AWL=0.162, 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 yCbttlz4r1El for ; Wed, 7 Mar 2012 07:31:41 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 72BED21F86DF for ; Wed, 7 Mar 2012 07:31:41 -0800 (PST) Received: by pbbrq13 with SMTP id rq13so681010pbb.31 for ; Wed, 07 Mar 2012 07:31:41 -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:content-transfer-encoding; bh=nUj5eTkBy7iZ7bR9Br4RVp3nyAtttlcORj1T7MzCjlY=; b=rDWeu98l/7b4CNDL8A4uf9JjocMzrULBdpr6hyJpITENAlRm39K9aJ0H+31666Mw7q FdFCseUkfhutdA4LGrAq2kLMuBHiLvkQPE0SZetmvnTpOD5Ws0NKBBnlmRNeLJ+1Lc7m PSkd9ipz7GeeQ86HYjS2uewCTmmOLS73davPvX3cEmuG+d8QJapLJ4UTSL/7sViByaLc o5G7k1vM//7UBz20coGj87Y3EeqqNGSHf5nXlJtOQTcY7AV0VsXYoUGza/LUUW3biKOs 9PBYGYVuXHj7Zz8Llol05SSZSTw1xf8C+QDynzn9bTxsWY3Gog53+U8DqMXYBb/i9SJZ iPow== MIME-Version: 1.0 Received: by 10.68.216.138 with SMTP id oq10mr4122796pbc.85.1331134301093; Wed, 07 Mar 2012 07:31:41 -0800 (PST) Received: by 10.142.163.16 with HTTP; Wed, 7 Mar 2012 07:31:41 -0800 (PST) In-Reply-To: References: Date: Wed, 7 Mar 2012 07:31:41 -0800 Message-ID: From: Cameron Byrne To: Wojciech Dec Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Ops WG Subject: Re: [v6ops] Nomative language in draft-ietf-v6ops-464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 15:31:42 -0000 Woj, On Wed, Mar 7, 2012 at 5:49 AM, Wojciech Dec wrote: > The draft contains text like > > "In the 464XLAT environment, the PLAT and CLAT SHOULD include an IPv6 > Fragment Header, since IPv4 host does not set the DF bit. " > This will be changed in future revisions, RFC 2119 key words will be remove= d. > What more it contains specific text in Section 6.1 like > > " > > IPv6 address format in 464XLAT is presented in the following format. > > +-----------------------------------------------+---------------+ > | XLAT prefix(96) | IPv4(32) | > +-----------------------------------------------+---------------+ > > Source address and destination address have IPv4 address embedded in the > low-order 32 bits of the IPv6 address. " > > NAT64 RFCs does not make such requirements or place such a prefix > restriction, and IMO these effectively become normative for an > implementation. If they're not needed then they shouldn't be there. > This is not a NAT64 RFC. This an informational draft that states how a scenario defined in a NAT64 RFC may be used. The above IPv6 address format is defined as one of many possible in RFC 6052. The above format for convenience of implementation is recommended in 464XLAT. I hope this recommendation of how a deployment scenario in an informational document is not a problem for you. The point of a deployment scenario / architecture is that it constrains all possible options into a reasonable set that work together in a particular way. In general, /96 speeds up discover and helps create uniformity in the 464XLAT deployment model. We do not see any specific utility in support anything beyond a /96 for the purposes for which 464XLAT is scoped. > Way of resolving the issue(s) would be to: > - Document the experiment, the set-up=A0 and the results. draft-ietf-v6ops-464xlat-00 is not an experiment report, it is an informational architecture which happens to be supported by running code and informal network deployment reports > - Separately document any/all specific requirements, assumptions or > operations that are not covered by existing RFCs (eg the requirement for > XLAT to use a /96 prefix) > draft-ietf-v6ops-464xlat-00 does not create any new technology or standards. I don't believe an information document that does not use RFC 2119 language and recommends a /96 prefix (which is one of many defined in RFC 6052) should be an issue. If it is, please let me know why. CB > -Woj. > > From hiromi@inetcore.com Wed Mar 7 07:39:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59DE521F8734 for ; Wed, 7 Mar 2012 07:39:31 -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_22=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 mNBKmXXXsaTY for ; Wed, 7 Mar 2012 07:39:30 -0800 (PST) Received: from inc.inetcore.com (inc.inetcore.com [IPv6:2403:2000:1:1::11]) by ietfa.amsl.com (Postfix) with ESMTP id 21A6C21F86D5 for ; Wed, 7 Mar 2012 07:39:21 -0800 (PST) Received: from [192.168.22.15] (141.21.148.210.bf.2iij.net [210.148.21.141]) by inc.inetcore.com (Postfix) with ESMTPSA id BE6302CE9A4; Thu, 8 Mar 2012 00:39:20 +0900 (JST) From: Ruri Hiromi Content-Type: multipart/signed; boundary="Apple-Mail=_D9531B5B-CF4D-44A8-BC3B-0F6EC3088DB8"; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 8 Mar 2012 00:39:19 +0900 Message-Id: <77792581-451F-4E6E-A3F1-4BAC46AA725C@inetcore.com> To: fred@cisco.com, Joel jaeggli Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Cc: v6ops@ietf.org Subject: [v6ops] slot request at Paris meeting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 15:39:31 -0000 --Apple-Mail=_D9531B5B-CF4D-44A8-BC3B-0F6EC3088DB8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear chairs We(WIDE Project) will update our draft, = draft-hazeyama-widecamp-ipv6-only-experience-00. We would like to talk about it and allow me(or Hazeyama) to have 10 = minutes slot in IETF83. Regards, ------------------- Ruri Hiromi= --Apple-Mail=_D9531B5B-CF4D-44A8-BC3B-0F6EC3088DB8 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDuDCCA7Qw ggMdoAMCAQICAgCwMA0GCSqGSIb3DQEBBAUAMHYxCzAJBgNVBAYTAkpQMQ4wDAYDVQQIEwVUb2t5 bzEbMBkGA1UEChMSSW50ZWMgTmV0Q29yZSBJbmMuMRkwFwYDVQQDExBJbnRlYyBOZXRDb3JlIENB MR8wHQYJKoZIhvcNAQkBFhBub2NAaW5ldGNvcmUuY29tMB4XDTExMDgwODA0MjA1OFoXDTEzMDkw NjA0MjA1OFowbzELMAkGA1UEBhMCSlAxDjAMBgNVBAgTBVRva3lvMRswGQYDVQQKExJJbnRlYyBO ZXRDb3JlIEluYy4xDzANBgNVBAMTBmhpcm9taTEiMCAGCSqGSIb3DQEJARYTaGlyb21pQGluZXRj b3JlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAu1A0kuEMuSfwH/5ERlsLpir7xmqC qePSNr8ciJmZZYwQ66AAOzrT6mk9IQNPQlAE3gdFlSiBtQi4W+czFvGXM0lM0a3EfbgmHZcFiSVT PBWB6mmmKxq5uxCpz7UzvcxoQ7CtP9TEvlp2qX1xQzOo3Lsvh/43iSEqGTX0SEVn4V0CAwEAAaOC AVYwggFSMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIF4DAqBgNV HSUBAf8EIDAeBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMCwGCWCGSAGG+EIBDQQfFh1P cGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUt0nlPTSdBhgK4FvCWhj7yTN1 aMMwgagGA1UdIwSBoDCBnYAUk5fdgIJO7sYhJGcH6L30dxS7aI6heqR4MHYxCzAJBgNVBAYTAkpQ MQ4wDAYDVQQIEwVUb2t5bzEbMBkGA1UEChMSSW50ZWMgTmV0Q29yZSBJbmMuMRkwFwYDVQQDExBJ bnRlYyBOZXRDb3JlIENBMR8wHQYJKoZIhvcNAQkBFhBub2NAaW5ldGNvcmUuY29tggkA0ePIyRyR uGcwDQYJKoZIhvcNAQEEBQADgYEAhy6ATj73MLLfQxtI1yAmlDgqELRgOH8Ki9XkYNdcfuQyFwk4 DKVsewWYLXBIgAaPUYGblcll+844+nBQKLUQh1puTmDzRXYUsBtmbd7aa2YXBqoRwoo/fCrzM1Ts Wd5fQf+oplyZdmDBWH5rtrI9O/h278lhexgtga+6cH1q/WsxggKhMIICnQIBATB8MHYxCzAJBgNV BAYTAkpQMQ4wDAYDVQQIEwVUb2t5bzEbMBkGA1UEChMSSW50ZWMgTmV0Q29yZSBJbmMuMRkwFwYD VQQDExBJbnRlYyBOZXRDb3JlIENBMR8wHQYJKoZIhvcNAQkBFhBub2NAaW5ldGNvcmUuY29tAgIA sDAJBgUrDgMCGgUAoIIBezAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMjAzMDcxNTM5MjBaMCMGCSqGSIb3DQEJBDEWBBSNvrl2qBaBCWajVD7/+LUowrIHbDCBiwYJ KwYBBAGCNxAEMX4wfDB2MQswCQYDVQQGEwJKUDEOMAwGA1UECBMFVG9reW8xGzAZBgNVBAoTEklu dGVjIE5ldENvcmUgSW5jLjEZMBcGA1UEAxMQSW50ZWMgTmV0Q29yZSBDQTEfMB0GCSqGSIb3DQEJ ARYQbm9jQGluZXRjb3JlLmNvbQICALAwgY0GCyqGSIb3DQEJEAILMX6gfDB2MQswCQYDVQQGEwJK UDEOMAwGA1UECBMFVG9reW8xGzAZBgNVBAoTEkludGVjIE5ldENvcmUgSW5jLjEZMBcGA1UEAxMQ SW50ZWMgTmV0Q29yZSBDQTEfMB0GCSqGSIb3DQEJARYQbm9jQGluZXRjb3JlLmNvbQICALAwDQYJ KoZIhvcNAQEBBQAEgYBKY2brFRAnT0PViPeMPDevl2q8EpPqb5aot5m6t6jAnGSGhFX/BaeokPmL 69m58awJU1pbQRUOPcJ8cgeaHQUcf0plS0fEDOfcivLzkEb5leCV8mcfA1O70xI5ecSS1P8D3wYx W6gSIc//VJ8EplAiMu6IEWTFvQqBu8cTdCCs9gAAAAAAAA== --Apple-Mail=_D9531B5B-CF4D-44A8-BC3B-0F6EC3088DB8-- From brian.e.carpenter@gmail.com Wed Mar 7 11:15:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F97511E8086 for ; Wed, 7 Mar 2012 11:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.893 X-Spam-Level: X-Spam-Status: No, score=-102.893 tagged_above=-999 required=5 tests=[AWL=-0.494, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-1, 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 ZAFEb1V4-8sI for ; Wed, 7 Mar 2012 11:15:11 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACCF11E807F for ; Wed, 7 Mar 2012 11:15:11 -0800 (PST) Received: by werb10 with SMTP id b10so5229569wer.31 for ; Wed, 07 Mar 2012 11:15:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uGIHmFQe9vM/ehS17n7/O6113CENBuUph9acEVyV3Uw=; b=gcjXZCeXUCf8DKr0DuNWZW4vykmOvHK1IB0zipiRJ4TEdp+99v1SZEWahAxWA5xQn9 7nFmqn4hsRNoAiziCiR8WzktggXXrWitPnaO88d8gtWf2GJ3gEQFyiJmVza8LHpnZrbT 8i4gHVhPvbgFTktUcygA8M9hr0x4oxrVsoDLme1Qy/r5Fgx4PVGqRFwF7zXiiOXd32nA uSTW1grTcBI38XL38Xr5vNbR5CuLtwMbPbNaA7jgXADDDWo8QkyL8PJ5OyyuXffvEXQK zAeltqQp3LIAxkfuNhFlaKjRf/JuSOBCdzg8eg34Xe+mU3mAvKOpJ51tDPKuOZ/HcERv mg+Q== Received: by 10.180.104.137 with SMTP id ge9mr6242351wib.20.1331147710705; Wed, 07 Mar 2012 11:15:10 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id fw5sm37914761wib.0.2012.03.07.11.15.06 (version=SSLv3 cipher=OTHER); Wed, 07 Mar 2012 11:15:09 -0800 (PST) Message-ID: <4F57B3AB.4070707@gmail.com> Date: Thu, 08 Mar 2012 08:14:51 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Washam Fan References: <20120303200905.31106.67929.idtracker@ietfa.amsl.com> <4F529C37.9090900@bogus.com> <4F52AE79.9020504@si6networks.com> <2D31D894-5885-4BDB-B082-036517FDE0BE@huawei.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: New Version Notification for draft-lopez-v6ops-dc-ipv6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 19:15:12 -0000 Hi Washam, > Finally, I feel it would be some overlap between this draft and > draft-carpenter-v6ops-icp-guidance. I think the goals are rather different. -icp-guidance is aimed at describing a process and a range of options for ICPs. -dc-ipv6 seems to be describing quite specific scenarios. Also data centres are not the same thing as ICPs. There's also overlap with draft-chkpvc-enterprise-incremental-ipv6, although that is aimed at any kind of enterprise. The three documents should aim at being consistent with each other, but I think they have different audiences. I would definitely be against combining them, because that would take for ever. Regards Brian On 2012-03-08 02:56, Washam Fan wrote: > Hi, > > I don't think the problem the draft is trying to address is clear. > Deduced from the solution, It seems to me the problem is to address > the IPv6 Internet accessing IPv4 network scenario. The solution seems > to me, is a variant of stateful NAT64. Compared to stateful NAT64, the > proposal is doing address translation whileas the statefull NAT64 is > doing address+port translation. And I don't know why the proposal is > integral to LB. It could have been an individual module even it could > be co-located with LB. > > Finally, I feel it would be some overlap between this draft and > draft-carpenter-v6ops-icp-guidance. > > Thanks, > washam > > 2012/3/7 Tina TSOU : >> For your comments. >> http://datatracker.ietf.org/doc/draft-lopez-v6ops-dc-ipv6/ >> >> Sent from my iPad >> >> Begin forwarded message: >> >> From: >> Date: March 5, 2012 5:09:49 PM PST >> To: >> Cc: , , <18918588897@189.cn> >> Subject: New Version Notification for draft-lopez-v6ops-dc-ipv6-00.txt >> >> A new version of I-D, draft-lopez-v6ops-dc-ipv6-00.txt has been successfully >> submitted by Tina Tsou and posted to the IETF repository. >> >> Filename: draft-lopez-v6ops-dc-ipv6 >> Revision: 00 >> Title: DC Migration to IPv6 >> Creation date: 2012-03-05 >> WG ID: Individual Submission >> Number of pages: 10 >> >> Abstract: >> This document describes the issues, possible solutions, and >> opportunities in Data Center (DC) migration from IPv4 to IPv6. It >> focuses on the DC infrastructure itself, its operation, and the >> aspects related to DC interconnection through IPv6. It does not >> consider the particular mechanisms for making Internet services >> provided by applications hosted in the DC available through IPv6 >> beyond the specific aspects related to how their deployed on the DC >> infrastructure. >> >> Apart from facilitating the migration procedure itself, the >> mechanisms outlined here are intended to make this migration as >> transparent as possible (if not completely transparent) to >> applications and services running on the DC infrastructure, as well >> as to take advantage of IPv6 features to simplify DC operations, >> internally and across the Internet. >> >> >> >> >> The IETF Secretariat >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From wesley.george@twcable.com Wed Mar 7 12:29:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B877321F85AE for ; Wed, 7 Mar 2012 12:29:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.737 X-Spam-Level: X-Spam-Status: No, score=-0.737 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, 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 L-qtkFQooyNK for ; Wed, 7 Mar 2012 12:29:54 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1A721F859F for ; Wed, 7 Mar 2012 12:29:52 -0800 (PST) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.73,547,1325480400"; d="scan'208";a="350277182" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 07 Mar 2012 15:29:33 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Wed, 7 Mar 2012 15:29:52 -0500 From: "George, Wes" To: Fred Baker , v6ops v6ops WG Date: Wed, 7 Mar 2012 15:29:54 -0500 Thread-Topic: [v6ops] Agenda discussion Thread-Index: Acz7VeybKyYxleOdTyqoStrVPYanVQBR7mpg Message-ID: References: <25E067CE-65BF-462E-9A45-2D09451256F9@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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] Agenda discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 20:29:54 -0000 IMO draft-ma-v6ops-terminal-test is not ready for discussion in Paris. I'll= provide a few comments separately on that one, but I don't want those to b= e misconstrued as interest in seeing the draft presented. I'm interested in draft-gundavelli, but I think it has an awful lot of plac= eholders for it to be effectively discussed in Paris. Perhaps next meeting,= unless the authors are currently working on a -01 draft to be posted later= this week that fills in some of the gaps. Regarding draft-lopez, As with previous documents of this type, I think the= re's a certain burden of proof that we need another cookbook document on "I= Pv6 deployment in [foo]" and that IETF is the proper venue for it. As other= work (like ARMD) in IETF is finding out, "datacenter" is such a nebulous c= oncept that purporting to represent a deployment strategy for a datacenter = is probably simplistic and overbroad. It will either be so generic that it = won't say anything new, or it will be so specific that it won't be applicab= le to very many applications, and either way that's not overly helpful. While Brian is correct in his observation than ICP !=3D datacenter, many of= the same things are suggested/useful, so I do think that there's a lot of = overlap. The authors either need to propose solving for a different problem= space, or identify a way to eliminate the overlap. Thanks, Wes George > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= Fred > Baker > Sent: Monday, March 05, 2012 11:59 PM > To: v6ops v6ops WG > Subject: Re: [v6ops] Agenda discussion > > Downloading the new drafts, I observe three new ones: > > -rw-rw-r-- 1 fred fred 10823 Mar 5 17:46 draft-ma-v6ops-terminal-test= - > 00.txt > -rw-rw-r-- 1 fred fred 18058 Mar 6 08:44 draft-gundavelli-v6ops-commu= nity- > wifi-svcs-00.txt > -rw-rw-r-- 1 fred fred 21172 Mar 6 10:08 draft-lopez-v6ops-dc-ipv6-00= .txt > > (the date/time stamp reflects the fact that I'm in Japan and therefore a = day > ahead) > > In each case, I will be looking for list traffic related to them as my cu= e for > agenda time. Authors, please provoke list traffic... > > > On Mar 6, 2012, at 1:46 PM, Fred Baker wrote: > > > Stated in no particular order, we have the following documents that mee= t > these criteria: > > - not in the IESG process somewhere > > - posted or updated since IETF 82 > > - have had list discussion since IETF 82 or responds to discussion at = IETF > 82 > > > > At this point, I take them as our agenda at IETF 83. If I am missing a > document (if you have posted it since Sunday, I may well be missing it), > please remind me. > > > > > > http://tools.ietf.org/html/draft-carpenter-v6ops-icp-guidance > > "IPv6 Guidance for Internet Content and Application Service Providers"= , > > Brian Carpenter, Sheng Jiang, 22-Feb-12 > > > > No presentation expected, but the authors would like working group adop= tion. > We need to decide whether we want to do that. > > > > http://tools.ietf.org/html/draft-carpenter-v6ops-label-balance > > "Using the IPv6 Flow Label for Server Load Balancing", Brian Carpenter= , > > Sheng Jiang, Willy Tarreau, 17-Jan-12 > > > > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat > > "464XLAT: Combination of Stateful and Stateless Translation", Masataka > > Mawatari, Masanobu Kawashima, Cameron Byrne, 14-Feb-12 > > > > http://tools.ietf.org/html/draft-ietf-v6ops-6204bis > > "Basic Requirements for IPv6 Customer Edge Routers", Barbara Stark, > > Chris Donley, Hemant Singh, Ole Troan, Wes Beebee, 22-Dec-11 > > > > http://tools.ietf.org/html/draft-ietf-v6ops-ivi-icmp-address > > "Stateless Source Address Mapping for ICMPv6 Packets", Xing Li, Congxi= ao > > Bao, Dan Wing, Ramji Vaithianathan, Geoff Huston, 24-Feb-12 > > > > http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation > > "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)"= , > > Fernando Gont, 3-Mar-12 > > > > http://tools.ietf.org/html/draft-ietf-v6ops-wireline-incremental-ipv6 > > "Wireline Incremental IPv6", Victor Kuarsingh, Lee Howard, 1-Feb-12 > > > > In the coming week, I am told to expect one additional -00 draft, and I > could imagine other drafts being updated. I will be looking for those dra= fts > to meet the criteria above as well, but please drop the chairs a note. > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From wesley.george@twcable.com Wed Mar 7 12:47:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 254A421F8766 for ; Wed, 7 Mar 2012 12:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.241 X-Spam-Level: X-Spam-Status: No, score=-0.241 tagged_above=-999 required=5 tests=[AWL=-0.378, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=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 mNmi+Xy0bIpO for ; Wed, 7 Mar 2012 12:47:37 -0800 (PST) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDFF21F8762 for ; Wed, 7 Mar 2012 12:47:36 -0800 (PST) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.73,547,1325480400"; d="scan'208";a="333876971" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 07 Mar 2012 15:47:08 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Wed, 7 Mar 2012 15:47:35 -0500 From: "George, Wes" To: "fred@cisco.com" , "v6ops@ietf.org" Date: Wed, 7 Mar 2012 15:47:38 -0500 Thread-Topic: [v6ops] new draft: draft-ma-v6ops-terminal-test Thread-Index: Acz64BlhEnK/T9mDSYWEn4l4RqpitABvMvAw Message-ID: References: <201203051455.q25Et1V04869@ftpeng-update.cisco.com> In-Reply-To: <201203051455.q25Et1V04869@ftpeng-update.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ma-v6ops-terminal-test@tools.ietf.org" Subject: Re: [v6ops] new draft: draft-ma-v6ops-terminal-test X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 20:47:38 -0000 The format of the draft is making it difficult to identify the point that i= t is trying to make. The fact that you did some IPv6 testing and that some devices didn't work a= s expected is not a surprise, and should not be a focus for the draft, nor = should your methodology. If I'm reading this properly, what you're saying is that there are some hos= ts that do some "strange" things with DNS and DHCP (like continuing to ask = for an A record once it has received a AAAA and initiated a connection usin= g IPv6). However, that may or may not be interesting to IETF. If the observed behavior was seen on some hosts/applications, but not all, = chances are quite good that it's just a poor implementation, open a bug wit= h the implementer. We don't typically do "name and shame" documents here th= at point out a failure with a specific implementation, and even then, this = one doesn't actually name names, meaning that it's impossible to lean on sa= id implementer for a fix via public humiliation. If the observed behavior was seen on all hosts/applications, then it's a qu= estion of whether this is expected behavior or not based on the existing do= cumented standards, and if not, what fix action needs to be taken. Unless you can point to a specific portion of the existing standards that t= he host is implementing properly but are creating undesired consequences, e= ither because they are unclear, incomplete, or because there's an unforesee= n problem, there's no action for IETF to take to resolve it. If there is a scaling issue (too many DNS queries), explain that clearly, i= ncluding what steps can be taken either operationally or at a protocol leve= l to fix it. This again gives the IETF a problem to solve, rather than this= simply being a test report. Thanks, Wes George > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > fred@cisco.com > Sent: Monday, March 05, 2012 9:55 AM > To: v6ops@ietf.org > Cc: draft-ma-v6ops-terminal-test@tools.ietf.org > Subject: [v6ops] new draft: draft-ma-v6ops-terminal-test > > > A new draft has been posted, at http://tools.ietf.org/html/draft-ma-v6ops= - > terminal-test. Please take a look at it and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From fred@cisco.com Wed Mar 7 13:29:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF5D11E80A3 for ; Wed, 7 Mar 2012 13:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.466 X-Spam-Level: X-Spam-Status: No, score=-108.466 tagged_above=-999 required=5 tests=[AWL=0.933, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_24=0.6, 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 4OtjlFFJXq7J for ; Wed, 7 Mar 2012 13:29:05 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id AC03D11E80A2 for ; Wed, 7 Mar 2012 13:29:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=430; q=dns/txt; s=iport; t=1331155745; x=1332365345; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=wxBZ0N9YvXyCc6/lt2XTPasCu0vHyFy9rToa4WisaLc=; b=C5s7tvjFtd22TX5PEfEknN7V4ZYixkNjH2nGnae6I1sq1BeoEwXKF60w UQQnxra/YBLPa1WGZv19enHpk+ZOWohmPRIJKAqf9BNQm0MNQKP7YgG4L PJjjlp1mHEolLFRsdJHH1ctyCXT+jLLuO8EtesMWrkX+tplro2Ze1ANfw E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAL7SV09Io8UY/2dsb2JhbABEti2CCgEBAQMBEgEnPwULC0ZXBjWHYQWaWQGNLpFdkAxjBIhQjHGFZIozgnI X-IronPort-AV: E=Sophos;i="4.73,548,1325462400"; d="scan'208";a="7322354" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 07 Mar 2012 21:29:03 +0000 Received: from robin-gw-192-168-12.cisco.com (tky-vpn-client-231-203.cisco.com [10.70.231.203]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q27LSMMq003450; Wed, 7 Mar 2012 21:29:02 GMT Received: from [127.0.0.1] by robin-gw-192-168-12.cisco.com (PGP Universal service); Thu, 08 Mar 2012 06:29:02 +0900 X-PGP-Universal: processed; by robin-gw-192-168-12.cisco.com on Thu, 08 Mar 2012 06:29:02 +0900 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <77792581-451F-4E6E-A3F1-4BAC46AA725C@inetcore.com> Date: Thu, 8 Mar 2012 06:29:01 +0900 Message-Id: References: <77792581-451F-4E6E-A3F1-4BAC46AA725C@inetcore.com> To: Ruri Hiromi X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] slot request at Paris meeting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 21:29:05 -0000 I think that would be interesting. Please do. Note that you have until = Monday to do the update. On Mar 8, 2012, at 12:39 AM, Ruri Hiromi wrote: > Dear chairs >=20 > We(WIDE Project) will update our draft, = draft-hazeyama-widecamp-ipv6-only-experience-00. > We would like to talk about it and allow me(or Hazeyama) to have 10 = minutes slot in IETF83. >=20 > Regards, >=20 > ------------------- > Ruri Hiromi From fred@cisco.com Wed Mar 7 14:22:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F5C11E80AF for ; Wed, 7 Mar 2012 14:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.999 X-Spam-Level: X-Spam-Status: No, score=-108.999 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 LITbM0Kuj+VH for ; Wed, 7 Mar 2012 14:22:49 -0800 (PST) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id CD95D11E80AE for ; Wed, 7 Mar 2012 14:22:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=5755; q=dns/txt; s=iport; t=1331158969; x=1332368569; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=Uslwy7jjzMBpsxX36wMdwh1Ip2nXGqDIKimGqTjOMt4=; b=VZLypuDG79xXAcZV/cOYTX1uFutfD98mh3AomX+8YeDYVWOhVHFoHjfz KsLxyM11Y4blwExMaVeguaUU3kfnlbJW7EvL+0M8N3XepCuLa/Vk3P0Qv ZmG1uj8vm16uXLXtGQymzZe3VCj3Sl7vRLHMrxu7ddI1EaU12jp429X9y M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAJLeV09Io8UY/2dsb2JhbAA6CrYuggoBAQEDAQEBAQsEAScrCQQHBQcECxEEAQEBJwcnHwkIBhMUDodhBQuaPwGfDIogCYVjYwSIUIxxhWSKM4JygU0 X-IronPort-AV: E=Sophos;i="4.73,548,1325462400"; d="scan'208";a="7323627" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 07 Mar 2012 22:22:47 +0000 Received: from robin-gw-192-168-12.cisco.com (tky-vpn-client-231-203.cisco.com [10.70.231.203]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q27MMjNv031795; Wed, 7 Mar 2012 22:22:46 GMT Received: from [127.0.0.1] by robin-gw-192-168-12.cisco.com (PGP Universal service); Thu, 08 Mar 2012 07:22:46 +0900 X-PGP-Universal: processed; by robin-gw-192-168-12.cisco.com on Thu, 08 Mar 2012 07:22:46 +0900 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Thu, 8 Mar 2012 07:22:30 +0900 Message-Id: <4D71B71D-6A40-4D95-8448-A0FF3E8EBBA6@cisco.com> References: <25E067CE-65BF-462E-9A45-2D09451256F9@cisco.com> To: "George, Wes" X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops v6ops WG Subject: Re: [v6ops] Agenda discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 22:22:50 -0000 On Mar 8, 2012, at 5:29 AM, George, Wes wrote: > IMO draft-ma-v6ops-terminal-test is not ready for discussion in Paris. = I'll provide a few comments separately on that one, but I don't want = those to be misconstrued as interest in seeing the draft presented. >=20 > I'm interested in draft-gundavelli, but I think it has an awful lot of = placeholders for it to be effectively discussed in Paris. Perhaps next = meeting, unless the authors are currently working on a -01 draft to be = posted later this week that fills in some of the gaps. >=20 > Regarding draft-lopez, As with previous documents of this type, I = think there's a certain burden of proof that we need another cookbook = document on "IPv6 deployment in [foo]" and that IETF is the proper venue = for it. As other work (like ARMD) in IETF is finding out, "datacenter" = is such a nebulous concept that purporting to represent a deployment = strategy for a datacenter is probably simplistic and overbroad. It will = either be so generic that it won't say anything new, or it will be so = specific that it won't be applicable to very many applications, and = either way that's not overly helpful. > While Brian is correct in his observation than ICP !=3D datacenter, = many of the same things are suggested/useful, so I do think that there's = a lot of overlap. The authors either need to propose solving for a = different problem space, or identify a way to eliminate the overlap. Thanks for the view. I'll discuss that with the authors. > Thanks, >=20 > Wes George >=20 >=20 >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of Fred >> Baker >> Sent: Monday, March 05, 2012 11:59 PM >> To: v6ops v6ops WG >> Subject: Re: [v6ops] Agenda discussion >>=20 >> Downloading the new drafts, I observe three new ones: >>=20 >> -rw-rw-r-- 1 fred fred 10823 Mar 5 17:46 = draft-ma-v6ops-terminal-test- >> 00.txt >> -rw-rw-r-- 1 fred fred 18058 Mar 6 08:44 = draft-gundavelli-v6ops-community- >> wifi-svcs-00.txt >> -rw-rw-r-- 1 fred fred 21172 Mar 6 10:08 = draft-lopez-v6ops-dc-ipv6-00.txt >>=20 >> (the date/time stamp reflects the fact that I'm in Japan and = therefore a day >> ahead) >>=20 >> In each case, I will be looking for list traffic related to them as = my cue for >> agenda time. Authors, please provoke list traffic... >>=20 >>=20 >> On Mar 6, 2012, at 1:46 PM, Fred Baker wrote: >>=20 >>> Stated in no particular order, we have the following documents that = meet >> these criteria: >>> - not in the IESG process somewhere >>> - posted or updated since IETF 82 >>> - have had list discussion since IETF 82 or responds to discussion = at IETF >> 82 >>>=20 >>> At this point, I take them as our agenda at IETF 83. If I am missing = a >> document (if you have posted it since Sunday, I may well be missing = it), >> please remind me. >>>=20 >>>=20 >>> http://tools.ietf.org/html/draft-carpenter-v6ops-icp-guidance >>> "IPv6 Guidance for Internet Content and Application Service = Providers", >>> Brian Carpenter, Sheng Jiang, 22-Feb-12 >>>=20 >>> No presentation expected, but the authors would like working group = adoption. >> We need to decide whether we want to do that. >>>=20 >>> http://tools.ietf.org/html/draft-carpenter-v6ops-label-balance >>> "Using the IPv6 Flow Label for Server Load Balancing", Brian = Carpenter, >>> Sheng Jiang, Willy Tarreau, 17-Jan-12 >>>=20 >>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat >>> "464XLAT: Combination of Stateful and Stateless Translation", = Masataka >>> Mawatari, Masanobu Kawashima, Cameron Byrne, 14-Feb-12 >>>=20 >>> http://tools.ietf.org/html/draft-ietf-v6ops-6204bis >>> "Basic Requirements for IPv6 Customer Edge Routers", Barbara Stark, >>> Chris Donley, Hemant Singh, Ole Troan, Wes Beebee, 22-Dec-11 >>>=20 >>> http://tools.ietf.org/html/draft-ietf-v6ops-ivi-icmp-address >>> "Stateless Source Address Mapping for ICMPv6 Packets", Xing Li, = Congxiao >>> Bao, Dan Wing, Ramji Vaithianathan, Geoff Huston, 24-Feb-12 >>>=20 >>> http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation >>> "Implementation Advice for IPv6 Router Advertisement Guard = (RA-Guard)", >>> Fernando Gont, 3-Mar-12 >>>=20 >>> = http://tools.ietf.org/html/draft-ietf-v6ops-wireline-incremental-ipv6 >>> "Wireline Incremental IPv6", Victor Kuarsingh, Lee Howard, 1-Feb-12 >>>=20 >>> In the coming week, I am told to expect one additional -00 draft, = and I >> could imagine other drafts being updated. I will be looking for those = drafts >> to meet the criteria above as well, but please drop the chairs a = note. >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. From washam.fan@gmail.com Wed Mar 7 18:10:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E037B21E8029 for ; Wed, 7 Mar 2012 18:10:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.358 X-Spam-Level: X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[AWL=0.241, 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 e5lyBxHUCmuf for ; Wed, 7 Mar 2012 18:10:48 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7B15421E8039 for ; Wed, 7 Mar 2012 18:10:48 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so2093wgb.13 for ; Wed, 07 Mar 2012 18:10: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:content-transfer-encoding; bh=iGZrmh597WiabD8UMJVusZGqEhT73qO0g8OAJ1lDSW0=; b=Rw1d7FK+UqjDRG/eWUHfHFO1Y1b9KUpfYVYi6WPZET3gHXTheVXEaO8ZDmaCHYCRXR Nq+wbIKNtvskatlQLBDs1DoGzTZabnF+7hbJCCrBqlIlBi8EH6Gz+lWWm4XgPNck/nu4 hPzfewUHSw8r8mbtjmwPTjiFlG8kNX/lE24lVdkUNUS8QLdadZQbkGQguQ2NY1vVEpqy IM1afQXvXXClgbLk6QENX9/AYFSEzKZewPGTcP0T1996Dd56fCneaeVaIrtSDmCxwsxK V8uuytsYXlpUuuyVb+Z8ScaHDe2k4jIqjjmbfoPf4LH8iGPYTMp6k2wJnTpVGxKM7Jje yamQ== MIME-Version: 1.0 Received: by 10.180.95.34 with SMTP id dh2mr8333751wib.15.1331172647640; Wed, 07 Mar 2012 18:10:47 -0800 (PST) Received: by 10.216.205.169 with HTTP; Wed, 7 Mar 2012 18:10:47 -0800 (PST) In-Reply-To: References: Date: Thu, 8 Mar 2012 10:10:47 +0800 Message-ID: From: Washam Fan To: Victor Kuarsingh Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] Updated Feedback on Wireline Incremental IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 02:10:54 -0000 Hi Victor, 2012/3/7 Victor Kuarsingh : > > > On Wed, Mar 7, 2012 at 9:39 AM, Washam Fan wrote: >> >> >> >> >> I got what you said. But what does "co-located" mean here? Are you >> meaning combination of CGN part of NAT444 and CGN part of AFTR into a >> generic CGN? These two parts are a slight different since CGN of AFTR >> depends on IPv6 addresses in addition to IPv4 addresses for >> translation. If these two parts are still separate instead of combined >> into one, I think "co-located" is only meaning CGN and AFTR are >> connected within a chassis instead of via cable or fibre. > > > Washam, > > Ok, I see what your question was.=A0 My intent was to describe that the t= wo > functions would be geographically co-located and/or could be in a common > chassis.=A0 I was not intending to describe an integration of the two > technologies.=A0 I am not saying a vendor may not be crafty and do this, = but > that is out of my control or interest. > > I could clean up the text to be more specific.=A0 If I addressed this (wi= th > sufficient text), would you be ok with that? Yes, please. That would address my concern. Thanks, washam > regards, > > Victor K > From victor.kuarsingh@gmail.com Wed Mar 7 18:33:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75AD721E8029 for ; Wed, 7 Mar 2012 18:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.26 X-Spam-Level: X-Spam-Status: No, score=-3.26 tagged_above=-999 required=5 tests=[AWL=0.339, 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 Egnx2jCgKSzC for ; Wed, 7 Mar 2012 18:33:43 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id CB82521E8020 for ; Wed, 7 Mar 2012 18:33:42 -0800 (PST) Received: by vbbez10 with SMTP id ez10so21097vbb.31 for ; Wed, 07 Mar 2012 18:33:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to :mime-version:content-type:content-transfer-encoding; bh=tuWSGtYOpMMFeZxcjZQkjbZIqB4znaamzTox4/SaGG8=; b=bZEv7PYgG59KNCwvs8kLinc9yOpfAIgPdj0/il2CVAz6vRq4xixatAdDKxN3x9R2aC V/61c1fpPq2J8au34Jb3g2wK2CTmnxP8/DCeFcOei7W9QqkZtTQbSjK5/8EBkgj2RoTO 6W9WJGFRE0i+sSlCp++qwlGR0x65UPTing32H+0vH9oDFJdzCdqrioOB1zbG0KjWqCrE DwDCJR+i1MSmrP1LUz8NBunFmUBWXpP6i4LKETFp0+Xv9YdLe7k+AURkpPB0d8mVG0Sl X3mvVh2JQJdYdGowrJA/MuygfxGYijCc+YE8s5UgzXxjiBIlI1Ua7BbP8YHbwLrEYxWS UWXw== Received: by 10.52.17.82 with SMTP id m18mr7062920vdd.89.1331174022210; Wed, 07 Mar 2012 18:33:42 -0800 (PST) Received: from [192.168.100.205] ([67.224.83.162]) by mx.google.com with ESMTPS id t8sm615144vdh.11.2012.03.07.18.33.35 (version=SSLv3 cipher=OTHER); Wed, 07 Mar 2012 18:33:41 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Wed, 07 Mar 2012 21:33:35 -0500 From: Victor Kuarsingh To: "George, Wes" , Fred Baker , v6ops v6ops WG Message-ID: Thread-Topic: [v6ops] Agenda discussion In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [v6ops] Agenda discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 02:33:43 -0000 On 12-03-07 3:29 PM, "George, Wes" wrote: > >I'm interested in draft-gundavelli, but I think it has an awful lot of >placeholders for it to be effectively discussed in Paris. Perhaps next >meeting, unless the authors are currently working on a -01 draft to be >posted later this week that fills in some of the gaps. I am interested in this draft as well - timely topic . I agree with Wes that there is a significant amount of text which needs to be created to have a qualify discussion on this. Sections which I think need more content for discussion 4.7 Mobility in WLAN. A very important part of the WiFi discussion. 4.8 Mobility across WLAN and Macro Access. This is a complex topic. I am not sure how much detail needs to be put down here. I think the content is a bit light (but maybe that what the authors were looking for - not sure). I would say (perhaps) a reference to 3GPP 23.327 may be applicable. 4.10 Service and Network Security. This is also a large part of the WiFi discussion. If we put security items here, do we still need section 7? (Security Considerations) 4.11 Should this say "Lawful Intercept"? Vs Legal Intercept? I guess this section could be short (I guess requirements here will differ greatly by country/region. Also, related to 4.7, but likely a separate section is around RF planning for WiFi deployment. This may include comments/topics around what channels to use, 2.4GHz vs. 5.0GHz ranges etc. A section around potential encryption requirements? (maybe in security section or separate?) Regards, Victor Kuarsingh From cathy.zhou@huawei.com Wed Mar 7 18:57:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC77621E801E for ; Wed, 7 Mar 2012 18:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.679 X-Spam-Level: X-Spam-Status: No, score=-6.679 tagged_above=-999 required=5 tests=[AWL=-1.280, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_74=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 aomH6Ge+h4zm for ; Wed, 7 Mar 2012 18:57:43 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 742B721F850C for ; Wed, 7 Mar 2012 18:57:34 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0J00LD5PJSXH@szxga04-in.huawei.com> for v6ops@ietf.org; Thu, 08 Mar 2012 10:57:28 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0J00KOGPJSH8@szxga04-in.huawei.com> for v6ops@ietf.org; Thu, 08 Mar 2012 10:57:28 +0800 (CST) Received: from szxeml214-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHR05638; Thu, 08 Mar 2012 10:57:28 +0800 Received: from SZXEML426-HUB.china.huawei.com (10.72.61.34) by szxeml214-edg.china.huawei.com (172.24.2.29) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 08 Mar 2012 10:56:47 +0800 Received: from SZXEML527-MBX.china.huawei.com ([169.254.3.10]) by szxeml426-hub.china.huawei.com ([10.72.61.34]) with mapi id 14.01.0323.003; Thu, 08 Mar 2012 10:57:17 +0800 Date: Thu, 08 Mar 2012 02:57:17 +0000 From: "Cathy Zhou(Qian)" X-Originating-IP: [10.70.39.60] To: Washam Fan , Tina TSOU Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: zh-CN Content-transfer-encoding: quoted-printable Accept-Language: zh-CN, en-US Thread-topic: [v6ops] Fwd: New Version Notification for draft-lopez-v6ops-dc-ipv6-00.txt Thread-index: AQHM/DApbLA+bohBLkOBmnddFUMWJpZeVaQAgAFXRJCAAAivwA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" Subject: [v6ops] FW: Fwd: New Version Notification for draft-lopez-v6ops-dc-ipv6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 02:57:43 -0000 Hi Washam, -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of W= asham Fan Sent: Wednesday, March 07, 2012 9:56 PM To: Tina TSOU Cc: v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-lopez-v6ops-dc= -ipv6-00.txt Hi, I don't think the problem the draft is trying to address is clear. Deduced from the solution, It seems to me the problem is to address the IPv6 Internet accessing IPv4 network scenario. The solution seems to me, is a variant of stateful NAT64. Compared to stateful NAT64, the proposal is doing address translation whileas the statefull NAT64 is doing address+port translation.=20 //This solution is similar to stateful NAT64, but there are some difference= s. We say that is NAT64-Lite for this solution, using the same IPv6 prefix = for the DC. For each service, IPv4 address is embedded into the IPv6 addres= s (e.g. VSIPv6 formed: IPv6 prefix + VSIPv4+ other bits) . Via VSIPv4 embed= ded into VSIPv6, we don't need DNS64. In addition, the binding tables are o= nly based on host IPv6 address, so we can reduce the number of binding tabl= es(compared to RFC 6146-binding tables based on TCP/UDP sessions). And I don't know why the proposal is integral to LB. It could have been an individual module even it could be co-located with LB. //You are right. It could be an individual module or co-located with LB. Finally, I feel it would be some overlap between this draft and draft-carpenter-v6ops-icp-guidance. //Data Center and ICP are two different things, although they may use some = similar IPv6 transition technologies, e.g., NAT. Best Regards, Cathy Thanks, washam 2012/3/7 Tina TSOU : > For your comments. > http://datatracker.ietf.org/doc/draft-lopez-v6ops-dc-ipv6/ > > Sent from my iPad > > Begin forwarded message: > > From: > Date: March 5, 2012 5:09:49 PM PST > To: > Cc: , , <18918588897@189.cn> > Subject: New Version Notification for draft-lopez-v6ops-dc-ipv6-00.txt > > A new version of I-D, draft-lopez-v6ops-dc-ipv6-00.txt has been successfu= lly > submitted by Tina Tsou and posted to the IETF repository. > > Filename: =A0 =A0 draft-lopez-v6ops-dc-ipv6 > Revision: =A0 =A0 00 > Title: =A0 =A0 =A0 =A0 DC Migration to IPv6 > Creation date: =A0 =A0 2012-03-05 > WG ID: =A0 =A0 =A0 =A0 Individual Submission > Number of pages: 10 > > Abstract: > =A0=A0This document describes the issues, possible solutions, and > =A0=A0opportunities in Data Center (DC) migration from IPv4 to IPv6. =A0I= t > =A0=A0focuses on the DC infrastructure itself, its operation, and the > =A0=A0aspects related to DC interconnection through IPv6. =A0It does not > =A0=A0consider the particular mechanisms for making Internet services > =A0=A0provided by applications hosted in the DC available through IPv6 > =A0=A0beyond the specific aspects related to how their deployed on the DC > =A0=A0infrastructure. > > =A0=A0Apart from facilitating the migration procedure itself, the > =A0=A0mechanisms outlined here are intended to make this migration as > =A0=A0transparent as possible (if not completely transparent) to > =A0=A0applications and services running on the DC infrastructure, as well > =A0=A0as to take advantage of IPv6 features to simplify DC operations, > =A0=A0internally and across the Internet. > > > > > The IETF Secretariat > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From washam.fan@gmail.com Wed Mar 7 19:20:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D548B21E8040 for ; Wed, 7 Mar 2012 19:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.782 X-Spam-Level: X-Spam-Status: No, score=-2.782 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_74=0.6, 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 Gc7nnbW0jeru for ; Wed, 7 Mar 2012 19:20:56 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id D4CB521E802B for ; Wed, 7 Mar 2012 19:20:55 -0800 (PST) Received: by wgbdr13 with SMTP id dr13so27848wgb.13 for ; Wed, 07 Mar 2012 19:20:55 -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:content-transfer-encoding; bh=D3/sqLVuzF9lzXt1Y57VOiNnNyFQK5Qx03XFvjem/Jw=; b=hJRuHrlITX8NZ9WJoGB1/USKJsZWSDsJSuyD6RTxjCOiSUU8CYq8uqkDfeib5ZpN7I hrj075WlJSC23qndC3C0nXmCDg2/9pxvRriSfQbwsuhhEszkCyT/bL6Q+1CgaQop898E Uv2FhAlfjdXPUy8OftALfm7zTY1+RiKQV26JkNEERJla8k9cGeecsGffsY69l+kn6xAr B2Dw/89YsAlhz3stIXtUnmGpL/YprWfX5RMUyJRMXpxrUHFvYqC4S2Sxk1is8gJiKaAU dBihhkx3UAs+xhrUNPUomJEnG4cHgXBAIh4f+/hTYIFUIgI4SkzhPd7c7P6iYRPCgsPT Pnjg== MIME-Version: 1.0 Received: by 10.180.82.132 with SMTP id i4mr31089444wiy.12.1331176854984; Wed, 07 Mar 2012 19:20:54 -0800 (PST) Received: by 10.216.205.169 with HTTP; Wed, 7 Mar 2012 19:20:54 -0800 (PST) In-Reply-To: References: <20120303200905.31106.67929.idtracker@ietfa.amsl.com> <4F529C37.9090900@bogus.com> <4F52AE79.9020504@si6networks.com> <2D31D894-5885-4BDB-B082-036517FDE0BE@huawei.com> Date: Thu, 8 Mar 2012 11:20:54 +0800 Message-ID: From: Washam Fan To: "Cathy Zhou(Qian)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: New Version Notification for draft-lopez-v6ops-dc-ipv6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 03:20:57 -0000 Hi Cathy, 2012/3/8 Cathy Zhou(Qian) : > Hi Wsham, > > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= Washam Fan > Sent: Wednesday, March 07, 2012 9:56 PM > To: Tina TSOU > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Fwd: New Version Notification for draft-lopez-v6ops-= dc-ipv6-00.txt > > Hi, > > I don't think the problem the draft is trying to address is clear. > Deduced from the solution, It seems to me the problem is to address > the IPv6 Internet accessing IPv4 network scenario. The solution seems > to me, is a variant of stateful NAT64. Compared to stateful NAT64, the > proposal is doing address translation whileas the statefull NAT64 is > doing address+port translation. > //This solution is similar to stateful NAT64, but there are some differen= ces. We say that is NAT64-Lite for this solution, using the same IPv6 prefi= x for the DC. For each service, IPv4 address is embedded into the IPv6 addr= ess (e.g. VSIPv6 formed: IPv6 prefix + VSIPv4+ other bits) . Via VSIPv4 emb= edded into VSIPv6, we don't need DNS64. I don't think so, DNS64 would be used for the v6 clients to get VSIPv6 of the target services they is wanting to access. Or Could you elaborate on how you publish those VSIPv6 to the v6 clients who is attempting to access the corresponding services located in DC? >In addition, the binding tables are only based on host IPv6 address, so we= can reduce the number of binding tables(compared to RFC 6146-binding table= s based on TCP/UDP sessions). Yes. That why I said it is doing classical NAT whileas standard NAT64 is doing NAPT. > And I don't know why the proposal is > integral to LB. It could have been an individual module even it could > be co-located with LB. > //You are right. It could be an individual module or co-located with LB. > > Finally, I feel it would be some overlap between this draft and > draft-carpenter-v6ops-icp-guidance. > //Data Center and ICP are two different things, although they may use som= e similar IPv6 transition technologies, e.g., NAT. > Yes. But they should be consistent just as Brian pointed out. Thanks, washam > > 2012/3/7 Tina TSOU : >> For your comments. >> http://datatracker.ietf.org/doc/draft-lopez-v6ops-dc-ipv6/ >> >> Sent from my iPad >> >> Begin forwarded message: >> >> From: >> Date: March 5, 2012 5:09:49 PM PST >> To: >> Cc: , , <18918588897@189.cn> >> Subject: New Version Notification for draft-lopez-v6ops-dc-ipv6-00.txt >> >> A new version of I-D, draft-lopez-v6ops-dc-ipv6-00.txt has been successf= ully >> submitted by Tina Tsou and posted to the IETF repository. >> >> Filename: =A0 =A0 draft-lopez-v6ops-dc-ipv6 >> Revision: =A0 =A0 00 >> Title: =A0 =A0 =A0 =A0 DC Migration to IPv6 >> Creation date: =A0 =A0 2012-03-05 >> WG ID: =A0 =A0 =A0 =A0 Individual Submission >> Number of pages: 10 >> >> Abstract: >> =A0=A0This document describes the issues, possible solutions, and >> =A0=A0opportunities in Data Center (DC) migration from IPv4 to IPv6. =A0= It >> =A0=A0focuses on the DC infrastructure itself, its operation, and the >> =A0=A0aspects related to DC interconnection through IPv6. =A0It does not >> =A0=A0consider the particular mechanisms for making Internet services >> =A0=A0provided by applications hosted in the DC available through IPv6 >> =A0=A0beyond the specific aspects related to how their deployed on the D= C >> =A0=A0infrastructure. >> >> =A0=A0Apart from facilitating the migration procedure itself, the >> =A0=A0mechanisms outlined here are intended to make this migration as >> =A0=A0transparent as possible (if not completely transparent) to >> =A0=A0applications and services running on the DC infrastructure, as wel= l >> =A0=A0as to take advantage of IPv6 features to simplify DC operations, >> =A0=A0internally and across the Internet. >> >> >> >> >> The IETF Secretariat >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From cathy.zhou@huawei.com Wed Mar 7 19:57:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7168A21E8020 for ; Wed, 7 Mar 2012 19:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=-1.067, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_74=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 lu-8Bft+ufbR for ; Wed, 7 Mar 2012 19:57:11 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3AAFC21E800E for ; Wed, 7 Mar 2012 19:57:11 -0800 (PST) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0J00D8GSB1JX@szxga03-in.huawei.com> for v6ops@ietf.org; Thu, 08 Mar 2012 11:57:01 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0J00GX9S91ZO@szxga03-in.huawei.com> for v6ops@ietf.org; Thu, 08 Mar 2012 11:57:01 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHR11095; Thu, 08 Mar 2012 11:57:01 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 08 Mar 2012 11:56:51 +0800 Received: from SZXEML527-MBX.china.huawei.com ([169.254.3.10]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Thu, 08 Mar 2012 11:56:53 +0800 Date: Thu, 08 Mar 2012 03:56:52 +0000 From: "Cathy Zhou(Qian)" In-reply-to: X-Originating-IP: [10.70.39.60] To: Washam Fan Message-id: MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: zh-CN Content-transfer-encoding: quoted-printable Accept-Language: zh-CN, en-US Thread-topic: [v6ops] Fwd: New Version Notification for draft-lopez-v6ops-dc-ipv6-00.txt Thread-index: AQHM/NqDSuZqZpI3vkKsVwA8d7SeDpZfwzRw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20120303200905.31106.67929.idtracker@ietfa.amsl.com> <4F529C37.9090900@bogus.com> <4F52AE79.9020504@si6networks.com> <2D31D894-5885-4BDB-B082-036517FDE0BE@huawei.com> Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: New Version Notification for draft-lopez-v6ops-dc-ipv6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 03:57:12 -0000 Hi Washam, -----Original Message----- From: Washam Fan [mailto:washam.fan@gmail.com]=20 Sent: Thursday, March 08, 2012 11:21 AM To: Cathy Zhou(Qian) Cc: Tina TSOU; v6ops@ietf.org Subject: Re: [v6ops] Fwd: New Version Notification for draft-lopez-v6ops-dc= -ipv6-00.txt Hi Cathy, 2012/3/8 Cathy Zhou(Qian) : > Hi Wsham, > > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= Washam Fan > Sent: Wednesday, March 07, 2012 9:56 PM > To: Tina TSOU > Cc: v6ops@ietf.org > Subject: Re: [v6ops] Fwd: New Version Notification for draft-lopez-v6ops-= dc-ipv6-00.txt > > Hi, > > I don't think the problem the draft is trying to address is clear. > Deduced from the solution, It seems to me the problem is to address > the IPv6 Internet accessing IPv4 network scenario. The solution seems > to me, is a variant of stateful NAT64. Compared to stateful NAT64, the > proposal is doing address translation whileas the statefull NAT64 is > doing address+port translation. > //This solution is similar to stateful NAT64, but there are some differen= ces. We say that is NAT64-Lite for this solution, using the same IPv6 prefi= x for the DC. For each service, IPv4 address is embedded into the IPv6 addr= ess (e.g. VSIPv6 formed: IPv6 prefix + VSIPv4+ other bits) . Via VSIPv4 emb= edded into VSIPv6, we don't need DNS64. I don't think so, DNS64 would be used for the v6 clients to get VSIPv6 of the target services they is wanting to access. Or Could you elaborate on how you publish those VSIPv6 to the v6 clients who is attempting to access the corresponding services located in DC? [Cathy]: The VSIPv6 and VSIPv4 addresses will both be published to the clie= nt.=20 So the v6 client will get the address it needs without DNS64.=20 >In addition, the binding tables are only based on host IPv6 address, so we= can reduce the number of binding tables(compared to RFC 6146-binding table= s based on TCP/UDP sessions). Yes. That why I said it is doing classical NAT whileas standard NAT64 is doing NAPT. > And I don't know why the proposal is > integral to LB. It could have been an individual module even it could > be co-located with LB. > //You are right. It could be an individual module or co-located with LB. > > Finally, I feel it would be some overlap between this draft and > draft-carpenter-v6ops-icp-guidance. > //Data Center and ICP are two different things, although they may use som= e similar IPv6 transition technologies, e.g., NAT. > Yes. But they should be consistent just as Brian pointed out. [Cathy]: Agree. Best Regards, Cathy ZHOU Thanks, washam > > 2012/3/7 Tina TSOU : >> For your comments. >> http://datatracker.ietf.org/doc/draft-lopez-v6ops-dc-ipv6/ >> >> Sent from my iPad >> >> Begin forwarded message: >> >> From: >> Date: March 5, 2012 5:09:49 PM PST >> To: >> Cc: , , <18918588897@189.cn> >> Subject: New Version Notification for draft-lopez-v6ops-dc-ipv6-00.txt >> >> A new version of I-D, draft-lopez-v6ops-dc-ipv6-00.txt has been successf= ully >> submitted by Tina Tsou and posted to the IETF repository. >> >> Filename: =A0 =A0 draft-lopez-v6ops-dc-ipv6 >> Revision: =A0 =A0 00 >> Title: =A0 =A0 =A0 =A0 DC Migration to IPv6 >> Creation date: =A0 =A0 2012-03-05 >> WG ID: =A0 =A0 =A0 =A0 Individual Submission >> Number of pages: 10 >> >> Abstract: >> =A0=A0This document describes the issues, possible solutions, and >> =A0=A0opportunities in Data Center (DC) migration from IPv4 to IPv6. =A0= It >> =A0=A0focuses on the DC infrastructure itself, its operation, and the >> =A0=A0aspects related to DC interconnection through IPv6. =A0It does not >> =A0=A0consider the particular mechanisms for making Internet services >> =A0=A0provided by applications hosted in the DC available through IPv6 >> =A0=A0beyond the specific aspects related to how their deployed on the D= C >> =A0=A0infrastructure. >> >> =A0=A0Apart from facilitating the migration procedure itself, the >> =A0=A0mechanisms outlined here are intended to make this migration as >> =A0=A0transparent as possible (if not completely transparent) to >> =A0=A0applications and services running on the DC infrastructure, as wel= l >> =A0=A0as to take advantage of IPv6 features to simplify DC operations, >> =A0=A0internally and across the Internet. >> >> >> >> >> The IETF Secretariat >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From washam.fan@gmail.com Wed Mar 7 20:24:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0D1121E8018 for ; Wed, 7 Mar 2012 20:24:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, 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 W2qHHzEcc7HI for ; Wed, 7 Mar 2012 20:24:23 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACD421E800E for ; Wed, 7 Mar 2012 20:24:22 -0800 (PST) Received: by wicr5 with SMTP id r5so54318wic.31 for ; Wed, 07 Mar 2012 20:24:22 -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:content-transfer-encoding; bh=0DsdvFqJ+2wubiqVdUC+QrkwjDWjTvc4rEPX3INmTdU=; b=T4RW1FFkqzie3EC/jZXlk+wLn4ZB9ZLCCG5pgFOA0WHcm91Oqmy3VM6uT8PLSuQsEZ zZsdLqZOjEo0XsCJjTj6D4OTsLc9ztfIQP6SpOhiTtaVWgJVgSZhDR/HY5/PKwd4A+ie dhdarvy6cKmmS/t8+PKzqc87nrLdWn80CivauSMrcklj1WTUEtnYJbb+1DaKjVEawGaT 1dHXsInb3xVbER22UiBWD2sNPuRlMZjCL2Oq8ulGI5vWiDzLtIy2aVZM6EOm+LZqbbW5 d0GinsAzoxgm2RCRxAxgBBbSq+qB1wVu8Q/o3DLo2+cOiDBPsjVdCeHKpzrTC57Eh6lY J+8A== MIME-Version: 1.0 Received: by 10.180.90.212 with SMTP id by20mr9138119wib.12.1331180662282; Wed, 07 Mar 2012 20:24:22 -0800 (PST) Received: by 10.216.205.169 with HTTP; Wed, 7 Mar 2012 20:24:22 -0800 (PST) In-Reply-To: References: <20120303200905.31106.67929.idtracker@ietfa.amsl.com> <4F529C37.9090900@bogus.com> <4F52AE79.9020504@si6networks.com> <2D31D894-5885-4BDB-B082-036517FDE0BE@huawei.com> Date: Thu, 8 Mar 2012 12:24:22 +0800 Message-ID: From: Washam Fan To: "Cathy Zhou(Qian)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Fwd: New Version Notification for draft-lopez-v6ops-dc-ipv6-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 04:24:23 -0000 Hi Cathy, >> I don't think the problem the draft is trying to address is clear. >> Deduced from the solution, It seems to me the problem is to address >> the IPv6 Internet accessing IPv4 network scenario. The solution seems >> to me, is a variant of stateful NAT64. Compared to stateful NAT64, the >> proposal is doing address translation whileas the statefull NAT64 is >> doing address+port translation. >> //This solution is similar to stateful NAT64, but there are some differe= nces. We say that is NAT64-Lite for this solution, using the same IPv6 pref= ix for the DC. For each service, IPv4 address is embedded into the IPv6 add= ress (e.g. VSIPv6 formed: IPv6 prefix + VSIPv4+ other bits) . Via VSIPv4 em= bedded into VSIPv6, we don't need DNS64. > > I don't think so, DNS64 would be used for the v6 clients to get VSIPv6 > of the target services they is wanting to access. Or Could you > elaborate on how you publish those VSIPv6 to the v6 clients who is > attempting to access the corresponding services located in DC? > > [Cathy]: The VSIPv6 and VSIPv4 addresses will both be published to the cl= ient. > So the v6 client will get the address it needs without DNS64. Ok. Then would you mind to explicitly describe the publish process? IMHO, DNS64 would be better used for this purpose. Thanks, washam From sgundave@cisco.com Wed Mar 7 21:23:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25AB421E8042 for ; Wed, 7 Mar 2012 21:23:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.033 X-Spam-Level: X-Spam-Status: No, score=-9.033 tagged_above=-999 required=5 tests=[AWL=1.566, 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 jiyvmhor7vak for ; Wed, 7 Mar 2012 21:23:00 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF4721E8029 for ; Wed, 7 Mar 2012 21:23:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=883; q=dns/txt; s=iport; t=1331184180; x=1332393780; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=j36n33AkyhYD0qExEAu39YQZLP71QBxaj6TPxTuvbCE=; b=Ur6W1sK50juoZPeVuI1gztPma5tSZxGMB7rFcqBA32s+wFMtOzNoKuJK lcbtkTKVG2mYicDByZejgyNmDEWCAKgIquMniclDa5nVHD2+5O5ftJSBh CsoRJyV9uYxlaXbe4JfgBVmzPTwx5QQv7YV43OAefThEJdtOUq/rLjtmG 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAPhAWE+rRDoH/2dsb2JhbABDtSqBB4IKAQEBAwESAScCAUENAQiBHQEBBAESCQsOh2EEAQuaagGfEZBuBIhSjG+QF4ME X-IronPort-AV: E=Sophos;i="4.73,550,1325462400"; d="scan'208";a="32356512" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 08 Mar 2012 05:23:00 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q285N0OA022343; Thu, 8 Mar 2012 05:23:00 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Mar 2012 21:23:00 -0800 Received: from 10.32.246.211 ([10.32.246.211]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Thu, 8 Mar 2012 05:22:59 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 07 Mar 2012 21:22:57 -0800 From: Sri Gundavelli To: "George, Wes" , Fred Baker , v6ops v6ops WG Message-ID: Thread-Topic: [v6ops] Agenda discussion Thread-Index: Acz7VeybKyYxleOdTyqoStrVPYanVQBR7mpgABN3v7I= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 08 Mar 2012 05:23:00.0317 (UTC) FILETIME=[873A70D0:01CCFCEB] Subject: Re: [v6ops] Agenda discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 05:23:01 -0000 Hi George/Victor, On 3/7/12 12:29 PM, "George, Wes" wrote: > IMO draft-ma-v6ops-terminal-test is not ready for discussion in Paris. I'll > provide a few comments separately on that one, but I don't want those to be > misconstrued as interest in seeing the draft presented. > > I'm interested in draft-gundavelli, but I think it has an awful lot of > placeholders for it to be effectively discussed in Paris. Perhaps next > meeting, unless the authors are currently working on a -01 draft to be posted > later this week that fills in some of the gaps. > Ack. We have revised the draft and we plan to do one more rev before Monday and that should bring the draft to a point where we can have meaningful discussions in the Paris meeting. http://www.ietf.org/id/draft-gundavelli-v6ops-community-wifi-svcs-02.txt Regards Sri From wdec.ietf@gmail.com Wed Mar 7 23:59:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC03521E800C for ; Wed, 7 Mar 2012 23:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.203 X-Spam-Level: X-Spam-Status: No, score=-3.203 tagged_above=-999 required=5 tests=[AWL=0.395, 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 q3ypGa+vDBGM for ; Wed, 7 Mar 2012 23:59:55 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8C02121F8634 for ; Wed, 7 Mar 2012 23:59:55 -0800 (PST) Received: by qcsq13 with SMTP id q13so157694qcs.31 for ; Wed, 07 Mar 2012 23:59:55 -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 :content-type; bh=QAizNnnS7uztWxoHuO0g5n3ijB0bq1DCYPh+uMYgl60=; b=hZUlAHtrDS9OQFbbLtQFTOWnJdDAw4fOLLoZ0EwPlOPthd8z5fcQhTp6Hribotl1xK WPJMnoSPuQOlYm+q7twobcPwEs/82ewigHVKSuSYPt/47pSg15CKC0K7pBgagVDI+kjo GliQS1ccVX1K2bVUWKNBKWE5yGuBfdzLcJZIa6G2GdLk3q0VbW5wGcxbm47h6lgaIIoi DJnz72HBMTfyA588nMok25I1BPCNjsBIPqVGYnq2hFNk4p0bioWVWViil02cfwGyhsfv vggjISlb7eDXAtJ2E/VsYYylv18wc/bUarJfo5E+JFnxcKP0wFgpl2XqRM1BUfQkl3Y6 tZMg== MIME-Version: 1.0 Received: by 10.229.107.34 with SMTP id z34mr945167qco.135.1331193594906; Wed, 07 Mar 2012 23:59:54 -0800 (PST) Received: by 10.229.231.203 with HTTP; Wed, 7 Mar 2012 23:59:54 -0800 (PST) In-Reply-To: References: Date: Thu, 8 Mar 2012 08:59:54 +0100 Message-ID: From: Wojciech Dec To: Cameron Byrne , IPv6 Ops WG Content-Type: multipart/alternative; boundary=002354470b985a084e04bab6a927 Subject: [v6ops] Fwd: Nomative language in draft-ietf-v6ops-464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 07:59:56 -0000 --002354470b985a084e04bab6a927 Content-Type: text/plain; charset=ISO-8859-1 On 7 March 2012 16:31, Cameron Byrne wrote: > Woj, > > On Wed, Mar 7, 2012 at 5:49 AM, Wojciech Dec wrote: > > The draft contains text like > > > > "In the 464XLAT environment, the PLAT and CLAT SHOULD include an IPv6 > > Fragment Header, since IPv4 host does not set the DF bit. " > > > > This will be changed in future revisions, RFC 2119 key words will be > removed. > > > What more it contains specific text in Section 6.1 like > > > > " > > > > IPv6 address format in 464XLAT is presented in the following format. > > > > +-----------------------------------------------+---------------+ > > | XLAT prefix(96) | IPv4(32) | > > +-----------------------------------------------+---------------+ > > > > Source address and destination address have IPv4 address embedded in the > > low-order 32 bits of the IPv6 address. " > > > > NAT64 RFCs does not make such requirements or place such a prefix > > restriction, and IMO these effectively become normative for an > > implementation. If they're not needed then they shouldn't be there. > > > > This is not a NAT64 RFC. This an informational draft that states how > a scenario defined in a NAT64 RFC may be used. The above IPv6 address > format is defined as one of many possible in RFC 6052. The above > format for convenience of implementation is recommended in 464XLAT. I > hope this recommendation of how a deployment scenario in an > informational document is not a problem for you. The point of a > deployment scenario / architecture is that it constrains all possible > options into a reasonable set that work together in a particular way. > Building architecture specifications conforming only to very narrow deployment scenarios means that they will likely not work when taken outside of that environment. In the xlat464 case this very narrow deployment scenario appears to be the combined set of; a stateful core NAT46 device; use of only /96 prefix for address mapping; only private IPv4 addresses for end hosts/apps. I for one have no problem with someone choosing to set up their network to operate like that, and documenting publicly their setup/experiences. Also no problem with the use NAT64 stateless/stateful to solve the overall problem of "connect v4 to and across v6". Where I do start having problems is in seeking broad WG recommendations for effectively creating devices/implementations that *only* work within this specific set of constraints. > In general, /96 speeds up discover and helps create uniformity in the > 464XLAT deployment model. We do not see any specific utility in > support anything beyond a /96 for the purposes for which 464XLAT is > scoped. > Can you substantiate how a /96 helps speed up discovery, and not other prefix lengths, or operator assigned lengths? Why restrict the operator to this specific prefix length for both source and destination address mapping? The NAT64 authors, operators amongst them, didn't think that such a restriction was useful or necessary. > > > Way of resolving the issue(s) would be to: > > - Document the experiment, the set-up and the results. > > draft-ietf-v6ops-464xlat-00 is not an experiment report, it is an > informational architecture which happens to be supported by running > code and informal network deployment reports > > > - Separately document any/all specific requirements, assumptions or > > operations that are not covered by existing RFCs (eg the requirement for > > XLAT to use a /96 prefix) > > > > draft-ietf-v6ops-464xlat-00 does not create any new technology or > standards. I don't believe an information document that does not use > RFC 2119 language and recommends a /96 prefix (which is one of many > defined in RFC 6052) should be an issue. If it is, please let me know > why. > If this is a recommendation and not a spec, how would a regular stateless NAT64 device, like the CLAT claims to be, know that it should use a /96 as its source prefix for mapping v4? -Woj. CB > > > -Woj. > > > > > --002354470b985a084e04bab6a927 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On 7 March 2012 16:31, Cameron Byrne <cb.list6@gmail.com>= ; wrote:
Woj,

On Wed, Mar 7, 2012 at 5:49 AM, Wojciech Dec <wdec.ietf@gmail.com> wrote:
> The draft contains text like
>
> =A0"In the 464XLAT environment, the PLAT and CLAT SHOULD include = an IPv6
> =A0 =A0Fragment Header, since IPv4 host does not set the DF bit. "= ;
>

This will be changed in future revisions, RFC 2119 key words will be = removed.

> What more it contains specific text in Section 6.1 like
>
> "
>
> IPv6 address format in 464XLAT is presented in the following format. >
> =A0 =A0 =A0 =A0+-----------------------------------------------+------= ---------+
> =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0XLAT prefix(96) =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0IPv4(32) =A0 |
> =A0 =A0 =A0 =A0+-----------------------------------------------+------= ---------+
>
> Source address and destination address have IPv4 address embedded in t= he
> low-order 32 bits of the IPv6 address. "
>
> NAT64 RFCs does not make such requirements or place such a prefix
> restriction, and IMO these effectively become normative for an
> implementation. If they're not needed then they shouldn't be t= here.
>

This is not a NAT64 RFC. =A0This an informational draft that states h= ow
a scenario defined in a NAT64 RFC may be used. =A0The above IPv6 address format is defined as one of many possible in RFC 6052. =A0The above
format for convenience of implementation is recommended in 464XLAT. =A0I hope this recommendation of how a deployment scenario in an
informational document is not a problem for you. =A0The point of a
deployment scenario / architecture is that it constrains all possible
options into a reasonable set that work together in a particular way.

Building architecture specifications confor= ming only to very narrow deployment scenarios means that they will likely n= ot work when taken outside of that environment. In the xlat464 case this ve= ry narrow deployment scenario appears to be the combined set of; a stateful= core NAT46 device; use of only /96 prefix for address mapping; only privat= e IPv4 addresses for end hosts/apps.

I for one have no problem with someone choosing to set up their network= to operate like that, and documenting publicly their setup/experiences. Al= so no problem with the use NAT64 stateless/stateful to solve the overall pr= oblem of "connect v4 to and across v6". Where I do start having p= roblems is in seeking broad WG recommendations for effectively creating dev= ices/implementations that *only* work within this specific set of constrain= ts.


In general, /96 speeds up discover and helps create uniformity in the
464XLAT deployment model. =A0We do not see any specific utility in
support anything beyond a /96 for the purposes for which 464XLAT is
scoped.

Can you substantiate how a /96 helps= speed up discovery, and not other prefix lengths, or operator assigned len= gths? Why restrict the operator to this specific prefix length for both sou= rce and destination address mapping?
The NAT64 authors, operators amongst them, didn't think that such a res= triction was useful or necessary.
=A0

> Way of resolving the issue(s) would be to:
> - Document the experiment, the set-up=A0 and the results.

draft-ietf-v6ops-464xlat-00 is not an experiment report, it is an
informational architecture which happens to be supported by running
code and informal network deployment reports

> - Separately document any/all specific requirements, assumptions or > operations that are not covered by existing RFCs (eg the requirement f= or
> XLAT to use a /96 prefix)
>

draft-ietf-v6ops-464xlat-00 does not create any new technology or
standards. =A0I don't believe an information document that does not use=
RFC 2119 language and recommends a /96 prefix (which is one of many
defined in RFC 6052) should be an issue. =A0If it is, please let me know why.

If this is a recommendation and not a s= pec, how would a regular stateless NAT64 device, like the CLAT claims to be= , know that it should use a /96 as its source prefix for mapping v4?


-Woj.

CB

> -Woj.
>
>


--002354470b985a084e04bab6a927-- From cb.list6@gmail.com Thu Mar 8 00:03:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB4721F8673 for ; Thu, 8 Mar 2012 00:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.445 X-Spam-Level: X-Spam-Status: No, score=-3.445 tagged_above=-999 required=5 tests=[AWL=0.153, 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 Abv9tJlEnPT9 for ; Thu, 8 Mar 2012 00:03:23 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5870121F866D for ; Thu, 8 Mar 2012 00:03:23 -0800 (PST) Received: by pbbrq13 with SMTP id rq13so1390145pbb.31 for ; Thu, 08 Mar 2012 00:03: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 :content-type; bh=4WF2xcrUcjDRs+BjqgWOk82VKszOk0SVZ/97LQMReOY=; b=MOVrsGFk1QjxZGOephOOkyYWNSK0CLOOKAhfiHwOBV1Ub9oRQt4iBmqs2CkS2sB5iR jjrXzv2/Nyf3WXkAiwWKj5EzCyVMiV9iL+Pxzxhjn9ieWaPlk8iDRH6npQ4Qlc2XISxm g4ypsphIHWqEf1Mi98frgH35CTcPkQTK0jwqmmnOd6yFz4ezYWNtajH0AO0pxcKsZJ3G Ea5ZtivBsy87/0Diqiu3iRVnmmPfw7+/G8kuE60zKrH1eR8qE2BmhglMMp4UM3LFBmTm t378QDzX5L8o2RfsOQOEWYbvNumV6MTG3EgO0OSnLmOaEl3HWuC7NiW9K34pKLd1peGD dxpg== MIME-Version: 1.0 Received: by 10.68.241.102 with SMTP id wh6mr2644679pbc.148.1331193802980; Thu, 08 Mar 2012 00:03:22 -0800 (PST) Received: by 10.142.163.16 with HTTP; Thu, 8 Mar 2012 00:03:22 -0800 (PST) Received: by 10.142.163.16 with HTTP; Thu, 8 Mar 2012 00:03:22 -0800 (PST) In-Reply-To: References: Date: Thu, 8 Mar 2012 00:03:22 -0800 Message-ID: From: Cameron Byrne To: v6ops@ietf.org Content-Type: multipart/alternative; boundary=047d7b339d19c0fc8d04bab6b5db Subject: Re: [v6ops] Nomative language in draft-ietf-v6ops-464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 08:03:24 -0000 --047d7b339d19c0fc8d04bab6b5db Content-Type: text/plain; charset=ISO-8859-1 ---------- Forwarded message ---------- From: "Cameron Byrne" Date: Mar 7, 2012 4:34 PM Subject: Re: [v6ops] Nomative language in draft-ietf-v6ops-464xlat-00 To: "Wojciech Dec" we seem to be off list, in line On Wed, Mar 7, 2012 at 9:03 AM, Wojciech Dec wrote: > > > On 7 March 2012 16:31, Cameron Byrne wrote: >> >> Woj, >> >> On Wed, Mar 7, 2012 at 5:49 AM, Wojciech Dec wrote: >> > The draft contains text like >> > >> > "In the 464XLAT environment, the PLAT and CLAT SHOULD include an IPv6 >> > Fragment Header, since IPv4 host does not set the DF bit. " >> > >> >> This will be changed in future revisions, RFC 2119 key words will be >> removed. >> >> > What more it contains specific text in Section 6.1 like >> > >> > " >> > >> > IPv6 address format in 464XLAT is presented in the following format. >> > >> > +-----------------------------------------------+---------------+ >> > | XLAT prefix(96) | IPv4(32) | >> > +-----------------------------------------------+---------------+ >> > >> > Source address and destination address have IPv4 address embedded in the >> > low-order 32 bits of the IPv6 address. " >> > >> > NAT64 RFCs does not make such requirements or place such a prefix >> > restriction, and IMO these effectively become normative for an >> > implementation. If they're not needed then they shouldn't be there. >> > >> >> This is not a NAT64 RFC. This an informational draft that states how >> a scenario defined in a NAT64 RFC may be used. The above IPv6 address >> format is defined as one of many possible in RFC 6052. The above >> format for convenience of implementation is recommended in 464XLAT. I >> hope this recommendation of how a deployment scenario in an >> informational document is not a problem for you. The point of a >> deployment scenario / architecture is that it constrains all possible >> options into a reasonable set that work together in a particular way. > > > Building architectures conforming only to very narrow deployment scenarios > means that they will likely break when taken outside of that environment. In if they are taken outside of their environment, they are not the specified architecture. > the xlat464 case this very narrow deployment scenario appears to be the narrow or not, it patches the 15% app breakage that we see when nat64/dns64 is deployed alone. That alone is the utility of the service. > combined set of; a stateful core NAT46 device; use of only /96 prefix for > address mapping; only private IPv4 addresses for end hosts/apps. > > I for one have no problem with someone choosing to set up their network to > operate like that, and documenting publicly their setup/experiences. Also no > problem with the use NAT64 stateless/stateful to solve the overall problem > of "connect v4 to and across v6". Where I do start having problems is in > seeking broad WG recommendations for effectively creating > devices/implementations that *only* work within this specific set of > constraints. this is an informational doc and not a device spec. > >> >> In general, /96 speeds up discover and helps create uniformity in the >> 464XLAT deployment model. We do not see any specific utility in >> support anything beyond a /96 for the purposes for which 464XLAT is >> scoped. > > > Can you substantiate how a /96 helps speed up discovery, and not other > prefix lengths, or operator assigned lengths? Why restrict the operator to > this specific prefix length for both source and destination address mapping? > The NAT64 authors, operators amongst them, didn't think that such a > restriction was useful or necessary. > I got the impression that /96 is faster here http://www.ietf.org/mail-archive/web/behave/current/msg08893.html the fact that it is simpler is intuitive. i see know reason why to introduce the additional complexity of having other side prefixes. Is there a benefit? >> >> >> > Way of resolving the issue(s) would be to: >> > - Document the experiment, the set-up and the results. >> >> draft-ietf-v6ops-464xlat-00 is not an experiment report, it is an >> informational architecture which happens to be supported by running >> code and informal network deployment reports >> >> > - Separately document any/all specific requirements, assumptions or >> > operations that are not covered by existing RFCs (eg the requirement for >> > XLAT to use a /96 prefix) >> > >> >> draft-ietf-v6ops-464xlat-00 does not create any new technology or >> standards. I don't believe an information document that does not use >> RFC 2119 language and recommends a /96 prefix (which is one of many >> defined in RFC 6052) should be an issue. If it is, please let me know >> why. > > > If this is a recommendation and not a spec, how would a regular stateless > NAT64 device, like the CLAT claims to be, know that it should use a /96 as > its source prefix for mapping v4? > The fact that is knows means that it is CLAT subset of any CPE that does 6145 CB > > -Woj. > >> CB >> >> > -Woj. >> > >> > > > --047d7b339d19c0fc8d04bab6b5db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
---------- Forwarded message ----------
From:= "Cameron Byrne" <cb.lis= t6@gmail.com>
Date: Mar 7, 2012 4:34 PM
Subject: Re: [v6ops] N= omative language in draft-ietf-v6ops-464xlat-00
To: "Wojciech Dec" <wde= c.ietf@gmail.com>

we seem to be off list= , in line

On Wed, Mar 7, 2012 at 9:03 AM, Wojciech Dec <wdec.ietf@gmail.com> wrote:
>
>
> On 7 March 2012 16:31, Cameron Byrne <cb.list6@gmail.com> wrote:
>>
>> Woj,
>>
>> On Wed, Mar 7, 2012 at 5:49 AM, Wojciech Dec <wdec.ietf@gmail.com> wrote:
>> > The draft contains text like
>> >
>> > =A0"In the 464XLAT environment, the PLAT and CLAT SHOULD= include an IPv6
>> > =A0 =A0Fragment Header, since IPv4 host does not set the DF b= it. "
>> >
>>
>> This will be changed in future revisions, RFC 2119 key words will = be
>> removed.
>>
>> > What more it contains specific text in Section 6.1 like
>> >
>> > "
>> >
>> > IPv6 address format in 464XLAT is presented in the following = format.
>> >
>> > =A0 =A0 =A0 =A0+---------------------------------------------= --+---------------+
>> > =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0XLAT prefix(96) = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0IPv4(32) =A0 |
>> > =A0 =A0 =A0 =A0+---------------------------------------------= --+---------------+
>> >
>> > Source address and destination address have IPv4 address embe= dded in the
>> > low-order 32 bits of the IPv6 address. "
>> >
>> > NAT64 RFCs does not make such requirements or place such a pr= efix
>> > restriction, and IMO these effectively become normative for a= n
>> > implementation. If they're not needed then they shouldn&#= 39;t be there.
>> >
>>
>> This is not a NAT64 RFC. =A0This an informational draft that state= s how
>> a scenario defined in a NAT64 RFC may be used. =A0The above IPv6 a= ddress
>> format is defined as one of many possible in RFC 6052. =A0The abov= e
>> format for convenience of implementation is recommended in 464XLAT= . =A0I
>> hope this recommendation of how a deployment scenario in an
>> informational document is not a problem for you. =A0The point of a=
>> deployment scenario / architecture is that it constrains all possi= ble
>> options into a reasonable set that work together in a particular w= ay.
>
>
> Building architectures conforming only to very narrow deployment scena= rios
> means that they will likely break when taken outside of that environme= nt. In

if they are taken outside of their environment, they are not the
specified architecture.

> the xlat464 case this very narrow deployment scenario appears to be th= e

narrow or not, it patches the 15% app breakage that we see when
nat64/dns64 is deployed alone.

That alone is the utility of the service.

> combined set of; a stateful core NAT46 device; use of only /96 prefix = for
> address mapping; only private IPv4 addresses for end hosts/apps.
>
> I for one have no problem with someone choosing to set up their networ= k to
> operate like that, and documenting publicly their setup/experiences. A= lso no
> problem with the use NAT64 stateless/stateful to solve the overall pro= blem
> of "connect v4 to and across v6". Where I do start having pr= oblems is in
> seeking broad WG recommendations for effectively creating
> devices/implementations that *only* work within this specific set of > constraints.

this is an informational doc and not a device spec.

>
>>
>> In general, /96 speeds up discover and helps create uniformity in = the
>> 464XLAT deployment model. =A0We do not see any specific utility in=
>> support anything beyond a /96 for the purposes for which 464XLAT i= s
>> scoped.
>
>
> Can you substantiate how a /96 helps speed up discovery, and not other=
> prefix lengths, or operator assigned lengths? Why restrict the operato= r to
> this specific prefix length for both source and destination address ma= pping?
> The NAT64 authors, operators amongst them, didn't think that such = a
> restriction was useful or necessary.
>

I got the impression that /96 is faster here
http://www.ietf.org/mail-archive/web/behave/current/ms= g08893.html

the fact that it is simpler is intuitive.

i see know reason why to introduce the additional complexity of having
other side prefixes.

Is there a benefit?

>>
>>
>> > Way of resolving the issue(s) would be to:
>> > - Document the experiment, the set-up=A0 and the results.
>>
>> draft-ietf-v6ops-464xlat-00 is not an experiment report, it is an<= br> >> informational architecture which happens to be supported by runnin= g
>> code and informal network deployment reports
>>
>> > - Separately document any/all specific requirements, assumpti= ons or
>> > operations that are not covered by existing RFCs (eg the requ= irement for
>> > XLAT to use a /96 prefix)
>> >
>>
>> draft-ietf-v6ops-464xlat-00 does not create any new technology or<= br> >> standards. =A0I don't believe an information document that doe= s not use
>> RFC 2119 language and recommends a /96 prefix (which is one of man= y
>> defined in RFC 6052) should be an issue. =A0If it is, please let m= e know
>> why.
>
>
> If this is a recommendation and not a spec, how would a regular statel= ess
> NAT64 device, like the CLAT claims to be, know that it should use a /9= 6 as
> its source prefix for mapping v4?
>

The fact that is knows means that it is CLAT subset of any CPE that d= oes 6145

CB
>
> -Woj.
>
>> CB
>>
>> > -Woj.
>> >
>> >
>
>
--047d7b339d19c0fc8d04bab6b5db-- From rick@openfortress.nl Thu Mar 8 00:38:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476D321F85E1 for ; Thu, 8 Mar 2012 00:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 0Jgr3F7GhMmE for ; Thu, 8 Mar 2012 00:38:56 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A436A21F85E0 for ; Thu, 8 Mar 2012 00:38:55 -0800 (PST) Received: by obbta4 with SMTP id ta4so390772obb.31 for ; Thu, 08 Mar 2012 00:38:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.9.232 with SMTP id d8mr2048624oeb.66.1331195935593; Thu, 08 Mar 2012 00:38:55 -0800 (PST) Received: by 10.182.4.175 with HTTP; Thu, 8 Mar 2012 00:38:55 -0800 (PST) In-Reply-To: <25E067CE-65BF-462E-9A45-2D09451256F9@cisco.com> References: <25E067CE-65BF-462E-9A45-2D09451256F9@cisco.com> Date: Thu, 8 Mar 2012 09:38:55 +0100 Message-ID: From: Rick van Rein To: Fred Baker Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQliuhhWsRiDsuJtLNKw3N3yqBm3NO2wlTryBWZqSPm7QYWdsBU0BAupor+tK908z4urVijT Cc: v6ops v6ops WG Subject: Re: [v6ops] Agenda discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 08:38:57 -0000 Hello, > At this point, I take them as our agenda at IETF 83. If I am missing a > document (if you have posted it since Sunday, I may well be missing it), > please remind me. I am working to get a new version of draft-vanrein-v6ops-6bed4 out -- the tunnel that works without account and on any network. The response on v00 has given me a lot to think about, but it is now technically quite clear and will be documented as a draft during next week. Meanwhile, tests with v00 have shown that the concept is succesful and really, really simple to use. This is my first draft submission, if I'm braking any rules or if there are any deadlines then feel not hesitation in correcting me. Thanks, RIck van Rein OpenFortress From fred@cisco.com Thu Mar 8 00:40:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B991821F85F4 for ; Thu, 8 Mar 2012 00:40:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.913 X-Spam-Level: X-Spam-Status: No, score=-108.913 tagged_above=-999 required=5 tests=[AWL=1.686, 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 QOWypaKPSdC1 for ; Thu, 8 Mar 2012 00:40:45 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id CB00421F85F2 for ; Thu, 8 Mar 2012 00:40:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=768; q=dns/txt; s=iport; t=1331196044; x=1332405644; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=MovbIZ+3MVASEMMsM//2zPF9ZQiqVLddKl4eC4B8n1E=; b=jug5aWMw7eNDQRx50sNYYG1XOoQnUfe5L9g5fpmUDgPZOH93wxN84cp5 W1fIXApXKl4lmZZnQcFwy8tjpxzxkARvXOntXJc79sQZOv7/p00T1cSQY 8sOhJWMcXRZ7Y4Ud5Ow6hh1YFfzWnRuyDQjweQkZjpk3EK4RGkYXEjROT s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHpvWE+rRDoJ/2dsb2JhbABDtSSBB4IKAQEBAwESASc/BQsLRlcGNYdhBJtCAY5hkDKQC2MEiFCMcYVkijOCcoFHFw X-IronPort-AV: E=Sophos;i="4.73,551,1325462400"; d="scan'208";a="32520877" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 08 Mar 2012 08:40:44 +0000 Received: from Freds-Computer.local (tky-vpn-client-230-92.cisco.com [10.70.230.92]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q288ehj4018285; Thu, 8 Mar 2012 08:40:43 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Thu, 08 Mar 2012 17:40:45 +0900 X-PGP-Universal: processed; by Freds-Computer.local on Thu, 08 Mar 2012 17:40:45 +0900 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Thu, 8 Mar 2012 17:40:32 +0900 Message-Id: <0B17C523-77BA-48CC-81E5-854F079B590D@cisco.com> References: To: Victor Kuarsingh X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops v6ops WG Subject: Re: [v6ops] Agenda discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 08:40:45 -0000 On Mar 8, 2012, at 11:33 AM, Victor Kuarsingh wrote: > 4.11 Should this say "Lawful Intercept"? Vs Legal Intercept? I guess = this > section could be short (I guess requirements here will differ greatly = by > country/region. The term nowadays seems to be Lawfully Authorized Electronic = Surveillance (LAES). Specifics of procedure, audit, and integrity = validation vary by jurisdiction, but once the bar has been passed that = the surveillance is in fact legal and authorized, what one does next is = pretty common. It falls under CyberCrime Article 20 (data retention, = which in most cases means keeping application logs much longer than an = ISP usually does, but in some countries adds IPFIX captures) or Article = 21 (Content Intercept).= From fred@cisco.com Thu Mar 8 00:52:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D70E21F8602 for ; Thu, 8 Mar 2012 00:52:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.257 X-Spam-Level: X-Spam-Status: No, score=-110.257 tagged_above=-999 required=5 tests=[AWL=0.342, 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 uOILyRmcRMz1 for ; Thu, 8 Mar 2012 00:52:24 -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 954D021F85DB for ; Thu, 8 Mar 2012 00:52:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1360; q=dns/txt; s=iport; t=1331196744; x=1332406344; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=vVDm01+A09hVjvj7sQ+UsFdjQJJa/vRbmuC9BfTorZw=; b=eu5GQ6Y9j/CIV4ZcOGZWWVPfwtHdLQ3MPaMEYeir982s/fwRdr3vch3k v3HuQjiK7t95CMmU4U4ijcDF2u/lbq4XickNOKp3pecNV/aDh9fDv0DSS G36AEdnBiQaBaEaiyfB96vs1rcgxtcX1wXrIPz9Lwwxi4a6cBdgu/YJ9y I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABhzWE+tJV2b/2dsb2JhbABCtTGBB4IKAQEBAwESASc/BQsLLRlXBjWHYQWgAgGXLI1AgktjBIhQjHGFZIozgnI X-IronPort-AV: E=Sophos;i="4.73,551,1325462400"; d="scan'208";a="64742474" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 08 Mar 2012 08:52:03 +0000 Received: from Freds-Computer.local (tky-vpn-client-230-92.cisco.com [10.70.230.92]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q288q2cU014434; Thu, 8 Mar 2012 08:52:02 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Thu, 08 Mar 2012 17:52:04 +0900 X-PGP-Universal: processed; by Freds-Computer.local on Thu, 08 Mar 2012 17:52:04 +0900 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Thu, 8 Mar 2012 17:51:52 +0900 Message-Id: References: <25E067CE-65BF-462E-9A45-2D09451256F9@cisco.com> To: Rick van Rein X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops v6ops WG Subject: Re: [v6ops] Agenda discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 08:52:25 -0000 On Mar 8, 2012, at 5:38 PM, Rick van Rein wrote: > Hello, >=20 >> At this point, I take them as our agenda at IETF 83. If I am missing = a >> document (if you have posted it since Sunday, I may well be missing = it), >> please remind me. >=20 > I am working to get a new version of draft-vanrein-v6ops-6bed4 out -- > the tunnel that works without account and on any network. The > response on v00 has given me a lot to think about, but it is now > technically quite clear and will be documented as a draft during next > week. Meanwhile, tests with v00 have shown that the concept is > succesful and really, really simple to use. >=20 > This is my first draft submission, if I'm braking any rules or if > there are any deadlines then feel not hesitation in correcting me. >=20 > Thanks, >=20 > RIck van Rein > OpenFortress Don't worry about breaking rules; that what rules are made for. There = is, however, a deadline, and this working group has a criterion for = discussion slots that I have found I need to be pretty firm on. The = deadline for new drafts was Monday; the deadline for updates to existing = drafts is this coming Monday. Given a newly-posted draft or update, the = authors are on the hook to get discussion going on the list; I'm looking = for operators saying that they are interested in the proposal.= From wdec.ietf@gmail.com Thu Mar 8 04:26:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE9B721F86B9 for ; Thu, 8 Mar 2012 04:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.952 X-Spam-Level: X-Spam-Status: No, score=-2.952 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 s-CxWJK4uPKU for ; Thu, 8 Mar 2012 04:26:18 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8CCE821F8668 for ; Thu, 8 Mar 2012 04:26:18 -0800 (PST) Received: by qcsq13 with SMTP id q13so348060qcs.31 for ; Thu, 08 Mar 2012 04:26: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=+OIMr2HxL+O21BBjKzjD6nQTvxDJjkpION+9dxdNCOc=; b=oJNegKZY1cyYwPgjfJL5/0PvNZGvuRV1J8gassEil+3eMTXwhRNU1h2/YK2XamWg9O zzoU4XPzHh5kUBns5N8vcmm0r/ZK2+qQUT5QwGlt0orr/OeWdIz0z7auroZxuBHySQJp IBXpnIy5zlaYn7q6tprytJEu3xJ6kdw5jhz/8nE+smXTrApAllJky9IeHdmjEJGAcQxv Xi5ANkTIoUpShfvlAX4qm4+mXKeFqyq+iV8QtLiNiIcY2Sq4QABnBDK6cg7CoSD7ijw6 jqJrlSaJnVYZdZkja54AL6vC2/EsobrLVKgpZc5t6fxlVngh93BSJ0RziiEL3koc7F5q 1c7Q== MIME-Version: 1.0 Received: by 10.229.78.86 with SMTP id j22mr1049431qck.95.1331209577936; Thu, 08 Mar 2012 04:26:17 -0800 (PST) Received: by 10.229.231.203 with HTTP; Thu, 8 Mar 2012 04:26:17 -0800 (PST) In-Reply-To: References: Date: Thu, 8 Mar 2012 13:26:17 +0100 Message-ID: From: Wojciech Dec To: Cameron Byrne Content-Type: multipart/alternative; boundary=00235429c81803b5c404baba6287 Cc: v6ops@ietf.org Subject: Re: [v6ops] Nomative language in draft-ietf-v6ops-464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 12:26:20 -0000 --00235429c81803b5c404baba6287 Content-Type: text/plain; charset=ISO-8859-1 On 8 March 2012 09:03, Cameron Byrne wrote: > ---------- Forwarded message ---------- > From: "Cameron Byrne" > Date: Mar 7, 2012 4:34 PM > Subject: Re: [v6ops] Nomative language in draft-ietf-v6ops-464xlat-00 > To: "Wojciech Dec" > > we seem to be off list, in line > > On Wed, Mar 7, 2012 at 9:03 AM, Wojciech Dec wrote: > > > > > > On 7 March 2012 16:31, Cameron Byrne wrote: > >> > >> Woj, > >> > >> On Wed, Mar 7, 2012 at 5:49 AM, Wojciech Dec > wrote: > >> > The draft contains text like > >> > > >> > "In the 464XLAT environment, the PLAT and CLAT SHOULD include an IPv6 > >> > Fragment Header, since IPv4 host does not set the DF bit. " > >> > > >> > >> This will be changed in future revisions, RFC 2119 key words will be > >> removed. > >> > >> > What more it contains specific text in Section 6.1 like > >> > > >> > " > >> > > >> > IPv6 address format in 464XLAT is presented in the following format. > >> > > >> > > +-----------------------------------------------+---------------+ > >> > | XLAT prefix(96) | IPv4(32) > | > >> > > +-----------------------------------------------+---------------+ > >> > > >> > Source address and destination address have IPv4 address embedded in > the > >> > low-order 32 bits of the IPv6 address. " > >> > > >> > NAT64 RFCs does not make such requirements or place such a prefix > >> > restriction, and IMO these effectively become normative for an > >> > implementation. If they're not needed then they shouldn't be there. > >> > > >> > >> This is not a NAT64 RFC. This an informational draft that states how > >> a scenario defined in a NAT64 RFC may be used. The above IPv6 address > >> format is defined as one of many possible in RFC 6052. The above > >> format for convenience of implementation is recommended in 464XLAT. I > >> hope this recommendation of how a deployment scenario in an > >> informational document is not a problem for you. The point of a > >> deployment scenario / architecture is that it constrains all possible > >> options into a reasonable set that work together in a particular way. > > > > > > Building architectures conforming only to very narrow deployment > scenarios > > means that they will likely break when taken outside of that > environment. In > > if they are taken outside of their environment, they are not the > specified architecture. > Yes, that's why architectures should be broad usage based. > > > the xlat464 case this very narrow deployment scenario appears to be the > > narrow or not, it patches the 15% app breakage that we see when > nat64/dns64 is deployed alone. > > That alone is the utility of the service. > Case in hand appears that if one takes a CLAT and connects it to say any other network, say your enterprise network where NAT64 may even be present but configured outside of the narrow xlat464 constraints, the CLAT won't work, ie the app breakage will be there, even though it they could be avoided. > > combined set of; a stateful core NAT46 device; use of only /96 prefix for > > address mapping; only private IPv4 addresses for end hosts/apps. > > > > I for one have no problem with someone choosing to set up their network > to > > operate like that, and documenting publicly their setup/experiences. > Also no > > problem with the use NAT64 stateless/stateful to solve the overall > problem > > of "connect v4 to and across v6". Where I do start having problems is in > > seeking broad WG recommendations for effectively creating > > devices/implementations that *only* work within this specific set of > > constraints. > > this is an informational doc and not a device spec. > > > > >> > >> In general, /96 speeds up discover and helps create uniformity in the > >> 464XLAT deployment model. We do not see any specific utility in > >> support anything beyond a /96 for the purposes for which 464XLAT is > >> scoped. > > > > > > Can you substantiate how a /96 helps speed up discovery, and not other > > prefix lengths, or operator assigned lengths? Why restrict the operator > to > > this specific prefix length for both source and destination address > mapping? > > The NAT64 authors, operators amongst them, didn't think that such a > > restriction was useful or necessary. > > > > I got the impression that /96 is faster here > http://www.ietf.org/mail-archive/web/behave/current/msg08893.html > > the fact that it is simpler is intuitive. > > i see know reason why to introduce the additional complexity of having > other side prefixes. > > Is there a benefit? > For a start, NAT64 authors saw a benefit, so unless we're redefining that we should follow, or be very precise why not. To me, the impression that /96 is faster not entirely justified. Besides this, the length of the prefix is relevant to operators who care about route summarization and optimization, besides actual subnetting. It's similar to why we don't have rules for a "simple and intuitive" fixed host subnet length in IPv6. > > >> > >> > >> > Way of resolving the issue(s) would be to: > >> > - Document the experiment, the set-up and the results. > >> > >> draft-ietf-v6ops-464xlat-00 is not an experiment report, it is an > >> informational architecture which happens to be supported by running > >> code and informal network deployment reports > >> > >> > - Separately document any/all specific requirements, assumptions or > >> > operations that are not covered by existing RFCs (eg the requirement > for > >> > XLAT to use a /96 prefix) > >> > > >> > >> draft-ietf-v6ops-464xlat-00 does not create any new technology or > >> standards. I don't believe an information document that does not use > >> RFC 2119 language and recommends a /96 prefix (which is one of many > >> defined in RFC 6052) should be an issue. If it is, please let me know > >> why. > > > > > > If this is a recommendation and not a spec, how would a regular stateless > > NAT64 device, like the CLAT claims to be, know that it should use a /96 > as > > its source prefix for mapping v4? > > > > The fact that is knows means that it is CLAT subset of any CPE that does > 6145 > This seems to contradict the previous statement about this draft not being a device spec. If the CLAT is fully RFC6145 compliant, it should be clearly stated, and text about /96, etc removed. If you're assuming that the CLAT is a subset of RFC6145, then it would be best if you put the specifics of those assumptions + anything else that is needed for the spec in a separate draft. -Woj. > > CB > > > > -Woj. > > > >> CB > >> > >> > -Woj. > >> > > >> > > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --00235429c81803b5c404baba6287 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 8 March 2012 09:03, Cameron Byrne <cb.list6@gmail.com= > wrote:
--------= -- Forwarded message ----------
From: "Cameron Byrne" <cb.list6@gmail.com&= gt;
Date: Mar 7, 2012 4:34 PM
Subject: Re: [v6ops] Nomative language in draf= t-ietf-v6ops-464xlat-00
To: "Wojciech Dec" <wdec.ietf@gmail.com>

we s= eem to be off list, in line

On Wed, Mar 7, 2012 at 9:03 AM, Wojciech Dec <wdec.ietf@gmail.com> wrote:
>
>
> On 7 March 2012 16:31, Cameron Byrne <cb.list6@gmail.com> wrote:
>>
>> Woj,
>>
>> On Wed, Mar 7, 2012 at 5:49 AM, Wojciech Dec <wdec.ietf@gmail.com> wrote:<= br> >> > The draft contains text like
>> >
>> > =A0"In the 464XLAT environment, the PLAT and CLAT SHOULD= include an IPv6
>> > =A0 =A0Fragment Header, since IPv4 host does not set the DF b= it. "
>> >
>>
>> This will be changed in future revisions, RFC 2119 key words will = be
>> removed.
>>
>> > What more it contains specific text in Section 6.1 like
>> >
>> > "
>> >
>> > IPv6 address format in 464XLAT is presented in the following = format.
>> >
>> > =A0 =A0 =A0 =A0+---------------------------------------------= --+---------------+
>> > =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0XLAT prefix(96) = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0IPv4(32) =A0 |
>> > =A0 =A0 =A0 =A0+---------------------------------------------= --+---------------+
>> >
>> > Source address and destination address have IPv4 address embe= dded in the
>> > low-order 32 bits of the IPv6 address. "
>> >
>> > NAT64 RFCs does not make such requirements or place such a pr= efix
>> > restriction, and IMO these effectively become normative for a= n
>> > implementation. If they're not needed then they shouldn&#= 39;t be there.
>> >
>>
>> This is not a NAT64 RFC. =A0This an informational draft that state= s how
>> a scenario defined in a NAT64 RFC may be used. =A0The above IPv6 a= ddress
>> format is defined as one of many possible in RFC 6052. =A0The abov= e
>> format for convenience of implementation is recommended in 464XLAT= . =A0I
>> hope this recommendation of how a deployment scenario in an
>> informational document is not a problem for you. =A0The point of a=
>> deployment scenario / architecture is that it constrains all possi= ble
>> options into a reasonable set that work together in a particular w= ay.
>
>
> Building architectures conforming only to very narrow deployment scena= rios
> means that they will likely break when taken outside of that environme= nt. In

if they are taken outside of their environment, they are not the
specified architecture.

Yes, tha= t's why architectures should be broad usage based.
=A0

> the xlat464 case this very narrow deployment scenario appears to be th= e

narrow or not, it patches the 15% app breakage that we see when
nat64/dns64 is deployed alone.

That alone is the utility of the service.

Case in hand appears that if one takes a CLAT and connects it to = say any other network, say your enterprise network where NAT64 may even be = present but configured outside of the narrow xlat464 constraints, the CLAT = won't work, ie the app breakage will be there, even though it they coul= d be avoided.


> combined set of; a stateful core NAT46 device; use of only /96 prefix = for
> address mapping; only private IPv4 addresses for end hosts/apps.
>
> I for one have no problem with someone choosing to set up their networ= k to
> operate like that, and documenting publicly their setup/experiences. A= lso no
> problem with the use NAT64 stateless/stateful to solve the overall pro= blem
> of "connect v4 to and across v6". Where I do start having pr= oblems is in
> seeking broad WG recommendations for effectively creating
> devices/implementations that *only* work within this specific set of > constraints.

this is an informational doc and not a device spec.

>
>>
>> In general, /96 speeds up discover and helps create uniformity in = the
>> 464XLAT deployment model. =A0We do not see any specific utility in=
>> support anything beyond a /96 for the purposes for which 464XLAT i= s
>> scoped.
>
>
> Can you substantiate how a /96 helps speed up discovery, and not other=
> prefix lengths, or operator assigned lengths? Why restrict the operato= r to
> this specific prefix length for both source and destination address ma= pping?
> The NAT64 authors, operators amongst them, didn't think that such = a
> restriction was useful or necessary.
>

I got the impression that /96 is faster here
http://www.ietf.org/mail-archive/web/behave/current/ms= g08893.html

the fact that it is simpler is intuitive.

i see know reason why to introduce the additional complexity of having
other side prefixes.

Is there a benefit?

For a start,= NAT64 authors saw a benefit, so unless we're redefining that we should= follow, or be very precise why not. To me, the impression that /96 is fast= er not entirely justified.
Besides this, the length of the prefix is relevant to operators who care ab= out route summarization and optimization, besides actual subnetting. It'= ;s similar to why we don't have rules for a "simple and intuitive&= quot; fixed host subnet length in IPv6.
=A0

>>
>>
>> > Way of resolving the issue(s) would be to:
>> > - Document the experiment, the set-up=A0 and the results.
>>
>> draft-ietf-v6ops-464xlat-00 is not an experiment report, it is an<= br> >> informational architecture which happens to be supported by runnin= g
>> code and informal network deployment reports
>>
>> > - Separately document any/all specific requirements, assumpti= ons or
>> > operations that are not covered by existing RFCs (eg the requ= irement for
>> > XLAT to use a /96 prefix)
>> >
>>
>> draft-ietf-v6ops-464xlat-00 does not create any new technology or<= br> >> standards. =A0I don't believe an information document that doe= s not use
>> RFC 2119 language and recommends a /96 prefix (which is one of man= y
>> defined in RFC 6052) should be an issue. =A0If it is, please let m= e know
>> why.
>
>
> If this is a recommendation and not a spec, how would a regular statel= ess
> NAT64 device, like the CLAT claims to be, know that it should use a /9= 6 as
> its source prefix for mapping v4?
>

The fact that is knows means that it is CLAT subset of any CPE that d= oes 6145

This seems to contradic= t the previous statement about this draft not being a device spec.
If the CLAT is fully RFC6145 compliant, it should be clearly stated, and te= xt about /96, etc removed. If you're assuming that the CLAT is a subset= of RFC6145, then it would be best if you put the specifics of those assump= tions + anything else that is needed for the spec in a separate draft.

-Woj.

CB
>
> -Woj.
>
>> CB
>>
>> > -Woj.
>> >
>> >
>
>

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


--00235429c81803b5c404baba6287-- From cb.list6@gmail.com Thu Mar 8 05:50:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F9421F84B9 for ; Thu, 8 Mar 2012 05:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 rhZD5gk7Fcv7 for ; Thu, 8 Mar 2012 05:50:23 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7D84921F84B8 for ; Thu, 8 Mar 2012 05:50:23 -0800 (PST) Received: by pbbrq13 with SMTP id rq13so1684232pbb.31 for ; Thu, 08 Mar 2012 05:50: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=cNwIRR+qLDCczHUhw8r3a2IJqDGMJ9x/iuF4bwKycSA=; b=FAgJZPUHYGW658fwLHH/M7JPq1LoVefyQSjt2sJKv001fRBgbBLhIxl2xof8++68AK d6vBAZVIVo/ke6P/jbiytekqJM2/doWN3fmxgkx+wafmMgftDsTavR7hrIj++XABQmpW 85tKfXnhY2/GS7mN8ClCwKuNzLE2L+y0i2DfiF8DtFo7r8CbgjnU+GI+sn13pdLsUFbU eANTLwySMWM6Av9GrjZiDa/Kb7YU3hiSqmPEbgz5pWsMVgeZUT4jMiEf3A9Ftl517Olq CvjfIJgMS4mW1Mt+TEAz3d8fQNAmJEOUu4y/yKD3Wbsxkc2Lv9ULx6wxUUiEEY/1R++O SASA== MIME-Version: 1.0 Received: by 10.68.216.138 with SMTP id oq10mr9735167pbc.85.1331214623136; Thu, 08 Mar 2012 05:50:23 -0800 (PST) Received: by 10.142.163.16 with HTTP; Thu, 8 Mar 2012 05:50:22 -0800 (PST) Received: by 10.142.163.16 with HTTP; Thu, 8 Mar 2012 05:50:22 -0800 (PST) In-Reply-To: References: Date: Thu, 8 Mar 2012 05:50:22 -0800 Message-ID: From: Cameron Byrne To: Victor Kuarsingh Content-Type: multipart/alternative; boundary=047d7b2e090dbb5c4e04babb8ebd Cc: v6ops v6ops WG Subject: Re: [v6ops] Agenda discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 13:50:24 -0000 --047d7b2e090dbb5c4e04babb8ebd Content-Type: text/plain; charset=ISO-8859-1 On Mar 7, 2012 7:33 PM, "Victor Kuarsingh" wrote: > > > > On 12-03-07 3:29 PM, "George, Wes" wrote: > > > > >I'm interested in draft-gundavelli, but I think it has an awful lot of > >placeholders for it to be effectively discussed in Paris. Perhaps next > >meeting, unless the authors are currently working on a -01 draft to be > >posted later this week that fills in some of the gaps. > > I am interested in this draft as well - timely topic . I agree with Wes > that there is a significant amount of text which needs to be created to > have a qualify discussion on this. > Interesting topic but I have not seen any novel or meaningful work.... and that is probably good. The internet model is smart end points and simple network. So the solution set should basis application solutions, not another mobile IP or GTP > Sections which I think need more content for discussion > > 4.7 Mobility in WLAN. A very important part of the WiFi discussion. > Why? Do session persistence / resume in the app. > 4.8 Mobility across WLAN and Macro Access. This is a complex topic. I am > not sure how much detail needs to be put down here. I think the content > is a bit light (but maybe that what the authors were looking for - not > sure). I would say (perhaps) a reference to 3GPP 23.327 may be applicable. > Complex. Tried to solve this with UMA/ GAN, failed. Too much complexity for too little gain. Make the endpoints figure it out in the app. Or ...mSCTP? VoLTE and SCC will be interesting to watch as technical aspirations meet instrumentation and deployment reality. > 4.10 Service and Network Security. This is also a large part of the WiFi > discussion. If we put security items here, do we still need section 7? > (Security Considerations) > You want to secure the internet? Once again, e2e not smart networks. Cb > 4.11 Should this say "Lawful Intercept"? Vs Legal Intercept? I guess this > section could be short (I guess requirements here will differ greatly by > country/region. > > Also, related to 4.7, but likely a separate section is around RF planning > for WiFi deployment. This may include comments/topics around what > channels to use, 2.4GHz vs. 5.0GHz ranges etc. > > A section around potential encryption requirements? (maybe in security > section or separate?) > > Regards, > > Victor Kuarsingh > > > > > > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --047d7b2e090dbb5c4e04babb8ebd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mar 7, 2012 7:33 PM, "Victor Kuarsingh" <victor.kuarsingh@gmail.com> wrote:
>
>
>
> On 12-03-07 3:29 PM, "George, Wes" <wesley.george@twcable.com> wrote:
>
> >
> >I'm interested in draft-gundavelli, but I think it has an awfu= l lot of
> >placeholders for it to be effectively discussed in Paris. Perhaps = next
> >meeting, unless the authors are currently working on a -01 draft t= o be
> >posted later this week that fills in some of the gaps.
>
> I am interested in this draft as well - timely topic . =A0I agree with= Wes
> that there is a significant amount of text which needs to be created t= o
> have a qualify discussion on this.
>

Interesting topic but I have not seen any novel or meaningful work.... a= nd that is probably good. The internet model is smart end points and simple= network. So the solution set should basis application solutions, not anoth= er mobile IP or GTP

> Sections which I think need more content for discussion
>
> 4.7 Mobility in WLAN. =A0A very important part of the WiFi discussion.=
>

Why? Do session persistence / resume in the app.

> 4.8 Mobility across WLAN and Macro Access. =A0This is a complex top= ic. =A0I am
> not sure how much detail needs to be put down here. =A0I think the con= tent
> is a bit light (but maybe that what the authors were looking for - not=
> sure). =A0I would say (perhaps) a reference to 3GPP 23.327 may be appl= icable.
>

Complex. Tried to solve this with UMA/ GAN, failed. Too much complexity = for too little gain. Make the endpoints figure it out in the app. Or ...mSC= TP?

VoLTE and SCC will be interesting to watch as technical aspirations meet= instrumentation and deployment reality.

> 4.10 Service and Network Security. =A0This is also a large part of = the WiFi
> discussion. =A0If we put security items here, do we still need section= 7?
> (Security Considerations)
>

You want to secure the internet? Once again, e2e not smart networks.

Cb

> 4.11 Should this say "Lawful Intercept"? Vs Legal Interce= pt? =A0I guess this
> section could be short (I guess requirements here will differ greatly = by
> country/region.
>
> Also, related to 4.7, but likely a separate section is around RF plann= ing
> for WiFi deployment. =A0This may include comments/topics around what > channels to use, 2.4GHz vs. 5.0GHz ranges etc.
>
> A section around potential encryption requirements? (maybe in security=
> section or separate?)
>
> Regards,
>
> Victor Kuarsingh
>
>
>
>
>
>
>
>
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--047d7b2e090dbb5c4e04babb8ebd-- From cb.list6@gmail.com Thu Mar 8 06:09:07 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9691B21F8716 for ; Thu, 8 Mar 2012 06:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.145 X-Spam-Level: X-Spam-Status: No, score=-3.145 tagged_above=-999 required=5 tests=[AWL=-0.147, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 zlm86eCyPEg5 for ; Thu, 8 Mar 2012 06:09:05 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id BFB2D21F8699 for ; Thu, 8 Mar 2012 06:09:05 -0800 (PST) Received: by pbbrq13 with SMTP id rq13so1701391pbb.31 for ; Thu, 08 Mar 2012 06:09: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=hkpEIesX4wxQvMirt7o9y7sPFjR878NBP7N1za8q+aA=; b=l7x3mqKdyS6dFlMg43n74HWFRTOs+Zp2Dwem527eebv+pkfPFxvAPhk4c+yRoXwv2D FB0/3uWLQ+O5JY7onPVhWpmxfgGOnUoQFSgMY7A8AH/T5cPV4b9Xd963ALgNkCm5/ddK 51cDxk0rkxp8gIPolvmKFKOPf7e9qSHZM5k4OKF135NRFEFLDeZU1DzEKP1pqlw94b0b Ix7li/6l+VYy3DzdBbR2kzQkGsQ2Dn4B/e5HVIhdEPEeDDnaHeyZUKQ93ZWOCAvjxkAW s3XOkElGdMPr6TPmaR3rNDEjJQraCcRUHnFTtLhQ5ynzRdT3bnwSK1l+m4Z2UJCD6gUF k/HQ== MIME-Version: 1.0 Received: by 10.68.216.138 with SMTP id oq10mr9831666pbc.85.1331215745369; Thu, 08 Mar 2012 06:09:05 -0800 (PST) Received: by 10.142.163.16 with HTTP; Thu, 8 Mar 2012 06:09:05 -0800 (PST) Received: by 10.142.163.16 with HTTP; Thu, 8 Mar 2012 06:09:05 -0800 (PST) In-Reply-To: References: Date: Thu, 8 Mar 2012 06:09:05 -0800 Message-ID: From: Cameron Byrne To: Wojciech Dec Content-Type: multipart/alternative; boundary=047d7b2e090d9f475104babbd1b9 Cc: v6ops@ietf.org Subject: Re: [v6ops] Nomative language in draft-ietf-v6ops-464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 14:09:07 -0000 --047d7b2e090d9f475104babbd1b9 Content-Type: text/plain; charset=ISO-8859-1 On Mar 8, 2012 5:26 AM, "Wojciech Dec" wrote: > > > > On 8 March 2012 09:03, Cameron Byrne wrote: >> >> ---------- Forwarded message ---------- >> From: "Cameron Byrne" >> Date: Mar 7, 2012 4:34 PM >> Subject: Re: [v6ops] Nomative language in draft-ietf-v6ops-464xlat-00 >> To: "Wojciech Dec" >> >> we seem to be off list, in line >> >> On Wed, Mar 7, 2012 at 9:03 AM, Wojciech Dec wrote: >> > >> > >> > On 7 March 2012 16:31, Cameron Byrne wrote: >> >> >> >> Woj, >> >> >> >> On Wed, Mar 7, 2012 at 5:49 AM, Wojciech Dec wrote: >> >> > The draft contains text like >> >> > >> >> > "In the 464XLAT environment, the PLAT and CLAT SHOULD include an IPv6 >> >> > Fragment Header, since IPv4 host does not set the DF bit. " >> >> > >> >> >> >> This will be changed in future revisions, RFC 2119 key words will be >> >> removed. >> >> >> >> > What more it contains specific text in Section 6.1 like >> >> > >> >> > " >> >> > >> >> > IPv6 address format in 464XLAT is presented in the following format. >> >> > >> >> > +-----------------------------------------------+---------------+ >> >> > | XLAT prefix(96) | IPv4(32) | >> >> > +-----------------------------------------------+---------------+ >> >> > >> >> > Source address and destination address have IPv4 address embedded in the >> >> > low-order 32 bits of the IPv6 address. " >> >> > >> >> > NAT64 RFCs does not make such requirements or place such a prefix >> >> > restriction, and IMO these effectively become normative for an >> >> > implementation. If they're not needed then they shouldn't be there. >> >> > >> >> >> >> This is not a NAT64 RFC. This an informational draft that states how >> >> a scenario defined in a NAT64 RFC may be used. The above IPv6 address >> >> format is defined as one of many possible in RFC 6052. The above >> >> format for convenience of implementation is recommended in 464XLAT. I >> >> hope this recommendation of how a deployment scenario in an >> >> informational document is not a problem for you. The point of a >> >> deployment scenario / architecture is that it constrains all possible >> >> options into a reasonable set that work together in a particular way. >> > >> > >> > Building architectures conforming only to very narrow deployment scenarios >> > means that they will likely break when taken outside of that environment. In >> >> if they are taken outside of their environment, they are not the >> specified architecture. > > > Yes, that's why architectures should be broad usage based. > Disagree. You may have a successful architecture for an air plane, but if you change the use case such that it must act as a boat ... that is an implementation failure. It does not make the airplane architecture a failure as soon as somebody puts it in the water >> >> >> > the xlat464 case this very narrow deployment scenario appears to be the >> >> narrow or not, it patches the 15% app breakage that we see when >> nat64/dns64 is deployed alone. >> >> >> That alone is the utility of the service. > > > Case in hand appears that if one takes a CLAT and connects it to say any other network, say your enterprise network where NAT64 may even be present but configured outside of the narrow xlat464 constraints, the CLAT won't work, ie the app breakage will be there, even though it they could be avoided. > Out of scope. >> >> > combined set of; a stateful core NAT46 device; use of only /96 prefix for >> > address mapping; only private IPv4 addresses for end hosts/apps. >> > >> > I for one have no problem with someone choosing to set up their network to >> > operate like that, and documenting publicly their setup/experiences. Also no >> > problem with the use NAT64 stateless/stateful to solve the overall problem >> > of "connect v4 to and across v6". Where I do start having problems is in >> > seeking broad WG recommendations for effectively creating >> > devices/implementations that *only* work within this specific set of >> > constraints. >> >> this is an informational doc and not a device spec. >> >> > >> >> >> >> In general, /96 speeds up discover and helps create uniformity in the >> >> 464XLAT deployment model. We do not see any specific utility in >> >> support anything beyond a /96 for the purposes for which 464XLAT is >> >> scoped. >> > >> > >> > Can you substantiate how a /96 helps speed up discovery, and not other >> > prefix lengths, or operator assigned lengths? Why restrict the operator to >> > this specific prefix length for both source and destination address mapping? >> > The NAT64 authors, operators amongst them, didn't think that such a >> > restriction was useful or necessary. >> > >> >> I got the impression that /96 is faster here >> http://www.ietf.org/mail-archive/web/behave/current/msg08893.html >> >> the fact that it is simpler is intuitive. >> >> i see know reason why to introduce the additional complexity of having >> other side prefixes. >> >> Is there a benefit? > > > For a start, NAT64 authors saw a benefit, so unless we're redefining that we should follow, or be very precise why not. To me, the impression that /96 is faster not entirely justified. > Besides this, the length of the prefix is relevant to operators who care about route summarization and optimization, besides actual subnetting. It's similar to why we don't have rules for a "simple and intuitive" fixed host subnet length in IPv6. > Saying the nat64 authors saw a benefit is not demonstrating value for the 464xlat scenario. Quantify how it is not faster, if that is your claim. Route summaries? As the draft says clearly, /64 is the best and likely case is that is with dhcp pd. The /96 is a case of nd proxy or similar. Neither have any impact on route summaries. In both cases above you made unsupported claims which makes me go back and justify why your unsubstantiated claim is wrong with facts and use cases. Please clearly substantiate your claims with examples in the future. ... for example, if you are going to claim this makes more routes, clearly articulate why you believe that. Otherwise you will be dismissed as creating FUD. >> >> >> >> >> >> >> >> > Way of resolving the issue(s) would be to: >> >> > - Document the experiment, the set-up and the results. >> >> >> >> draft-ietf-v6ops-464xlat-00 is not an experiment report, it is an >> >> informational architecture which happens to be supported by running >> >> code and informal network deployment reports >> >> >> >> > - Separately document any/all specific requirements, assumptions or >> >> > operations that are not covered by existing RFCs (eg the requirement for >> >> > XLAT to use a /96 prefix) >> >> > >> >> >> >> draft-ietf-v6ops-464xlat-00 does not create any new technology or >> >> standards. I don't believe an information document that does not use >> >> RFC 2119 language and recommends a /96 prefix (which is one of many >> >> defined in RFC 6052) should be an issue. If it is, please let me know >> >> why. >> > >> > >> > If this is a recommendation and not a spec, how would a regular stateless >> > NAT64 device, like the CLAT claims to be, know that it should use a /96 as >> > its source prefix for mapping v4? >> > >> >> The fact that is knows means that it is CLAT subset of any CPE that does 6145 > > > This seems to contradict the previous statement about this draft not being a device spec. > If the CLAT is fully RFC6145 compliant, it should be clearly stated, and text about /96, etc removed. If you're assuming that the CLAT is a subset of RFC6145, then it would be best if you put the specifics of those assumptions + anything else that is needed for the spec in a separate draft. > Disagree. Cb > -Woj. >> >> >> CB >> > >> > -Woj. >> > >> >> CB >> >> >> >> > -Woj. >> >> > >> >> > >> > >> > >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > --047d7b2e090d9f475104babbd1b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mar 8, 2012 5:26 AM, "Wojciech Dec" <wdec.ietf@gmail.com> wrote:
>
>
>
> On 8 March 2012 09:03, Cameron Byrne <cb.list6@gmail.com> wrote:
>>
>> ---------- Forwarded message ----------
>> From: "Cameron Byrne" <cb.list6@gmail.com>
>> Date: Mar 7, 2012 4:34 PM
>> Subject: Re: [v6ops] Nomative language in draft-ietf-v6ops-464xlat= -00
>> To: "Wojciech Dec" <wdec.ietf@gmail.com>
>>
>> we seem to be off list, in line
>>
>> On Wed, Mar 7, 2012 at 9:03 AM, Wojciech Dec <wdec.ietf@gmail.com> wrote:
>> >
>> >
>> > On 7 March 2012 16:31, Cameron Byrne <cb.list6@gmail.com> wrote:
>> >>
>> >> Woj,
>> >>
>> >> On Wed, Mar 7, 2012 at 5:49 AM, Wojciech Dec <wdec.ietf@gmail.com> wrote:
>> >> > The draft contains text like
>> >> >
>> >> > =A0"In the 464XLAT environment, the PLAT and CL= AT SHOULD include an IPv6
>> >> > =A0 =A0Fragment Header, since IPv4 host does not set= the DF bit. "
>> >> >
>> >>
>> >> This will be changed in future revisions, RFC 2119 key wo= rds will be
>> >> removed.
>> >>
>> >> > What more it contains specific text in Section 6.1 l= ike
>> >> >
>> >> > "
>> >> >
>> >> > IPv6 address format in 464XLAT is presented in the f= ollowing format.
>> >> >
>> >> > =A0 =A0 =A0 =A0+------------------------------------= -----------+---------------+
>> >> > =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0XLAT pre= fix(96) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0IPv4(32) =A0 |
>> >> > =A0 =A0 =A0 =A0+------------------------------------= -----------+---------------+
>> >> >
>> >> > Source address and destination address have IPv4 add= ress embedded in the
>> >> > low-order 32 bits of the IPv6 address. "
>> >> >
>> >> > NAT64 RFCs does not make such requirements or place = such a prefix
>> >> > restriction, and IMO these effectively become normat= ive for an
>> >> > implementation. If they're not needed then they = shouldn't be there.
>> >> >
>> >>
>> >> This is not a NAT64 RFC. =A0This an informational draft t= hat states how
>> >> a scenario defined in a NAT64 RFC may be used. =A0The abo= ve IPv6 address
>> >> format is defined as one of many possible in RFC 6052. = =A0The above
>> >> format for convenience of implementation is recommended i= n 464XLAT. =A0I
>> >> hope this recommendation of how a deployment scenario in = an
>> >> informational document is not a problem for you. =A0The p= oint of a
>> >> deployment scenario / architecture is that it constrains = all possible
>> >> options into a reasonable set that work together in a par= ticular way.
>> >
>> >
>> > Building architectures conforming only to very narrow deploym= ent scenarios
>> > means that they will likely break when taken outside of that = environment. In
>>
>> if they are taken outside of their environment, they are not the >> specified architecture.
>
>
> Yes, that's why architectures should be broad usage based.
> =A0

Disagree. You may have a successful architecture for an air plane, but i= f you change the use case such that it must act as a boat ... that is an im= plementation failure. It does not make the airplane architecture a failure = as soon as somebody puts it in the water

>>
>>
>> > the xlat464 case this very narrow deployment scenario appears= to be the
>>
>> narrow or not, it patches the 15% app breakage that we see when >> nat64/dns64 is deployed alone.
>>
>>
>> That alone is the utility of the service.
>
>
> Case in hand appears that if one takes a CLAT and connects it to say a= ny other network, say your enterprise network where NAT64 may even be prese= nt but configured outside of the narrow xlat464 constraints, the CLAT won&#= 39;t work, ie the app breakage will be there, even though it they could be = avoided.
>

Out of scope.

>>
>> > combined set of; a stateful core NAT46 device; use of only /9= 6 prefix for
>> > address mapping; only private IPv4 addresses for end hosts/ap= ps.
>> >
>> > I for one have no problem with someone choosing to set up the= ir network to
>> > operate like that, and documenting publicly their setup/exper= iences. Also no
>> > problem with the use NAT64 stateless/stateful to solve the ov= erall problem
>> > of "connect v4 to and across v6". Where I do start = having problems is in
>> > seeking broad WG recommendations for effectively creating
>> > devices/implementations that *only* work within this specific= set of
>> > constraints.
>>
>> this is an informational doc and not a device spec.
>>
>> >
>> >>
>> >> In general, /96 speeds up discover and helps create unifo= rmity in the
>> >> 464XLAT deployment model. =A0We do not see any specific u= tility in
>> >> support anything beyond a /96 for the purposes for which = 464XLAT is
>> >> scoped.
>> >
>> >
>> > Can you substantiate how a /96 helps speed up discovery, and = not other
>> > prefix lengths, or operator assigned lengths? Why restrict th= e operator to
>> > this specific prefix length for both source and destination a= ddress mapping?
>> > The NAT64 authors, operators amongst them, didn't think t= hat such a
>> > restriction was useful or necessary.
>> >
>>
>> I got the impression that /96 is faster here
>> http://www.ietf.org/mail-archive/web/behave/current/msg08893.ht= ml
>>
>> the fact that it is simpler is intuitive.
>>
>> i see know reason why to introduce the additional complexity of ha= ving
>> other side prefixes.
>>
>> Is there a benefit?
>
>
> For a start, NAT64 authors saw a benefit, so unless we're redefini= ng that we should follow, or be very precise why not. To me, the impression= that /96 is faster not entirely justified.
> Besides this, the length of the prefix is relevant to operators who ca= re about route summarization and optimization, besides actual subnetting. I= t's similar to why we don't have rules for a "simple and intui= tive" fixed host subnet length in IPv6.
> =A0

Saying the nat64 authors saw a benefit is not demonstrating value for th= e 464xlat scenario.

Quantify how it is not faster, if that is your claim.

Route summaries? As the draft says clearly, /64 is the best and likely c= ase is that is with dhcp pd. The /96 is a case of nd proxy or similar. Neit= her have any impact on route summaries.

In both cases above you made unsupported claims which makes me go back a= nd justify why your unsubstantiated claim is wrong with facts and use cases= .

Please clearly substantiate your claims with examples in the future. ...= for example, if you are going to claim this makes more routes, clearly art= iculate why you believe that. Otherwise you will be dismissed as creating F= UD.

>>
>>
>> >>
>> >>
>> >> > Way of resolving the issue(s) would be to:
>> >> > - Document the experiment, the set-up=A0 and the res= ults.
>> >>
>> >> draft-ietf-v6ops-464xlat-00 is not an experiment report, = it is an
>> >> informational architecture which happens to be supported = by running
>> >> code and informal network deployment reports
>> >>
>> >> > - Separately document any/all specific requirements,= assumptions or
>> >> > operations that are not covered by existing RFCs (eg= the requirement for
>> >> > XLAT to use a /96 prefix)
>> >> >
>> >>
>> >> draft-ietf-v6ops-464xlat-00 does not create any new techn= ology or
>> >> standards. =A0I don't believe an information document= that does not use
>> >> RFC 2119 language and recommends a /96 prefix (which is o= ne of many
>> >> defined in RFC 6052) should be an issue. =A0If it is, ple= ase let me know
>> >> why.
>> >
>> >
>> > If this is a recommendation and not a spec, how would a regul= ar stateless
>> > NAT64 device, like the CLAT claims to be, know that it should= use a /96 as
>> > its source prefix for mapping v4?
>> >
>>
>> The fact that is knows means that it is CLAT subset of any CPE tha= t does 6145
>
>
> This seems to contradict the previous statement about this draft not b= eing a device spec.
> If the CLAT is fully RFC6145 compliant, it should be clearly stated, a= nd text about /96, etc removed. If you're assuming that the CLAT is a s= ubset of RFC6145, then it would be best if you put the specifics of those a= ssumptions + anything else that is needed for the spec in a separate draft.=
>

Disagree.

Cb
> -Woj.
>>
>>
>> CB
>> >
>> > -Woj.
>> >
>> >> CB
>> >>
>> >> > -Woj.
>> >> >
>> >> >
>> >
>> >
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://ww= w.ietf.org/mailman/listinfo/v6ops
>>
>

--047d7b2e090d9f475104babbd1b9-- From mbehring@cisco.com Thu Mar 8 01:56:39 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6436721F8684 for ; Thu, 8 Mar 2012 01:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 Fmu31u-fWe3J for ; Thu, 8 Mar 2012 01:56:38 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1D821F8682 for ; Thu, 8 Mar 2012 01:56:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mbehring@cisco.com; l=948; q=dns/txt; s=iport; t=1331200598; x=1332410198; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to; bh=Tw1m8nU51Ie9xBweV/FEnjChbQuBIpNMP8+hrwsYoTE=; b=CsgfGpaixDphbSt3+U8Xhcp7ny5414aomhfogmer9OJd39xiOzBAdSBW T7TjNIj+ATeG3RzELyZOpyEybGykKokjhBPurWWKzvNwEYIVOgthxwjnq xghhiAlkc8F6V9Ozk1HfHEuaLLeNpmJ/q2H2VHqMpjoJ4ei5E+VI5aDl7 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAB2CWE+Q/khR/2dsb2JhbABDtSSBB4IMAQQSAR0KUQEqBhgHVwEEGxqHZguaEIEnAZ8WjUyCP2MEpViCZA X-IronPort-AV: E=Sophos;i="4.73,551,1325462400"; d="scan'208";a="67967019" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 08 Mar 2012 09:56:18 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q289uIYC018336 for ; Thu, 8 Mar 2012 09:56:18 GMT Received: from xmb-ams-105.cisco.com ([144.254.74.80]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 10:56:18 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Mar 2012 10:56:18 +0100 Message-ID: <51865E1A72F61D48A247348DCCBA5CFB05B9154C@XMB-AMS-105.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Draft: Using Only Link-Local Address in Network Core Thread-Index: Acz9EbT/Irz+o/sQQpmcdItexjh8fA== From: "Michael Behringer (mbehring)" To: X-OriginalArrivalTime: 08 Mar 2012 09:56:18.0964 (UTC) FILETIME=[B5956540:01CCFD11] X-Mailman-Approved-At: Thu, 08 Mar 2012 07:48:38 -0800 Subject: [v6ops] New Draft: Using Only Link-Local Address in Network Core X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 09:56:39 -0000 V6ops WG,=20 Eric and myself published a new draft, which is in the context of v6ops. We'd like to solicit feedback.=20 We feel there are substantial advantages to only using link-local addresses on core links, and propose this model as a "best common practice". However, there are some caveats.=20 Our draft lists advantages and disadvantages to allow network operators to make a factual decision on whether this model fits their needs.=20 Feedback? Michael http://wiki.tools.ietf.org/html/draft-behringer-lla-only-00 > -- > Using Only Link-Local Address in Network Core > draft-behringer-lla-only-00 >=20 > Abstract >=20 > This document proposes to use only IPv6 link-local addresses on > infrastructure links between routers, wherever possible. It > discusses the advantages and disadvantages of this approach to aide > the decision process for a given network, > -- From mohacsi@niif.hu Thu Mar 8 08:35:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D4C721F86B8 for ; Thu, 8 Mar 2012 08:35:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.446 X-Spam-Level: X-Spam-Status: No, score=0.446 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, J_CHICKENPOX_13=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 al-qxg5c1VaN for ; Thu, 8 Mar 2012 08:35:42 -0800 (PST) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by ietfa.amsl.com (Postfix) with ESMTP id 7176921F86B5 for ; Thu, 8 Mar 2012 08:35:42 -0800 (PST) Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by mail.ki.iif.hu (Postfix) with ESMTP id CFC9487A4E; Thu, 8 Mar 2012 17:35:40 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id uOr0rLfvLb93; Thu, 8 Mar 2012 17:35:35 +0100 (CET) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 2080D87A49; Thu, 8 Mar 2012 17:35:35 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 1F19387A14; Thu, 8 Mar 2012 17:35:35 +0100 (CET) Date: Thu, 8 Mar 2012 17:35:35 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: "Michael Behringer (mbehring)" In-Reply-To: <51865E1A72F61D48A247348DCCBA5CFB05B9154C@XMB-AMS-105.cisco.com> Message-ID: References: <51865E1A72F61D48A247348DCCBA5CFB05B9154C@XMB-AMS-105.cisco.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 16:35:43 -0000 Hi Michael, We are using such a setup for more than 6-8 years now. I always talking advantages and disadvantages of using link-local addresses on various IPv6 tutorial. I did not think it should have been documented as a draft, but if you think worth it, I can support it. (NB: are there any draft to use private IPv4 addresses in the Network Core? ) Janos Mohacsi Head of HBONE+ project Network Engineer, Deputy Director of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Thu, 8 Mar 2012, Michael Behringer (mbehring) wrote: > V6ops WG, > > Eric and myself published a new draft, which is in the context of v6ops. > We'd like to solicit feedback. > > We feel there are substantial advantages to only using link-local > addresses on core links, and propose this model as a "best common > practice". However, there are some caveats. > > Our draft lists advantages and disadvantages to allow network operators > to make a factual decision on whether this model fits their needs. > > Feedback? > Michael > > > http://wiki.tools.ietf.org/html/draft-behringer-lla-only-00 > >> -- >> Using Only Link-Local Address in Network Core >> draft-behringer-lla-only-00 >> >> Abstract >> >> This document proposes to use only IPv6 link-local addresses on >> infrastructure links between routers, wherever possible. It >> discusses the advantages and disadvantages of this approach to aide >> the decision process for a given network, >> -- > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From lorenzo@google.com Thu Mar 8 08:39:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A032321F871D for ; Thu, 8 Mar 2012 08:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.763 X-Spam-Level: X-Spam-Status: No, score=-102.763 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 a54QAOwvGsUs for ; Thu, 8 Mar 2012 08:39:53 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1F47C21F870A for ; Thu, 8 Mar 2012 08:39:53 -0800 (PST) Received: by obbta4 with SMTP id ta4so993452obb.31 for ; Thu, 08 Mar 2012 08:39:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=B82WuWGHaODRUI74YA1XVgJdWWzCEnhUKQssdLy5TFc=; b=okj5mVmaKUe42iphQinkd58NHcLwpL9UgEqxIA/dOS2aAnrxFKDo/z4wrzVIZSJ/lz bTDJ+NHxNjJjG1Lq1yhxEWUb0wqsojR61zfROWjZlFdnjhmJQR0YcRNXzoO8TWJ4ymE5 GHHptah9aolDen7NK2c2l3aiqLuIxKnWX5KzXQxqh9AyoSjB9uYEi4WndYj6rd09tF8y hC8SoT3L+2O3DZjkfAl8ZMZZ8YptAN4t9Pf079KXWP/lfA+dChyIja7DE3SQymaMPRK8 uGapkPL//84AlWWF6Gn005ib2pY1mrta+mveekStbXZbpZzhqahBh3lWaeJZj8Nr68MA zgnA== Received: by 10.182.216.41 with SMTP id on9mr2749156obc.18.1331224792725; Thu, 08 Mar 2012 08:39:52 -0800 (PST) Received: by 10.182.216.41 with SMTP id on9mr2749152obc.18.1331224792609; Thu, 08 Mar 2012 08:39:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.5.67 with HTTP; Thu, 8 Mar 2012 08:39:32 -0800 (PST) In-Reply-To: <51865E1A72F61D48A247348DCCBA5CFB05B9154C@XMB-AMS-105.cisco.com> References: <51865E1A72F61D48A247348DCCBA5CFB05B9154C@XMB-AMS-105.cisco.com> From: Lorenzo Colitti Date: Fri, 9 Mar 2012 01:39:32 +0900 Message-ID: To: "Michael Behringer (mbehring)" Content-Type: multipart/alternative; boundary=f46d04478a7fe1340e04babdecda X-System-Of-Record: true X-Gm-Message-State: ALoCoQmdbfjXVkF6O0ZmcHexYuwZN71P/4l5xeN0WYh34/YC1xGiMN9Nfg/nRCa6AAvPEMhUDyFp6tHjrV6m4ahPzi0nL+qlyDUSeTNXwjrhTw0xGB39aPPuzXAbVd/S9bQSdFu85JTn Cc: v6ops@ietf.org Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 16:39:53 -0000 --f46d04478a7fe1340e04babdecda Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 8, 2012 at 18:56, Michael Behringer (mbehring) < mbehring@cisco.com> wrote: > Feedback? > "We therefore conclude that it is possible to construct a working network in this way." Did you conclude so by building a working network, or did you just conclude so while writing this draft? :-> But yes, it works. I've designed a network or two in this way over the years, and I'm sure I'm not the only one. --f46d04478a7fe1340e04babdecda Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 8, 2012 at 18:56, Michael Behringer = (mbehring) <mbeh= ring@cisco.com> wrote:
Feedback?

"We therefore conclude t= hat it is possible to construct a working=A0network in this way."

Did you conclude so by building a working network, or = did you just conclude so while writing this draft? :->

But yes, it works. I've designed a network or two i= n this way over the years, and I'm sure I'm not the only one.
=
--f46d04478a7fe1340e04babdecda-- From rajiva@cisco.com Thu Mar 8 08:41:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25FA21F85F0 for ; Thu, 8 Mar 2012 08:41:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.408 X-Spam-Level: X-Spam-Status: No, score=-9.408 tagged_above=-999 required=5 tests=[AWL=0.591, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 Bsnm+X+4dV3U for ; Thu, 8 Mar 2012 08:41:29 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1940521F85E7 for ; Thu, 8 Mar 2012 08:41:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=2690; q=dns/txt; s=iport; t=1331224889; x=1332434489; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=Tv1C85F5rFoQKzS8CXOdyHsmSjC+2YtaDVSs7d5jNZA=; b=SU2T9YuznV8uc72d2gtlGLN8tVl9l0nsD93TCmPHc6L8ApsLjec9UOXD xlo3wdGMxGg+tVfcj7B1lmNqxFQ5qX9C2XhCOKDV28xJ9oZomHz/DDctO t9yLxeKQrJKYhLtvJFMxkc9ExuecxUTmFwgMmxgNAXe4MiejdL8DKYrsD E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJDgWE+tJV2d/2dsb2JhbABDtR2BB4IKAQEBBAEBAQ8BHQo0CwwEAgEIEQQBAQEKBhcBBgEmHwkIAQEEARIIGodoC5tPAZ8YkAtjBIhSiROTeIMC X-IronPort-AV: E=Sophos;i="4.73,552,1325462400"; d="scan'208";a="64857207" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 08 Mar 2012 16:41:28 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q28GfS2p015505; Thu, 8 Mar 2012 16:41:28 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 10:41:28 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Mar 2012 10:41:27 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C0795D3B3@XMB-RCD-111.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] New Draft: Using Only Link-Local Address in Network Core Thread-Index: Acz9SYgKi3/wEseSQU+o1DBy+DYaQwAAHMJQ References: <51865E1A72F61D48A247348DCCBA5CFB05B9154C@XMB-AMS-105.cisco.com> From: "Rajiv Asati (rajiva)" To: "Mohacsi Janos" , "Michael Behringer (mbehring)" X-OriginalArrivalTime: 08 Mar 2012 16:41:28.0729 (UTC) FILETIME=[4F552890:01CCFD4A] Cc: v6ops@ietf.org Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 16:41:30 -0000 Janos, Good point.=20 IMO, it is well worth documenting it as BCP. I would shy away from comparing LL with private IPv4. I would argue that using LL brings interesting set of challenges that never existed with private IPv4. So, it is important to document those challenges (and possible workarounds) while considering LL-only. BCP is a good venue for that. Cheers, Rajiv > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Mohacsi Janos > Sent: Thursday, March 08, 2012 11:36 AM > To: Michael Behringer (mbehring) > Cc: v6ops@ietf.org > Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network > Core >=20 > Hi Michael, >=20 > We are using such a setup for more than 6-8 years now. I always > talking advantages and disadvantages of using link-local addresses on > various IPv6 tutorial. I did not think it should have been documented as a > draft, but if you think worth it, I can support it. (NB: are there any > draft to use private IPv4 addresses in the Network Core? ) >=20 > Janos Mohacsi > Head of HBONE+ project > Network Engineer, Deputy Director of Network Planning and Projects > NIIF/HUNGARNET, HUNGARY > Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 >=20 > On Thu, 8 Mar 2012, Michael Behringer (mbehring) wrote: >=20 > > V6ops WG, > > > > Eric and myself published a new draft, which is in the context of v6ops. > > We'd like to solicit feedback. > > > > We feel there are substantial advantages to only using link-local > > addresses on core links, and propose this model as a "best common > > practice". However, there are some caveats. > > > > Our draft lists advantages and disadvantages to allow network operators > > to make a factual decision on whether this model fits their needs. > > > > Feedback? > > Michael > > > > > > http://wiki.tools.ietf.org/html/draft-behringer-lla-only-00 > > > >> -- > >> Using Only Link-Local Address in Network Core > >> draft-behringer-lla-only-00 > >> > >> Abstract > >> > >> This document proposes to use only IPv6 link-local addresses on > >> infrastructure links between routers, wherever possible. It > >> discusses the advantages and disadvantages of this approach to aide > >> the decision process for a given network, > >> -- > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From sthaug@nethelp.no Thu Mar 8 08:58:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7888B21F8630 for ; Thu, 8 Mar 2012 08:58:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 WMlfVAFLmq9A for ; Thu, 8 Mar 2012 08:58:08 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 7AE9521F8622 for ; Thu, 8 Mar 2012 08:58:07 -0800 (PST) Received: (qmail 5263 invoked from network); 8 Mar 2012 16:58:05 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 8 Mar 2012 16:58:05 -0000 Date: Thu, 08 Mar 2012 17:58:05 +0100 (CET) Message-Id: <20120308.175805.74752111.sthaug@nethelp.no> To: mohacsi@niif.hu From: sthaug@nethelp.no In-Reply-To: References: <51865E1A72F61D48A247348DCCBA5CFB05B9154C@XMB-AMS-105.cisco.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, mbehring@cisco.com Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 16:58:08 -0000 > We are using such a setup for more than 6-8 years now. I always > talking advantages and disadvantages of using link-local addresses on > various IPv6 tutorial. I did not think it should have been documented as a > draft, but if you think worth it, I can support it. (NB: are there any > draft to use private IPv4 addresses in the Network Core? ) There are several networks using private IPv4 addresses in the network core. This often breaks traceroute, since the ICMP replies tend to be sourced using the (private) interface address and many *other* networks block private IPv4 addresses at the borders. Also, a private IPv4 address is of course semantically different from a link-local address. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From gert@space.net Thu Mar 8 09:30:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3043321F85F4 for ; Thu, 8 Mar 2012 09:30:41 -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_13=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 XOnouat6i8eb for ; Thu, 8 Mar 2012 09:30:40 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 711EB21F85F2 for ; Thu, 8 Mar 2012 09:30:39 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 55C2FF8A77 for ; Thu, 8 Mar 2012 18:30:38 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 43D74F8A6C for ; Thu, 8 Mar 2012 18:30:38 +0100 (CET) Received: (qmail 82857 invoked by uid 1007); 8 Mar 2012 18:30:38 +0100 Date: Thu, 8 Mar 2012 18:30:38 +0100 From: Gert Doering To: "Michael Behringer \(mbehring\)" Message-ID: <20120308173038.GI84425@Space.Net> References: <51865E1A72F61D48A247348DCCBA5CFB05B9154C@XMB-AMS-105.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <51865E1A72F61D48A247348DCCBA5CFB05B9154C@XMB-AMS-105.cisco.com> X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 17:30:41 -0000 Hi, On Thu, Mar 08, 2012 at 10:56:18AM +0100, Michael Behringer (mbehring) wrote: > Eric and myself published a new draft, which is in the context of v6ops. > We'd like to solicit feedback. > > We feel there are substantial advantages to only using link-local > addresses on core links, and propose this model as a "best common > practice". However, there are some caveats. > > Our draft lists advantages and disadvantages to allow network operators > to make a factual decision on whether this model fits their needs. > > Feedback? It might make sense for some, but I would oppose to make this a BCP (which is another word for "we recommend that everbody does this"). We *like* using global scoped IPv4 and IPv6 addresses everywhere, because it helps a lot with diagnostics ("traceroute will tell you, which of the 4 possible links the packet traverses", "be able to run ping tests from your monitoring box to specific interfaces, to see if *this* link is up"). Of course you need iACLs if you do that. > > Abstract > > > > This document proposes to use only IPv6 link-local addresses on > > infrastructure links between routers, wherever possible. It > > discusses the advantages and disadvantages of this approach to aide > > the decision process for a given network, I'm perfectly fine with that abstract. I just want to be sure that this practice isn't advocated as a BCP to do so (because next thing our customers or some crazy auditors will tell us that we do it all wrong). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From SRS0=FhjX=BP=WPI.EDU=cra@srs.wpi.edu Thu Mar 8 09:37:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B14921F86C4 for ; Thu, 8 Mar 2012 09:37:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 IOaQ2P+Hnln4 for ; Thu, 8 Mar 2012 09:37:23 -0800 (PST) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by ietfa.amsl.com (Postfix) with ESMTP id 1248A21F86BA for ; Thu, 8 Mar 2012 09:37:14 -0800 (PST) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q28HbEwP018437 for ; Thu, 8 Mar 2012 12:37:14 -0500 X-DKIM: Sendmail DKIM Filter v2.8.3 MAIL1.WPI.EDU q28HbEwP018437 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1331228234; bh=nZjAjkSwPitHaVDQJqaqz+rfqICrzvVffloUTnZ4CQQ=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=hvDY7152qYk0njvLMAYIAL/deLKfkfCZbCIA6pQ+bmLgCzJGADQhJYkqCWXDRTx0e hB2AJt0yJzLZ9AeJVdpFqIXDlUbaQXNApyWs3joLY4XVjruqiFS9OB+xePHhiPwOBr Z/fojS1483MNT2whH3Knv/lKh+Zx0R2d1aG1YnvI= Received: from SMTP.WPI.EDU (SMTP.WPI.EDU [130.215.36.186]) by MAIL1.WPI.EDU (8.14.5/8.14.5) with ESMTP id q28HbET5018434 for ; Thu, 8 Mar 2012 12:37:14 -0500 Received: from angus.ind.WPI.EDU (ANGUS.IND.WPI.EDU [130.215.130.21]) by SMTP.WPI.EDU (8.14.4/8.14.4) with ESMTP id q28HbD4Q010074 for ; Thu, 8 Mar 2012 12:37:13 -0500 (envelope-from cra@WPI.EDU) Received: from angus.ind.WPI.EDU (angus.ind.WPI.EDU [127.0.0.1]) by angus.ind.WPI.EDU (8.14.2/8.14.2) with ESMTP id q28HbCj2008321 for ; Thu, 8 Mar 2012 12:37:12 -0500 Received: (from cra@localhost) by angus.ind.WPI.EDU (8.14.2/8.14.2/Submit) id q28HbCj0008319 for v6ops@ietf.org; Thu, 8 Mar 2012 12:37:12 -0500 X-Authentication-Warning: angus.ind.WPI.EDU: cra set sender to cra@WPI.EDU using -f Date: Thu, 8 Mar 2012 12:37:12 -0500 From: Chuck Anderson To: v6ops@ietf.org Message-ID: <20120308173712.GT22535@angus.ind.WPI.EDU> References: <51865E1A72F61D48A247348DCCBA5CFB05B9154C@XMB-AMS-105.cisco.com> <20120308173038.GI84425@Space.Net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120308173038.GI84425@Space.Net> User-Agent: Mutt/1.5.18 (2008-05-17) Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 17:48:08 -0000 On Thu, Mar 08, 2012 at 06:30:38PM +0100, Gert Doering wrote: > > > Abstract > > > > > > This document proposes to use only IPv6 link-local addresses on > > > infrastructure links between routers, wherever possible. It > > > discusses the advantages and disadvantages of this approach to aide > > > the decision process for a given network, > > I'm perfectly fine with that abstract. I just want to be sure that > this practice isn't advocated as a BCP to do so (because next thing our > customers or some crazy auditors will tell us that we do it all wrong). Perhaps the draft could be reworked to be a comparison and overview of both techniques, LLA and global addressing, and their pros/cons without having a position/recommendation/BCP for either method. From gert@space.net Thu Mar 8 09:55:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E50E021F84CE for ; Thu, 8 Mar 2012 09:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 mDuNdEwMFxkE for ; Thu, 8 Mar 2012 09:55:29 -0800 (PST) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id A493321F84C9 for ; Thu, 8 Mar 2012 09:55:27 -0800 (PST) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id DF196F8A70 for ; Thu, 8 Mar 2012 18:55:26 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id CCB74F8A71 for ; Thu, 8 Mar 2012 18:55:26 +0100 (CET) Received: (qmail 89992 invoked by uid 1007); 8 Mar 2012 18:55:26 +0100 Date: Thu, 8 Mar 2012 18:55:26 +0100 From: Gert Doering To: Chuck Anderson Message-ID: <20120308175526.GK84425@Space.Net> References: <51865E1A72F61D48A247348DCCBA5CFB05B9154C@XMB-AMS-105.cisco.com> <20120308173038.GI84425@Space.Net> <20120308173712.GT22535@angus.ind.WPI.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120308173712.GT22535@angus.ind.WPI.EDU> X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 17:55:30 -0000 Hi, On Thu, Mar 08, 2012 at 12:37:12PM -0500, Chuck Anderson wrote: > Perhaps the draft could be reworked to be a comparison and overview of > both techniques, LLA and global addressing, and their pros/cons > without having a position/recommendation/BCP for either method. Without having read the draft yet - this format is something I would be perfectly happy with, and having a conclusive list of pros/cons to point people at to help decisions would certainly be useful. Well, now it's obviously at me to actually read it and provide somewhat more complete feedback than "read the word BCP and start screaming" :-) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From brian.e.carpenter@gmail.com Thu Mar 8 11:31:36 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B68321F85FF for ; Thu, 8 Mar 2012 11:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.486 X-Spam-Level: X-Spam-Status: No, score=-103.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 PpjmKOLpqbB7 for ; Thu, 8 Mar 2012 11:31:35 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3A83621F85F6 for ; Thu, 8 Mar 2012 11:31:35 -0800 (PST) Received: by eeke51 with SMTP id e51so277345eek.31 for ; Thu, 08 Mar 2012 11:31:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=9Tvf+NppZf5DSdID0EcvDxdocgw0aBtKdZd7oIFKGwM=; b=xQrb8/NzaOlubHVPcGDG1P8VlsmzNNRobAFFyDzPQpMrcI+VZ8B+UwR/AjCxgl+W2F lW7G7onmaxLSFOAX4diS39DwqCketlh9Ic1FjUIxUIz8U7+0YPXMZVNAk1GIpqwCZsDv LnuYoXnylmk9cBVBYJXHwjMoI0NuGHo68ld8ZMikpvVlXhLjWil55XUn+Sq7KsSf5Ua5 PQnTKTgWMxCIKy3Elb6d9ywxz58sk/qcKhja49grfGjjSQzgUfXRTpmoAkl8gPgWi/T3 g/EQaMcWXuPv/ZDAb3AXs5EGNxfxsBEyv7RYCcGoT/qc5bKY0gJx8Pp6VPytECPgTN5j fSPA== Received: by 10.14.99.1 with SMTP id w1mr2622231eef.49.1331235094443; Thu, 08 Mar 2012 11:31:34 -0800 (PST) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id h47sm9425163eea.10.2012.03.08.11.31.30 (version=SSLv3 cipher=OTHER); Thu, 08 Mar 2012 11:31:33 -0800 (PST) Message-ID: <4F59090D.8000901@gmail.com> Date: Fri, 09 Mar 2012 08:31:25 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Gert Doering References: <51865E1A72F61D48A247348DCCBA5CFB05B9154C@XMB-AMS-105.cisco.com> <20120308173038.GI84425@Space.Net> <20120308173712.GT22535@angus.ind.WPI.EDU> <20120308175526.GK84425@Space.Net> In-Reply-To: <20120308175526.GK84425@Space.Net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 19:31:36 -0000 On 2012-03-09 06:55, Gert Doering wrote: > Hi, > > On Thu, Mar 08, 2012 at 12:37:12PM -0500, Chuck Anderson wrote: >> Perhaps the draft could be reworked to be a comparison and overview of >> both techniques, LLA and global addressing, and their pros/cons >> without having a position/recommendation/BCP for either method. > > Without having read the draft yet - this format is something I would > be perfectly happy with, and having a conclusive list of pros/cons > to point people at to help decisions would certainly be useful. Agreed. I haven't actually *read* the draft yet, but this did catch my eye: >> ICMPv6 [RFC4443] error messages (packet-too-big...) are required for >> routers, therefore a loopback interface must be configured with a >> global scope IPv6 address. This global scope IPv6 address will be >> used as the source IPv6 address for all generated ICMPv6 messages. I'm glad to see that and it merits a MUST in some normative document, even if this one is not a BCP. On the same point: >> Traceroute: Similar to the ping case, a reply to a traceroute packet >> would come from a loopback address with a global address. Today this >> does not display the specific interface the packets came in on. Also >> here, RFC5837 [RFC5837] provides a solution. There is a genuine source of confusion possible here for a typical traceroute user, even if not interested in the specific interface. I've seen cases where the traceroute reply came from a global address that was actually a PA address from an ISP that was not actually on the path, because the router had multiple interfaces with PA addresses from several ISPs. So it's actually important that the global address used for ICMP replies, even if it's a loopback address, is under a prefix that belongs to the organisation operating the router in question. Brian From wesley.george@twcable.com Thu Mar 8 11:34:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D7C21F865F; Thu, 8 Mar 2012 11:34:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.73 X-Spam-Level: X-Spam-Status: No, score=-0.73 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, 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 RHxnQszaw05c; Thu, 8 Mar 2012 11:34:00 -0800 (PST) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3AA21F8675; Thu, 8 Mar 2012 11:33:59 -0800 (PST) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.73,552,1325480400"; d="scan'208";a="350828265" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 08 Mar 2012 14:33:38 -0500 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Thu, 8 Mar 2012 14:33:59 -0500 From: "George, Wes" To: Chuck Anderson , "v6ops@ietf.org" , Anthony Kirkham Date: Thu, 8 Mar 2012 14:33:58 -0500 Thread-Topic: [v6ops] New Draft: Using Only Link-Local Address in Network Core Thread-Index: Acz9U6RMQtPs5mv8S7uNO+xYhpWncgADegtw Message-ID: References: <51865E1A72F61D48A247348DCCBA5CFB05B9154C@XMB-AMS-105.cisco.com> <20120308173038.GI84425@Space.Net> <20120308173712.GT22535@angus.ind.WPI.EDU> In-Reply-To: <20120308173712.GT22535@angus.ind.WPI.EDU> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "grow@ietf.org" Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 19:34:01 -0000 The proposed comparison already pretty much exists within a draft written a= nd being adopted in GROW. http://tools.ietf.org/html/draft-kirkham-private-ip-sp-cores-02 I'm thinking that perhaps the authors of the two drafts need to get togethe= r and either bolster the discussion around IPv6 and link-local in the curre= nt Kirkham draft, or turn this new draft into a companion document to -kirk= ham so that we end up with two non-overlapping drafts, one that covers IPv4= and one that covers IPv6 with a similar format. Thanks, Wes George > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Chuck Anderson > Sent: Thursday, March 08, 2012 12:37 PM > To: v6ops@ietf.org > Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network = Core > http://wiki.tools.ietf.org/html/draft-behringer-lla-only-00 > On Thu, Mar 08, 2012 at 06:30:38PM +0100, Gert Doering wrote: > > > > Abstract > > > > > > > > This document proposes to use only IPv6 link-local addresses on > > > > infrastructure links between routers, wherever possible. It > > > > discusses the advantages and disadvantages of this approach to ai= de > > > > the decision process for a given network, > > > > I'm perfectly fine with that abstract. I just want to be sure that > > this practice isn't advocated as a BCP to do so (because next thing our > > customers or some crazy auditors will tell us that we do it all wrong). > > Perhaps the draft could be reworked to be a comparison and overview of > both techniques, LLA and global addressing, and their pros/cons > without having a position/recommendation/BCP for either method. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From internet-drafts@ietf.org Thu Mar 8 11:58:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0793D21F8687; Thu, 8 Mar 2012 11:58:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 U6UkR86oSRMg; Thu, 8 Mar 2012 11:57:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1A221E801C; Thu, 8 Mar 2012 11:57:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120308195759.14484.86851.idtracker@ietfa.amsl.com> Date: Thu, 08 Mar 2012 11:57:59 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ra-guard-implementation-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 19:58:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : Implementation Advice for IPv6 Router Advertisement Guar= d (RA-Guard) Author(s) : Fernando Gont Filename : draft-ietf-v6ops-ra-guard-implementation-02.txt Pages : 18 Date : 2012-03-08 The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly employed to mitigate attack vectors based on forged ICMPv6 Router Advertisement messages. Many existing IPv6 deployments rely on RA- Guard as the first line of defense against the aforementioned attack vectors. However, some implementations of RA-Guard have been found to be prone to circumvention by employing IPv6 Extension Headers. This document describes the evasion techniques that affect the aforementioned implementations, and provides advice on the implementation of RA-Guard, such that the RA-Guard evasion vectors are eliminated. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ra-guard-implementatio= n-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-ra-guard-implementation= -02.txt From rajiva@cisco.com Thu Mar 8 11:59:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9AF21E8039; Thu, 8 Mar 2012 11:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.434 X-Spam-Level: X-Spam-Status: No, score=-9.434 tagged_above=-999 required=5 tests=[AWL=0.565, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 Ae9MdGNTXjOe; Thu, 8 Mar 2012 11:59:57 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id C002421E802B; Thu, 8 Mar 2012 11:59:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=3320; q=dns/txt; s=iport; t=1331236798; x=1332446398; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=RGvUbd1jdAg2WJv4JSzN0Eygy15JLQDqNRWwclJUTA0=; b=lYFrWv4Z6CqMix6FenggMvp0XwjCZftphJ9h5ToAhoByNzdnrGjnbhV/ p6VyaBPGRzfeBzD1mdMgxCMwmXBz0lYgd9/YzhX+Sdajw9MUZduklDzLG 7Se8BnFJb1T1WIz3F5AyR4Ij/i4cGcC8rqL1xg46P730Pa3CipWfc2NaK Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAH4OWU+tJXG//2dsb2JhbABDDrUbgQeCCgEBAQQBAQEPAR0KNAQHDAYBCBEEAQEBCgYXAQcmHwkJAQQBEggah2gLmz8Bnw6KKIVLYwSIUp0LgixWgT0 X-IronPort-AV: E=Sophos;i="4.73,553,1325462400"; d="scan'208";a="64925322" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 08 Mar 2012 19:59:57 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q28Jxvrr008952; Thu, 8 Mar 2012 19:59:57 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 13:59:57 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Mar 2012 13:59:55 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C0795D53E@XMB-RCD-111.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] New Draft: Using Only Link-Local Address in Network Core Thread-Index: Acz9U6RMQtPs5mv8S7uNO+xYhpWncgADegtwAAD6z8A= From: "Rajiv Asati (rajiva)" To: "George, Wes" , "Chuck Anderson" , , "AnthonyKirkham" X-OriginalArrivalTime: 08 Mar 2012 19:59:57.0165 (UTC) FILETIME=[095049D0:01CCFD66] Cc: grow@ietf.org Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 19:59:58 -0000 Hi Wes, That draft (in GROW) is mostly for IPv4 network, not for IPv6 network. Nonetheless, you have a point. =20 Cheers Rajiv=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of George, Wes > Sent: Thursday, March 08, 2012 2:34 PM > To: Chuck Anderson; v6ops@ietf.org; AnthonyKirkham > Cc: grow@ietf.org > Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network > Core >=20 > The proposed comparison already pretty much exists within a draft written > and being adopted in GROW. >=20 > http://tools.ietf.org/html/draft-kirkham-private-ip-sp-cores-02 >=20 >=20 > I'm thinking that perhaps the authors of the two drafts need to get together > and either bolster the discussion around IPv6 and link-local in the current > Kirkham draft, or turn this new draft into a companion document to -kirkham > so that we end up with two non-overlapping drafts, one that covers IPv4 and > one that covers IPv6 with a similar format. >=20 > Thanks, >=20 > Wes George >=20 > > -----Original Message----- > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of > > Chuck Anderson > > Sent: Thursday, March 08, 2012 12:37 PM > > To: v6ops@ietf.org > > Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network > Core > > >=20 > http://wiki.tools.ietf.org/html/draft-behringer-lla-only-00 >=20 > > On Thu, Mar 08, 2012 at 06:30:38PM +0100, Gert Doering wrote: > > > > > Abstract > > > > > > > > > > This document proposes to use only IPv6 link-local addresses on > > > > > infrastructure links between routers, wherever possible. It > > > > > discusses the advantages and disadvantages of this approach to aide > > > > > the decision process for a given network, > > > > > > I'm perfectly fine with that abstract. I just want to be sure that > > > this practice isn't advocated as a BCP to do so (because next thing our > > > customers or some crazy auditors will tell us that we do it all wrong). > > > > Perhaps the draft could be reworked to be a comparison and overview of > > both techniques, LLA and global addressing, and their pros/cons > > without having a position/recommendation/BCP for either method. > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops >=20 > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely for > the use of the individual or entity to which it is addressed. If you are not the > intended recipient of this E-mail, you are hereby notified that any > dissemination, distribution, copying, or action taken in relation to the > contents of and attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify the sender > immediately and permanently delete the original and any copy of this E-mail > and any printout. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From rajiva@cisco.com Thu Mar 8 12:29:07 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E54A821E8021 for ; Thu, 8 Mar 2012 12:29:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.448 X-Spam-Level: X-Spam-Status: No, score=-9.448 tagged_above=-999 required=5 tests=[AWL=0.551, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 s0m7p9BVJC6S for ; Thu, 8 Mar 2012 12:29:07 -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 47FE921E801C for ; Thu, 8 Mar 2012 12:29:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=2969; q=dns/txt; s=iport; t=1331238547; x=1332448147; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=BUbYCFvoZGXrJ1sj0UMBMILnVKKjM63ZXHtex47vARw=; b=Q2QB49R990dOmVy4UH+OB3LFOjBbud6o9gxNm7me4CO6NcodCUHYguXI 0gRKU1mYgYM/jgPQggsTynJ8SaBS/aPlSxNrXGcb1ICmfv2tUPyL2Bz6Y rEv0CuFsIIFdtUmV2SD3uvhiniV9DhVNebD9VwIwtR1o0Stj9rBXseVGD g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAOsVWU+tJXG9/2dsb2JhbABDtSmBB4IKAQEBAwEBAQEPAR0KNAsFBwQCAQgRBAEBAQoGFwEGASYfCQgBAQQBEggTB4djBQubNgGfBASPc2MEiFKdC4MC X-IronPort-AV: E=Sophos;i="4.73,553,1325462400"; d="scan'208";a="64938627" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 08 Mar 2012 20:29:07 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q28KT6Yj001594; Thu, 8 Mar 2012 20:29:06 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 14:29:06 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Mar 2012 14:29:05 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C0795D56A@XMB-RCD-111.cisco.com> In-Reply-To: <4F59090D.8000901@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] New Draft: Using Only Link-Local Address in Network Core Thread-Index: Acz9YhoQ+GW7xSELR5CiRs4yt5tddQAB79/A References: <51865E1A72F61D48A247348DCCBA5CFB05B9154C@XMB-AMS-105.cisco.com> <20120308173038.GI84425@Space.Net> <20120308173712.GT22535@angus.ind.WPI.EDU><20120308175526.GK84425@Space.Net> <4F59090D.8000901@gmail.com> From: "Rajiv Asati (rajiva)" To: "Brian E Carpenter" , "Gert Doering" X-OriginalArrivalTime: 08 Mar 2012 20:29:06.0651 (UTC) FILETIME=[1C16AAB0:01CCFD6A] Cc: v6ops@ietf.org Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 20:29:08 -0000 Brian, > addresses from several ISPs. So it's actually important that the > global address used for ICMP replies, even if it's a loopback address, > is under a prefix that belongs to the organisation operating the router > in question. Good point. This is worth adding in the next revision.=20 > I'm glad to see that and it merits a MUST in some normative document, > even if this one is not a BCP. Sure, it could be informational. But why would we not want it to be a BCP? =20 Cheers Rajiv > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Brian E Carpenter > Sent: Thursday, March 08, 2012 2:31 PM > To: Gert Doering > Cc: v6ops@ietf.org > Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network > Core >=20 > On 2012-03-09 06:55, Gert Doering wrote: > > Hi, > > > > On Thu, Mar 08, 2012 at 12:37:12PM -0500, Chuck Anderson wrote: > >> Perhaps the draft could be reworked to be a comparison and overview of > >> both techniques, LLA and global addressing, and their pros/cons > >> without having a position/recommendation/BCP for either method. > > > > Without having read the draft yet - this format is something I would > > be perfectly happy with, and having a conclusive list of pros/cons > > to point people at to help decisions would certainly be useful. >=20 > Agreed. I haven't actually *read* the draft yet, but this did catch my > eye: >=20 > >> ICMPv6 [RFC4443] error messages (packet-too-big...) are required for > >> routers, therefore a loopback interface must be configured with a > >> global scope IPv6 address. This global scope IPv6 address will be > >> used as the source IPv6 address for all generated ICMPv6 messages. >=20 > I'm glad to see that and it merits a MUST in some normative document, > even if this one is not a BCP. >=20 > On the same point: >=20 > >> Traceroute: Similar to the ping case, a reply to a traceroute packet > >> would come from a loopback address with a global address. Today this > >> does not display the specific interface the packets came in on. Also > >> here, RFC5837 [RFC5837] provides a solution. >=20 > There is a genuine source of confusion possible here for a typical > traceroute user, even if not interested in the specific interface. > I've seen cases where the traceroute reply came from a global address > that was actually a PA address from an ISP that was not actually > on the path, because the router had multiple interfaces with PA > addresses from several ISPs. So it's actually important that the > global address used for ICMP replies, even if it's a loopback address, > is under a prefix that belongs to the organisation operating the router > in question. >=20 > Brian > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From sthaug@nethelp.no Thu Mar 8 13:09:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFAB21F8694 for ; Thu, 8 Mar 2012 13:09:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 WYcGHOTQ6ZHM for ; Thu, 8 Mar 2012 13:09:27 -0800 (PST) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by ietfa.amsl.com (Postfix) with SMTP id 2C1C221F8691 for ; Thu, 8 Mar 2012 13:09:23 -0800 (PST) Received: (qmail 13401 invoked from network); 8 Mar 2012 21:09:21 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 8 Mar 2012 21:09:21 -0000 Date: Thu, 08 Mar 2012 22:09:21 +0100 (CET) Message-Id: <20120308.220921.41635923.sthaug@nethelp.no> To: rajiva@cisco.com From: sthaug@nethelp.no In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C0795D56A@XMB-RCD-111.cisco.com> References: <20120308175526.GK84425@Space.Net> <4F59090D.8000901@gmail.com> <067E6CE33034954AAC05C9EC85E2577C0795D56A@XMB-RCD-111.cisco.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 21:09:28 -0000 > > I'm glad to see that and it merits a MUST in some normative document, > > even if this one is not a BCP. > > Sure, it could be informational. > But why would we not want it to be a BCP? Because there *is* no agreement that this is "Best current practice"? I'm with Gert here - I want my links to have global addresses. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From fred@cisco.com Thu Mar 8 13:31:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B722921F8545 for ; Thu, 8 Mar 2012 13:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.964 X-Spam-Level: X-Spam-Status: No, score=-108.964 tagged_above=-999 required=5 tests=[AWL=1.635, 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 TcPEf5RN5EIF for ; Thu, 8 Mar 2012 13:31:12 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9F00B21F8525 for ; Thu, 8 Mar 2012 13:31:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=765; q=dns/txt; s=iport; t=1331242268; x=1332451868; h=from:subject:date:message-id:cc:to:mime-version: content-transfer-encoding; bh=vkIbfrZ6G22tFIgTil0V3sQC/ZlqaRqXuHAXMtizq1U=; b=Cf69tFfjMirk4Qfg5aA3IDiOObCOBg2mC7/75J+vVPm1u2dTpQvHfghr 7CfSlOsVSgw1KJLdqZs5zslq6Fi00NOziatYs6mIL4Xvg1vOt+Xg9Ecwg swUUOnG8A5rT6NqPjzoy5HOxufzlxi9K1cwHf1Vo9sleVaCUN9Hc3hwsr o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAEwkWU+rRDoG/2dsb2JhbABDtSmBB4IjASc/gXOHZ5tEAZ59jTSCP2MEiFCMdYVlijOCcg X-IronPort-AV: E=Sophos;i="4.73,554,1325462400"; d="scan'208";a="35217796" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 08 Mar 2012 21:31:08 +0000 Received: from Freds-Computer.local (tky-vpn-client-230-92.cisco.com [10.70.230.92]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q28LV6J1008860; Thu, 8 Mar 2012 21:31:07 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Fri, 09 Mar 2012 06:31:07 +0900 X-PGP-Universal: processed; by Freds-Computer.local on Fri, 09 Mar 2012 06:31:07 +0900 From: Fred Baker Date: Fri, 9 Mar 2012 06:30:53 +0900 Message-Id: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> To: v6ops@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops-chairs@tools.ietf.org, Ron Bonica Subject: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 21:31:15 -0000 This is to initiate a two week working group last call of = draft-ietf-v6ops-6204bis. Please read it now. If you find nits (spelling = errors, minor suggested wording changes, etc), comment to the authors; = if you find greater issues, such as disagreeing with a statement or = finding additional issues that need to be addressed, please post your = comments to the list. The draft will be on the agenda at IETF 83, and I = would like to send the authors home with a work plan to complete it if = it is not to the WG's liking. We are looking specifically for comments on the importance of the = document as well as its content. If you have read the document and = believe it to be of operational utility, that is also an important = comment to make.= From gvandeve@cisco.com Thu Mar 8 14:23:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5287F21E8065; Thu, 8 Mar 2012 14:23:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.519 X-Spam-Level: X-Spam-Status: No, score=-10.519 tagged_above=-999 required=5 tests=[AWL=0.080, 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 U-dLYY70dcu1; Thu, 8 Mar 2012 14:23:34 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFAE21F8622; Thu, 8 Mar 2012 14:23:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=1197; q=dns/txt; s=iport; t=1331245414; x=1332455014; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=SorALjr2JQ5E65Hrr2p1276RaT2vUK5NAyhDyw+qrfg=; b=QPbbYqH84wg/NWW2Y5vMJgUrgnQoCpw+JZU3DZq4nr/uE7iAQfcTS+rr ZYFTMtu/QP0LQDxH4hOIdFYUwgJ16pVnlcY37EV3MW/jq6NhXB84+cm7h kg0DoHWogEgBUkbMLZrsFYq6+qyXk9V7XvV8ssaQgRgLFMKlUPvJVJooJ U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAAwwWU+Q/khR/2dsb2JhbABDtSmBB4ILAQEEEgEdCj8QAgEIIgYYBgFWAQEEARoTB4doC5s+AZ54j3NjBKVdgmQ X-IronPort-AV: E=Sophos;i="4.73,554,1325462400"; d="scan'208";a="131768119" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 08 Mar 2012 22:23:32 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q28MNW4A015913; Thu, 8 Mar 2012 22:23:32 GMT Received: from xmb-ams-102.cisco.com ([144.254.74.77]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 23:23:32 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-hashedpuzzle: FT2B HRvN M8hf OGLw ORAL OZJ/ PWlV Uwmf WFy4 ZJeM bErj cNI8 gRxo kcoZ lJiU nwzH; 4; YgByAGkAYQBuAC4AZQAuAGMAYQByAHAAZQBuAHQAZQByAEAAZwBtAGEAaQBsAC4AYwBvAG0AOwBnAGUAcgB0AEAAcwBwAGEAYwBlAC4AbgBlAHQAOwBvAHAAcwBlAGMAQABpAGUAdABmAC4AbwByAGcAOwB2ADYAbwBwAHMAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {B833A991-48A8-41A0-B8E2-44C874B02303}; ZwB2AGEAbgBkAGUAdgBlAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Thu, 08 Mar 2012 22:23:23 GMT; UgBFADoAIABbAHYANgBvAHAAcwBdACAATgBlAHcAIABEAHIAYQBmAHQAOgAgAFUAcwBpAG4AZwAgAE8AbgBsAHkAIABMAGkAbgBrAC0ATABvAGMAYQBsACAAQQBkAGQAcgBlAHMAcwAgAGkAbgAgAE4AZQB0AHcAbwByAGsACQBDAG8AcgBlAA== MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable x-cr-puzzleid: {B833A991-48A8-41A0-B8E2-44C874B02303} Content-class: urn:content-classes:message Date: Thu, 8 Mar 2012 23:23:23 +0100 Message-ID: <5C99EC8C99D9BB45AC51D20DC2AD2DC5070CC4AB@XMB-AMS-102.cisco.com> In-Reply-To: <4F59090D.8000901@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] New Draft: Using Only Link-Local Address in Network Core Thread-Index: Acz9YhvAQlm+ygg7QLmlUlJzCncvFQAFoSKQ References: <51865E1A72F61D48A247348DCCBA5CFB05B9154C@XMB-AMS-105.cisco.com> <20120308173038.GI84425@Space.Net> <20120308173712.GT22535@angus.ind.WPI.EDU><20120308175526.GK84425@Space.Net> <4F59090D.8000901@gmail.com> From: "Gunter Van de Velde (gvandeve)" To: "Brian E Carpenter" , "Gert Doering" X-OriginalArrivalTime: 08 Mar 2012 22:23:32.0332 (UTC) FILETIME=[185A72C0:01CCFD7A] Cc: v6ops@ietf.org, opsec@ietf.org Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 22:23:35 -0000 >On the same point: > >>> Traceroute: Similar to the ping case, a reply to a traceroute packet >>> would come from a loopback address with a global address. Today this >>> does not display the specific interface the packets came in on. Also >>> here, RFC5837 [RFC5837] provides a solution. > >There is a genuine source of confusion possible here for a typical >traceroute user, even if not interested in the specific interface. >I've seen cases where the traceroute reply came from a global address >that was actually a PA address from an ISP that was not actually >on the path, because the router had multiple interfaces with PA >addresses from several ISPs. So it's actually important that the >global address used for ICMP replies, even if it's a loopback address, >is under a prefix that belongs to the organisation operating the router >in question. Also Passive-IPv6 addresses provide a way to have traceroute capabilities again to complement a LL-only infrastructure. (http://tools.ietf.org/html/draft-baker-opsec-passive-ip-address-00) The convenient element is that it doesn't require the ICMP stack to be changed and is box only behavior G/ From internet-drafts@ietf.org Thu Mar 8 15:03:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B42021E8048; Thu, 8 Mar 2012 15:03:05 -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 qGt-LTK9dIZK; Thu, 8 Mar 2012 15:03:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F43421E8021; Thu, 8 Mar 2012 15:03:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120308230305.4441.85868.idtracker@ietfa.amsl.com> Date: Thu, 08 Mar 2012 15:03:05 -0800 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 23:03:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : Basic Requirements for IPv6 Customer Edge Routers Author(s) : Hemant Singh Wes Beebee Chris Donley Barbara Stark Ole Troan Filename : draft-ietf-v6ops-6204bis-07.txt Pages : 21 Date : 2012-03-08 This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers IP transition technologies. Two transition technologies in RFC 5969's 6rd and RFC 6333's DS-Lite. are covered in the document. The document obsoletes RFC 6204, if approved. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6204bis-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-6204bis-07.txt From shemant@cisco.com Thu Mar 8 15:05:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A6B21E8052; Thu, 8 Mar 2012 15:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.062 X-Spam-Level: X-Spam-Status: No, score=-9.062 tagged_above=-999 required=5 tests=[AWL=0.937, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 fJzNa+BO2KWf; Thu, 8 Mar 2012 15:05:53 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id C617521E8021; Thu, 8 Mar 2012 15:05:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1861; q=dns/txt; s=iport; t=1331247952; x=1332457552; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=zjxX8YCWSCJsyMppOq95gaDBsTe/uwvBzLTaTFTLzkw=; b=Ezuxtp7GThd3q0z04ko8W7V7y3l9tuY1DiwNjANO4QZPYVePnALTro1w Ak3L2UjAR/1tbVACiAyvhGbVUdSb/ELlJLRvtZi+iE7IDxfUsEzQAGp9U G4wbCWT1B3jtbexzsWiIhDNj90OMTZdOn5e33/nnJztcjfiRpZqYoeJdz U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHA6WU+tJV2a/2dsb2JhbABCtTaBB4IKAQEBBAEBAQ8BHQo0CwwEAgEIEQQBAQsGFwEGASYfCQgBAQQBEggBGYdoC6APAZcKj3NjBIhSnQuDAg X-IronPort-AV: E=Sophos;i="4.73,554,1325462400"; d="scan'208";a="64967505" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 08 Mar 2012 23:05:52 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q28N5q6P032613; Thu, 8 Mar 2012 23:05:52 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 8 Mar 2012 17:05:52 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Mar 2012 17:05:51 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C304265518@XMB-RCD-109.cisco.com> In-Reply-To: <20120308230305.4441.85868.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-07.txt Thread-Index: Acz9f8lRgtAeCQfZScWQnEbbuBo6oQAABbQg References: <20120308230305.4441.85868.idtracker@ietfa.amsl.com> From: "Hemant Singh (shemant)" To: , X-OriginalArrivalTime: 08 Mar 2012 23:05:52.0361 (UTC) FILETIME=[02541D90:01CCFD80] Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-07.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Mar 2012 23:05:53 -0000 Folks, The only difference between this version in -07 and the -06 version is fixing of spellings and idnits. Regards, Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Thursday, March 08, 2012 6:03 PM To: i-d-announce@ietf.org Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-6204bis-07.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. Title : Basic Requirements for IPv6 Customer Edge Routers Author(s) : Hemant Singh Wes Beebee Chris Donley Barbara Stark Ole Troan Filename : draft-ietf-v6ops-6204bis-07.txt Pages : 21 Date : 2012-03-08 This document specifies requirements for an IPv6 Customer Edge (CE) router. Specifically, the current version of this document focuses on the basic provisioning of an IPv6 CE router and the provisioning of IPv6 hosts attached to it. The document also covers IP transition technologies. Two transition technologies in RFC 5969's 6rd and RFC 6333's DS-Lite. are covered in the document. The document obsoletes RFC 6204, if approved. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-6204bis-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-6204bis-07.txt _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From lorenzo@google.com Thu Mar 8 16:20:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F2E421E8061 for ; Thu, 8 Mar 2012 16:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.779 X-Spam-Level: X-Spam-Status: No, score=-102.779 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 RPG1U8Ik1bY6 for ; Thu, 8 Mar 2012 16:20:30 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D6E0B21E801B for ; Thu, 8 Mar 2012 16:20:23 -0800 (PST) Received: by obbta4 with SMTP id ta4so1517159obb.31 for ; Thu, 08 Mar 2012 16:20:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=Q7bYOZ9B3/kUewgO+HUDfGH7tNbX2wfddilyjYTKYjM=; b=l0Q/JSlGlfqE3rIRe2WjfuClFGAsBzCQwkyVY718ygo5jC0BN7L56Kap+e2RBiDHZl 7YigpdwvyUxbOI81IeU/bGLfUdH8H1WQUd37/1bFImVkQLYhhQIFFejsOJUCrzgKIe2Y xwxkhOCqY+Gy0/wlv9vVyLcGDvvQ0hwTjCoIERxT1N8zUy8H8mpC1ksUQzwi8ZkJn953 gHhlosi1hM+FrquJbBOYMZK6G29qbwLeSyAS+1XxjIBbm8rYvxbqQAcVMc6CaCZIZkzD GcKEKUcAWF1YumnjeM5wU60FxqI8w8M/oc3714SwvuNjA8MwpuQ+DlK/CF31vjCUJyLo 8WzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=Q7bYOZ9B3/kUewgO+HUDfGH7tNbX2wfddilyjYTKYjM=; b=Rh0WL7f3LuZBLAolCSE3uvP49NBfyGRY3z1yEf9mGVbyCoR8iVkx0nMRKFdOPRsvXW HnKKFT4VlPYZJe98C20a7nIZQjNfhYxcJD1FY2uRf2U1D/y0hZ4LusDAjVHnv8tqjnDJ 7lF2SiOyg6b4uICVfi95ZhDJnfdi2ABAvp9Fo8gY/cIx2MmBZuM46ha/I2vtSoY41Dl1 kdtbz7Y70Wi9Zxk6ufx2iR7EcNgE8vMCk4n3AZKCs6ObNwFwsdKxPuRDyc1y63MB9nXM xobEqFcOgI0S1Yq1VhL11JVB2kax6qbRI69yeBJurLSrsQ8FoF8q5zSdB6UOuZIxhjEG VTuQ== Received: by 10.60.4.10 with SMTP id g10mr83808oeg.18.1331252423498; Thu, 08 Mar 2012 16:20:23 -0800 (PST) Received: by 10.60.4.10 with SMTP id g10mr83800oeg.18.1331252423405; Thu, 08 Mar 2012 16:20:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.5.67 with HTTP; Thu, 8 Mar 2012 16:20:03 -0800 (PST) In-Reply-To: <20120308173712.GT22535@angus.ind.WPI.EDU> References: <51865E1A72F61D48A247348DCCBA5CFB05B9154C@XMB-AMS-105.cisco.com> <20120308173038.GI84425@Space.Net> <20120308173712.GT22535@angus.ind.WPI.EDU> From: Lorenzo Colitti Date: Fri, 9 Mar 2012 09:20:03 +0900 Message-ID: To: Chuck Anderson Content-Type: multipart/alternative; boundary=e89a8ff252dacdb19104bac45b7f X-System-Of-Record: true X-Gm-Message-State: ALoCoQlpQ7eFm1IwL91Ht7l19TbYl/oy/358Q1IqgSHLHD01J1WgmRqKMJSWbW5/jElzzmGbsnVSG3mtv1Rem95hImO+brlpcGfds21lECYotH4VwJffkUypwCvMOJAgiPZUgQgZddif Cc: v6ops@ietf.org Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 00:20:31 -0000 --e89a8ff252dacdb19104bac45b7f Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 9, 2012 at 02:37, Chuck Anderson wrote: > Perhaps the draft could be reworked to be a comparison and overview of > both techniques, LLA and global addressing, and their pros/cons > without having a position/recommendation/BCP for either method. +1. For me, what makes this attractive is the operational simplicity. If you don't number links, you can never make a mistake numbering them, you never have to configure them, etc. All you need to do is enable IPv6 packet processing on all interfaces and that's it. This is much simpler than IPv4, where you can end up blackholing traffic if you don't assign all your interfaces IP addresses. --e89a8ff252dacdb19104bac45b7f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 9, 2012 at 02:37, Chuck Anderson <cra@wpi.edu> wrote:
Perhaps the draft could be reworked to be a comparison an= d overview of
both techniques, LLA and global addressing, and their pros/cons
without having a position/recommendation/BCP for either method.

=A0+1.

For me, what makes thi= s attractive is the operational simplicity. If you don't number links, = you can never make a mistake numbering them, you never have to configure th= em, etc. All you need to do is enable IPv6 packet processing on all interfa= ces and that's it. This is much simpler than IPv4, where you can end up= blackholing traffic if you don't assign all your interfaces IP address= es.
--e89a8ff252dacdb19104bac45b7f-- From randy@psg.com Fri Mar 9 02:17:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1BC21F8637 for ; Fri, 9 Mar 2012 02:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 8UNmUPq1SY59 for ; Fri, 9 Mar 2012 02:17:50 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id C349C21F85FC for ; Fri, 9 Mar 2012 02:17:49 -0800 (PST) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S5wtN-0003tn-UD; Fri, 09 Mar 2012 10:17:46 +0000 Date: Fri, 09 Mar 2012 19:17:44 +0900 Message-ID: From: Randy Bush To: "Rajiv Asati (rajiva)" In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C0795D56A@XMB-RCD-111.cisco.com> References: <51865E1A72F61D48A247348DCCBA5CFB05B9154C@XMB-AMS-105.cisco.com> <20120308173038.GI84425@Space.Net> <20120308173712.GT22535@angus.ind.WPI.EDU> <20120308175526.GK84425@Space.Net> <4F59090D.8000901@gmail.com> <067E6CE33034954AAC05C9EC85E2577C0795D56A@XMB-RCD-111.cisco.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: v6ops@ietf.org Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 10:17:50 -0000 > But why would we not want it to be a BCP? because the B stands for Best, not Bad. we kinda like traceroute, ping, and other diagnostic tools to be useful. debug is horrible enough and primitive as it goes today. do not recommend screwing up what tools we have. randy From ichiroumakino@gmail.com Fri Mar 9 03:50:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC9F21F85F1 for ; Fri, 9 Mar 2012 03:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.273 X-Spam-Level: X-Spam-Status: No, score=-3.273 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 0mP3Vb47yxEz for ; Fri, 9 Mar 2012 03:50:42 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5A68021F8621 for ; Fri, 9 Mar 2012 03:50:42 -0800 (PST) Received: by wibhj6 with SMTP id hj6so297150wib.13 for ; Fri, 09 Mar 2012 03:50:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=5CEmfqXUkGDdqLp883/pu0pJevj/2rrZtzCSZ3m6JGs=; b=lm+ZdrA3mdT3fsSnqhQYUIPTCXlg1Td+rfIrV9HAkFiASpR0LxBuPx7WNUqL7ytlIW 0tpXEXlb0HvmmC1aEd9Eu9aMQFz2MDPQ03LZvEN9WBOF7lqQtz54hwCQwvgeP9taxEur 7Q3z3meydwfQELXAhTAFDCjg9NQZZtVirodsF0DKNWE2sV4c3JWp25aft+ONJoUZ37gL V94ZighwKv6TTi61Gr9BqxkZ1ymtrIFsbJXKR4QclCQ61YWkIxP6dgfhHIES/P1xGnZb pOTJaSj09Lkh9zgKwFspj/NXdXnQyo+vDdo6AQIIKPq5QL3ydO+nb/Ulm0dQbAY+xGnR YHEg== Received: by 10.180.97.41 with SMTP id dx9mr4050804wib.9.1331293841265; Fri, 09 Mar 2012 03:50:41 -0800 (PST) Received: from [10.147.13.118] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id fw5sm4561086wib.0.2012.03.09.03.50.39 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 09 Mar 2012 03:50:40 -0800 (PST) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> Date: Fri, 9 Mar 2012 12:50:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9B1C4EC1-50ED-436F-876A-1F2512BB54C9@employees.org> References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> To: "v6ops@ietf.org WG" X-Mailer: Apple Mail (2.1257) Cc: "v6ops-chairs@tools.ietf.org Chairs" , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 11:50:45 -0000 > This is to initiate a two week working group last call of = draft-ietf-v6ops-6204bis. Please read it now. If you find nits (spelling = errors, minor suggested wording changes, etc), comment to the authors; = if you find greater issues, such as disagreeing with a statement or = finding additional issues that need to be addressed, please post your = comments to the list. The draft will be on the agenda at IETF 83, and I = would like to send the authors home with a work plan to complete it if = it is not to the WG's liking. >=20 > We are looking specifically for comments on the importance of the = document as well as its content. If you have read the document and = believe it to be of operational utility, that is also an important = comment to make. I've done a review of the bis document against RFC6204. please find my = comments below. Major: =3D=3D=3D=3D=3D=3D 1. The DHCP "problem". UNH testing uncovered quite a few issues with the 3315/3633 protocol = specifications with regards to support for both IA_NA and IA_PD. these issues are debated = in DHC and there will be a DHC bar/DT meeting to see if those issues can be resolved and how. = 6204bis depends on the outcome of this and shouldn't proceed before we know what requirements to make on DHCP. This is a problem we need to solve, and I don't think we can be = silent on it. (e.g. bis has removed 6204, W-5. this also affects WPD-6.) Suggestion: Await resolution in DHC and adopt requirements = accordingly. 2. PCP text is incomplete. As specified PCP support in the document is = incomplete. If this has been added for DS-lite support draft-dupont-pcp-dslite-01 should be referenced. Currently the requirement is not testable. E.g. it doesn't even specify which PCP server the client should use. In my opinion it also need to specify PCP/proxy LAN side behavior. (or reference a homenet document if one existed) Suggestion: Get thorough review in PCP and HOMENET. Incorporate LAN = side requirements. 3. Section 4.4.1: transition mechanisms for IPv6. in introducing 6rd,=20 a CE might end up being multi-homed. that opens up a can of worms that the draft is silent on. either include the = requirements from draft-townsley-troan-ipv6-ce-transitioning-02 incorporated or specify = that native an 6rd are mutually exclusive. Suggestion: Incorporate requirements from above draft. 4. life-extension mechanisms for IPv4. firstly I don't think this = mechanism belongs in this document, which=20 is all about delivering IPv6 service, while DS-lite is all about = delivering IPv4 service. in addition to creating the same multi-homing issue (now for IPv4) = above, it also has missing pieces. e.g. assigning full global addresses, something that is being worked = on in softwire. fourthly (have I got that far) there are a number of proposals in softwires for = complementary / competing mechanisms for IPv4 life extensions. NAT464, MAP-{T,E}, 4rd-U. there is also SD-NAT = which achieves the same, but doesn't use IPv6 transport at all. I would prefer that none of these was in = _this_ document, but that we had a separate document for "Life extensions for IPv4 CEs" Minor: =3D=3D=3D=3D=3D=3D 1. Section 3.2.1: Why is this section removed? A dual-stack host is multihomed to IPv4 and IPv6 networks. The IPv4 = and IPv6 topologies may not be congruent, and different addresses may have different = reachability, e.g., ULAs. A host stack has to be able to quickly fail over and try a different = source address and destination address pair if communication fails, as outlined in [HAPPY-EYEBALLS]. Suggestion: Add back the missing paragraph. 2. W-3. Question: is there a need for "Router Discovery" to continue = forever? Compared to todays behavior where it times out after 3 attempts? 3. WAA-4. Has added support for the DNS Search List option. The CPE acts as a demarcation point between two administrative = domains. It will pass some information learnt from the WAN side DHCP client to = its LAN side DHCP server. I think it is a particularly bad idea to let the = ISP set the DNS search lists for hosts within my home. Why is this option added and what is the use case? Suggestion: Remove requirement for DNSSL 4. RFC6204 WAA-7 has been removed. Is that a good idea? I think this point is important to make it clear that RA and DHCP = processing can be done independently of each other. Suggestion: Add requirement back. 5. New WAA-7. I think the added "unless configured to require a global = IPv6 address on the WAN interface.", dilutes the purpose of that = requirement. The RFC6204 profile is meant to result in a router that can be = plugged into any access network. Even though certain access networks will not operate = the unnumbered addressing model, how are we going to ensure that no user moves this = CPE to another access network, that requires it? How is this additional "unless configured" testable? This same comment applies to WPD-6. Suggestion: Remove addition text on WPD-6 and WAA-7. 6. WPD-1. Generally we have tried to avoid having multiple 2119 keywords = in one requirement. Make PD-exclude a separate requirement. Suggestion: Split requirement in two. 7. WPD-4. I disagree with this requirement. It is also hard to test, and = becomes meaningless, given that a CPE must do PD even if M=3D0, O=3D0. Suggestion: revert back to RFC6204:WPD-4= From gvandeve@cisco.com Fri Mar 9 05:23:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E19921F864B for ; Fri, 9 Mar 2012 05:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.224 X-Spam-Level: X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 gFINMADSgCEI for ; Fri, 9 Mar 2012 05:23:04 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id C8D4F21F85D2 for ; Fri, 9 Mar 2012 05:23:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=1182; q=dns/txt; s=iport; t=1331299383; x=1332508983; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=H5QKH/BbiVvmbLFvN55tI+TvrXblruWnX9TJj53bORw=; b=ZweS6lGIwk0pURDlrl6+KA6my8m7yJIIPiMBoraxLb4kKquxIlRPDHBV eb7anXjsfcTKcTfsd8fZbjdxI13Qh7bK55Dr2hrVrEyVlxDGr6jEFmOZh tjHwQWg0029BkkjX1ClAa8JFeTkFhsQ1JxGtuhDuDIatxxozGS/TJELhD E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAD4DWk+Q/khR/2dsb2JhbABEtTGBB4IKAQEBAwEBAQEPAR0KNAsFBwQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBqHYwULm2oBnn0Ej3djBKVlgmQ X-IronPort-AV: E=Sophos;i="4.73,558,1325462400"; d="scan'208";a="131829389" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 09 Mar 2012 13:23:02 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q29DN25a013304; Fri, 9 Mar 2012 13:23:02 GMT Received: from xmb-ams-102.cisco.com ([144.254.74.77]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 14:23:03 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Mar 2012 14:23:01 +0100 Message-ID: <5C99EC8C99D9BB45AC51D20DC2AD2DC507141EF9@XMB-AMS-102.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] New Draft: Using Only Link-Local Address in Network Core Thread-Index: Acz93emmrSwS6YxJRo6j0fnleeIuiAAEkwUw References: <51865E1A72F61D48A247348DCCBA5CFB05B9154C@XMB-AMS-105.cisco.com><20120308173038.GI84425@Space.Net><20120308173712.GT22535@angus.ind.WPI.EDU><20120308175526.GK84425@Space.Net> <4F59090D.8000901@gmail.com><067E6CE33034954AAC05C9EC85E2577C0795D56A@XMB-RCD-111.cisco.com> From: "Gunter Van de Velde (gvandeve)" To: "Randy Bush" , "Rajiv Asati (rajiva)" X-OriginalArrivalTime: 09 Mar 2012 13:23:03.0195 (UTC) FILETIME=[C17E96B0:01CCFDF7] Cc: v6ops@ietf.org Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 13:23:04 -0000 I agree with Randy from a diagnostic perspective, however it does not mean that LL-only is a bad philosophy from a security perspective.=20 traceroute info can be fixed with passive IPv6 addresses, without adding an additional attack vector above LL-only. Ping in that case could result in people removing the passive out of 'ipv6 address 2001:db8::1/64 passive" cli on that interface. There is no need to implement new protocols at all at any side of the equation. G/ -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Randy Bush Sent: vrijdag 9 maart 2012 11:18 To: Rajiv Asati (rajiva) Cc: v6ops@ietf.org Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core > But why would we not want it to be a BCP? =20 because the B stands for Best, not Bad. we kinda like traceroute, ping, and other diagnostic tools to be useful. debug is horrible enough and primitive as it goes today. do not recommend screwing up what tools we have. randy _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From victor.kuarsingh@gmail.com Fri Mar 9 06:55:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E39E721F8658 for ; Fri, 9 Mar 2012 06:55:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.84 X-Spam-Level: X-Spam-Status: No, score=-1.84 tagged_above=-999 required=5 tests=[AWL=-1.159, BAYES_00=-2.599, MANGLED_PREMTR=2.3, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 X5Rmobx-fqft for ; Fri, 9 Mar 2012 06:55:21 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D9FF621F84CD for ; Fri, 9 Mar 2012 06:55:20 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so1668630vcb.31 for ; Fri, 09 Mar 2012 06:55:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :in-reply-to:mime-version:content-type:content-transfer-encoding; bh=BEwQi5+yCTWe3F1gwjj3Md0ew68dEsPLJQdyy0vJxQI=; b=G3YAk9/2vXaQNHKxGME9nGC1w1Rfe08z8bpT6hK6DJtwVLdaBSzioVRryRxV6jN8UB 6dEToVwvFEQ6EDy1YWpUqQqi7cnUfNyIxLl3hSEd6E0iaT+Oi46ISi37RoJnfqFEH2Oc sSfqW/eFSFP3guA3FyKEapUhtoqvxt3vFS+AhV0atg649twuCr2ldaipQW+BwGT1AcnB H5QZjRhylwuJ+WF1MFLXGDdX7ui+4xhhNbgSeZFS2LYo9DcIQId44C8rsRtlLZ9sSbjs YrnETlGmbpEx79Lz+mPoN2D2e5cNBjBfgXTjTMR9AeYQHWffRO1teOOQsmqS1/WwZo3p wcRw== Received: by 10.52.93.76 with SMTP id cs12mr3970286vdb.58.1331304920397; Fri, 09 Mar 2012 06:55:20 -0800 (PST) Received: from [25.31.193.101] ([74.198.87.101]) by mx.google.com with ESMTPS id ew2sm11014305vdc.16.2012.03.09.06.55.17 (version=SSLv3 cipher=OTHER); Fri, 09 Mar 2012 06:55:19 -0800 (PST) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Fri, 09 Mar 2012 09:55:10 -0500 From: Victor Kuarsingh To: Randy Bush , "Rajiv Asati (rajiva)" Message-ID: Thread-Topic: [v6ops] New Draft: Using Only Link-Local Address in Network Core In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 14:55:22 -0000 On 12-03-09 5:17 AM, "Randy Bush" wrote: >> But why would we not want it to be a BCP? > >because the B stands for Best, not Bad. we kinda like traceroute, ping, >and other diagnostic tools to be useful. debug is horrible enough and >primitive as it goes today. do not recommend screwing up what tools we >have. I will tend to agree (partially) with Randy here. I think a BCP would note that we are recommending a certain type of deployment or mode of operation. Whereas I don't disagree that LL-only is a useful model in some circumstances, I don't think we can say it applies uniformly to all networks and network conditions. Therefore making it a BCP may be a bit pre-mature. Regards, Victor K > >randy >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From despres.remi@laposte.net Fri Mar 9 07:33:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86D021F86C6 for ; Fri, 9 Mar 2012 07:33:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[AWL=-0.221, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] 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 zEt0FRqZfKFS for ; Fri, 9 Mar 2012 07:33:18 -0800 (PST) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id BA84C21F86A0 for ; Fri, 9 Mar 2012 07:33:10 -0800 (PST) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8502-out with ME id jTZ81i00237Y3f403TZ8fk; Fri, 09 Mar 2012 16:33:08 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Fri, 9 Mar 2012 16:30:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <11ECC355-6FAC-4D69-A615-AB43F2180CEE@laposte.net> References: To: GangChen X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-chen-v6ops-nat64-experience-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 15:33:18 -0000 Gang,=20 1. This kind of draft is IMHO useful because it discusses the global = picture. Maybe calling it NAT64 operational "issues" or "scenarios", would better = describe its contents than just "experiences" which, IMHO suggests a = report on already observed behaviors. 2. One point of substance: sec. 3.6 says "One approach avoiding this issue = is to configure IPv4 MTU>=3D1260, which would forbid the occurence of = PTB<1280". It should be possible for the IPv6 Internet to IPv4 network = scenario of sec. 3, but not for the IPv6 network to IPv4 Internet = scenario of sec 2. This should IMHO be clarified. =20 3.=20 Couldn' understand this sentence of sec. 1: "Since the scenario of "The IPv6 Internet to the IPv4 Internet" seems = the ideal case for in-network translation technology, this document has = focused on the three cases and categorized different NAT64 usages as = NAT64-CGN and NAT64-CE." 4. Minor noted typos: - 3.3 "might a good choice" =3D> "might be a good choice" - 3.1 "is to distributed" =3D> "is to distribute" - 3.5=20 " a synthetic AAAA records" =3D> "a synthetic AAAA record" - 3.6=20 "occurence" =3D> "occurrence" 5. For a further version, I would suggest to include more referenced = documents (in particular about Lawful traceability, IAP, ALGs other than = FTP, SYN Proxy-cookie).=20 Regards, RD Le 2012-02-14 =E0 05:11, GangChen a =E9crit : > Hello all, >=20 > We have published draft-chen-v6ops-nat64-experience-00, which > described NAT64 operational expriences and updated with all the > information from the presentation of draft-chen-v6ops-nat64-cpe at > last meeting. Considering the new changes, authors would like to > retire the old draft (i.e. draft-chen-v6ops-nat64-cpe) and continue > the discussion on nat64 experiences. >=20 > All comments are welcome. >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 > Title : NAT64 Operational Experiences > Author(s) : Gang Chen > Zhen Cao > Cameron Byrne > QiBo Niu > Filename : draft-chen-v6ops-nat64-experience-00.txt > Pages : 11 > Date : 2012-02-13 >=20 > This document summarizes some stateful NAT64 deployment scenarios and > operational experiences for NAT64-CGN and NAT64-CE. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-experience-00.t= xt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-chen-v6ops-nat64-experience-00.tx= t > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From mohacsi@niif.hu Fri Mar 9 08:11:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF5B021F869F for ; Fri, 9 Mar 2012 08:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.346 X-Spam-Level: * X-Spam-Status: No, score=1.346 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, MANGLED_PREMTR=2.3] 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 aE0SvoLZrek7 for ; Fri, 9 Mar 2012 08:11:41 -0800 (PST) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by ietfa.amsl.com (Postfix) with ESMTP id 3B3A821F8694 for ; Fri, 9 Mar 2012 08:11:41 -0800 (PST) Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by mail.ki.iif.hu (Postfix) with ESMTP id 5F0B487A75; Fri, 9 Mar 2012 17:11:39 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id yVw+abjgkCSC; Fri, 9 Mar 2012 17:11:33 +0100 (CET) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id 735F587A74; Fri, 9 Mar 2012 17:11:33 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 6E36F87A4F; Fri, 9 Mar 2012 17:11:33 +0100 (CET) Date: Fri, 9 Mar 2012 17:11:33 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: Victor Kuarsingh In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 16:11:42 -0000 On Fri, 9 Mar 2012, Victor Kuarsingh wrote: > On 12-03-09 5:17 AM, "Randy Bush" wrote: > >>> But why would we not want it to be a BCP? >> >> because the B stands for Best, not Bad. we kinda like traceroute, ping, >> and other diagnostic tools to be useful. debug is horrible enough and >> primitive as it goes today. do not recommend screwing up what tools we >> have. > > I will tend to agree (partially) with Randy here. I think a BCP would > note that we are recommending a certain type of deployment or mode of > operation. > > Whereas I don't disagree that LL-only is a useful model in some > circumstances, I don't think we can say it applies uniformly to all > networks and network conditions. Therefore making it a BCP may be a bit > pre-mature. I prefer informational draft - describing advantages and disadvantages. Regards, Janos Mohacsi From shemant@cisco.com Fri Mar 9 08:47:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1612F21F8734 for ; Fri, 9 Mar 2012 08:47:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.97 X-Spam-Level: X-Spam-Status: No, score=-8.97 tagged_above=-999 required=5 tests=[AWL=0.728, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, 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 hcnBSSv1UbwF for ; Fri, 9 Mar 2012 08:47:04 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8A81421F8733 for ; Fri, 9 Mar 2012 08:47:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=27239; q=dns/txt; s=iport; t=1331311624; x=1332521224; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=J8OlGHfpAJz5i0AWSt7vsMjleiP8M1vuNiSjmpQiU5w=; b=WKVAkN05RLR1Ba2lsA3FtpOnpx5GxwSs49ApjMhD0hnE4M8y3jifb0vV QAmktAqraLw3WQrVb4NxwXo8jAocdF4dGy9/e5Ot/4TpJHebFMOQmQgzu QHZeO3eSgtzUEN7iiNN7/5xvNWKD7Il3/mFMQkL9EJMqhNiIrK6fFB06K Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFANczWk+tJV2Y/2dsb2JhbABCtT+BB4IKAQEBAwESAQkRAzsOBQcEAgEIEAEEAQELBhAHAQYBRQkIAQEEARIIEQIHh2MFoAgBlx+Pd2MEiCAznRKDAoE9 X-IronPort-AV: E=Sophos;i="4.73,559,1325462400"; d="scan'208,217";a="65161518" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 09 Mar 2012 16:46:52 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q29Gkql1002360; Fri, 9 Mar 2012 16:46:52 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 10:46:52 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCFE14.3A90D878" Date: Fri, 9 Mar 2012 10:46:51 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDCEE@XMB-RCD-109.cisco.com> In-Reply-To: <9B1C4EC1-50ED-436F-876A-1F2512BB54C9@employees.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6204bis WGLC Thread-Index: Acz96uXRwjprUWYLSC2XqBbkihlfsgAIq2Tg References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> <9B1C4EC1-50ED-436F-876A-1F2512BB54C9@employees.org> From: "Hemant Singh (shemant)" To: =?iso-8859-1?Q?Ole_Tr=F8an?= , X-OriginalArrivalTime: 09 Mar 2012 16:46:52.0399 (UTC) FILETIME=[3AAB07F0:01CCFE14] Cc: v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 16:47:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFE14.3A90D878 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ole, General comment. Some folks would have liked to LastCall rfc6204bis = during December 2011. Rfc6204bis now seems to be in a mode such as the = mode the ipv6 node-requirement document was in. The ipv6 = node-requirement document will always miss something that someone wants = but the document is not held back after a certain set of requirements = are in. Most issues raised below have been beaten to death and we still = have no resolution on the issues. It's up to the WG to decide how long = should rfc6204bis wait and punt to rfc6204ter? See in line below. I will reply on the PCP and draft-dupont in another email so that the = comments do not get cluttered in this CE router discussion. -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Ole Tr=F8an Sent: Friday, March 09, 2012 6:51 AM To: v6ops@ietf.org WG Cc: v6ops-chairs@tools.ietf.org Chairs; Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC >Major: >=3D=3D=3D=3D=3D=3D >1. The DHCP "problem". > UNH testing uncovered quite a few issues with the 3315/3633 protocol = specifications with > regards to support for both IA_NA and IA_PD. these issues are = debated in DHC and there will be a DHC > bar/DT meeting to see if those issues can be resolved and how. = 6204bis depends on the outcome of this and > shouldn't proceed before we know what requirements to make on DHCP. > This is a problem we need to solve, and I don't think we can be = silent on it. > (e.g. bis has removed 6204, W-5. this also affects WPD-6.) > Suggestion: Await resolution in DHC and adopt requirements = accordingly. Waited for three months now having contacted the DHC WG with the issues. = Actually it's more than three months because the issues were known to = some DHC experts who are also on the cpe router design team. There is = still no resolution. Why wait? A rfc6204ter can cover the DHC = solutions when the solutions become available. Alternatively, when = rfc6204bis is in the IESG, if DHC has any resolution, one could = incorporate the changes. >3. Section 4.4.1: transition mechanisms for IPv6. in introducing 6rd,=20 > a CE might end up being multi-homed. that opens up > a can of worms that the draft is silent on. either include the = requirements from > draft-townsley-troan-ipv6-ce-transitioning-02 incorporated or = specify that native an 6rd are mutually > exclusive. > Suggestion: Incorporate requirements from above draft. The document above will take time to gestate in the IETF. Unless the = document above is an RFC and some working implementations have shown the = algorithms of the document working, rfc6204bis cannot do anything about = this work. I would continue rfc6204bis without this work. >4. life-extension mechanisms for IPv4. firstly I don't think this = mechanism belongs in this document, which=20 > is all about delivering IPv6 service, while DS-lite is all about = delivering IPv4 service. > in addition to creating the same multi-homing issue (now for IPv4) = above, it also has missing pieces. > e.g. assigning full global addresses, something that is being worked = on in softwire. fourthly (have I got > that far) there are a number of proposals in softwires for = complementary / competing mechanisms for > IPv4 life extensions. NAT464, MAP-{T,E}, 4rd-U. there is also SD-NAT = which achieves the same, but doesn't > use IPv6 transport at all. I would prefer that none of these was in = _this_ document, but that we had a separate > document for "Life extensions for IPv4 CEs" We are going down the rathole again trying to label DS-Lite as IPv4 tech = but it's beaten to death the issue is debatable. Life extensions is = very IPv4 specific. The kitchen sink of other new transition tech have = to all reach RFC form before any CPE router document can consider them. = Move this work to rfc6204ter. We can have a Webex meeting to discuss the minor issues raised and then = publish the closure to v6ops for further comments. Hemant ------_=_NextPart_001_01CCFE14.3A90D878 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [v6ops] draft-ietf-v6ops-6204bis WGLC

Ole,

General comment.  Some folks would have liked to LastCall = rfc6204bis during December = 2011.  = Rfc6204bis now seems to be in a = mode such as the mode the = ipv6 node-requirement = document was in.  The ipv6 = node-requirement document will always miss something that someone wants = but the document is not held back after a certain set of = requirements are in.  Most issues raised below have been beaten to = death and we still have no resolution on the = issues.  It's up to the WG to decide how long should = rfc6204bis wait and punt to rfc6204ter?  See in line below.

I = will reply on the PCP and draft-dupont in another email so that the = comments do not get cluttered in this CE router = discussion.

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]= On Behalf Of Ole Tr=F8an
Sent: Friday, March 09, 2012 6:51 AM
To: v6ops@ietf.org WG
Cc: v6ops-chairs@tools.ietf.org Chairs; Ron Bonica
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC

>Major:

>=3D=3D=3D=3D=3D=3D

>1. The DHCP "problem".

>   UNH testing uncovered quite a few = issues with the 3315/3633 protocol specifications with

>   regards to support for both IA_NA and = IA_PD. these issues are debated in DHC and there will be a = DHC

>   bar/DT meeting to see if those issues = can be resolved and how. 6204bis depends on the outcome of this = and

>   shouldn't proceed before we know what = requirements to make on DHCP.

>   This is a problem we need to solve, = and I don't think we can be silent on it.

>   (e.g. bis has removed 6204, W-5. this = also affects WPD-6.)

>   Suggestion: Await resolution in DHC = and adopt requirements accordingly.

Waited for three months now having = contacted = the DHC WG with the issues.  Actually it's = more than three months because = the issues were known = to some DHC experts = who are = also on the cpe router design team.  There is = still no resolution.   Why wait? A = rfc6204ter can cover the DHC solutions when the solutions become = available.  Alternatively, when rfc6204bis is in the IESG, if DHC has any resolution, = one could incorporate the changes.

>3. Section 4.4.1: transition mechanisms for IPv6. = in introducing 6rd,

>   a CE might end up being multi-homed. = that opens up

>   a can of worms that the draft is = silent on. either include the requirements from

>   = draft-townsley-troan-ipv6-ce-transitioning-02 incorporated or specify = that native an 6rd are mutually

>   exclusive.

>   Suggestion: Incorporate requirements = from above draft.

The document above will take time to gestate in the IETF.  = Unless the document above is an RFC and some = working implementations have shown the = algorithms of the document working, = rfc6204bis cannot do anything about this work.  I would continue = rfc6204bis without this work.

>4. life-extension mechanisms for IPv4. firstly I = don't think this mechanism belongs in this document, which =

>   is all about delivering IPv6 service, = while DS-lite is all about delivering IPv4 service.

>   in addition to creating the same = multi-homing issue (now for IPv4) above, it also has missing = pieces.

>   e.g. assigning full global addresses, = something that is being worked on in softwire. fourthly (have I = got

>   that far) there are a number of = proposals in softwires for complementary / competing mechanisms = for

>   IPv4 life extensions. NAT464, = MAP-{T,E}, 4rd-U. there is also SD-NAT which achieves the same, but = doesn't

>   use IPv6 transport at all. I would = prefer that none of these was in _this_ document, but that we had a = separate

>   document for "Life extensions for = IPv4 CEs"

We are going down the rathole again trying = to label DS-Lite as IPv4 tech but it's beaten to = death the issue is = debatable.  Life extensions is very IPv4 specific.  The = kitchen sink of other new transition tech have to all reach RFC form = before any CPE router document can consider them.  Move this work to = rfc6204ter.

We can have a Webex meeting to discuss the minor = issues raised and then publish the closure to v6ops for further comments.

Hemant

------_=_NextPart_001_01CCFE14.3A90D878-- From shemant@cisco.com Fri Mar 9 09:57:51 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2450921E8063 for ; Fri, 9 Mar 2012 09:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.013 X-Spam-Level: X-Spam-Status: No, score=-9.013 tagged_above=-999 required=5 tests=[AWL=0.685, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, 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 oksxFSaWE6nE for ; Fri, 9 Mar 2012 09:57:50 -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 3B83821E8027 for ; Fri, 9 Mar 2012 09:57:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=11611; q=dns/txt; s=iport; t=1331315870; x=1332525470; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=jKLmWq7+7CSSc/s50/uNUxl7Bt/TD5okj0/nWX1mshE=; b=TX8GHw6SiNyVyiYV8dlyArhm5VOnvC8bklujQKm0lS3VsHk3vBhLubHs Gqkj3U4s5BGyitu6Eq8LDbMd5KitSVOBgN96Ofrr0gn72SM072BjJHQ4H oE1+tuIHMJAw1Fnq/xpv++W75XpUhZ2GseXBdip1dc7LpKjrh+XGs6Kwt I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAA1EWk+tJXG//2dsb2JhbABDtTKBB4IKAQEBAwESAQkRA0kFBwQCAQgQAQQBAQsGFwEGAUUJCAEBBAESCBqHYwWcFQGfA493YwSIIDOdEoMC X-IronPort-AV: E=Sophos;i="4.73,559,1325462400"; d="scan'208,217";a="65195421" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-4.cisco.com with ESMTP; 09 Mar 2012 17:57:49 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q29Hvnfc022458; Fri, 9 Mar 2012 17:57:49 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 11:57:49 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCFE1E.24087078" Date: Fri, 9 Mar 2012 11:57:48 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDD4E@XMB-RCD-109.cisco.com> In-Reply-To: <9B1C4EC1-50ED-436F-876A-1F2512BB54C9@employees.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6204bis WGLC Thread-Index: Acz96uXRwjprUWYLSC2XqBbkihlfsgAMXbaA References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> <9B1C4EC1-50ED-436F-876A-1F2512BB54C9@employees.org> From: "Hemant Singh (shemant)" To: =?iso-8859-1?Q?Ole_Tr=F8an?= , X-OriginalArrivalTime: 09 Mar 2012 17:57:49.0667 (UTC) FILETIME=[24329330:01CCFE1E] Cc: v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 17:57:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFE1E.24087078 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ole, authors of pcp-dslite, any SP testing PCP with DS-Lite, and v6ops, Please see below. -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Ole Tr=F8an Sent: Friday, March 09, 2012 6:51 AM To: v6ops@ietf.org WG Cc: v6ops-chairs@tools.ietf.org Chairs; Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC >Major: >=3D=3D=3D=3D=3D=3D >2. PCP text is incomplete. As specified PCP support in the document is = incomplete. > If this has been added for DS-lite support = draft-dupont-pcp-dslite-01 > should be referenced. Currently the requirement is not testable. = E.g. > it doesn't even specify which PCP server the client should use. > In my opinion it also need to specify PCP/proxy LAN side behavior. > (or reference a homenet document if one existed) > Suggestion: Get thorough review in PCP and HOMENET. Incorporate LAN = side requirements. Provision manually or use a new DHCPv6 option. SPs who are testing PCP = can respond as well. These minor issues should not block adding a PCP = client to the rfc6204bis document. Further draft-dupont-pcp-dslite-01 = is not in RFC form nor in the IESG. Additionally the pcp-dslite = document needs a peer review. What is the Appendix A in pcp-dslite = talking about including mention of a "tag"? Why is the tag needed when = pcp-base already supports the necessary protocol? Here is how. The basic PCP header includes the source IP address of the PCP client = issuing the PCP request. Thus even though the IPv4 PCP request reaches = the CGN in an IPv6 tunnel, the CGN decapsulates the tunneled packet and = passes the packet to the IPv4 stack on the CGN. The IPv4 stack passes = the PCP Request to the PCP server. Snipped from section 6.1 of pcp-base = it this text. [IPv4 is represented using an IPv4-mapped IPv6 address.] Thus the PCP server is able to reply back to the PCP client in an IPv6 = tunneled PCP response back. I question why pcp-dslite document is needed if pcp-base already covers = the technical details. Hemant ------_=_NextPart_001_01CCFE1E.24087078 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [v6ops] draft-ietf-v6ops-6204bis WGLC

Ole, authors of = pcp-dslite, any SP testing PCP with DS-Lite, = and v6ops,

Please see = below.

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]= On Behalf Of Ole Tr=F8an
Sent: Friday, March 09, 2012 6:51 AM
To: v6ops@ietf.org WG
Cc: v6ops-chairs@tools.ietf.org Chairs; Ron Bonica
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC

>Major:

>=3D=3D=3D=3D=3D=3D

>2. PCP text is incomplete. As = specified PCP support in the document is incomplete.

>   If this has been = added for DS-lite support draft-dupont-pcp-dslite-01

>   should be = referenced. Currently the requirement is not testable. = E.g.

>   it doesn't even = specify which PCP server the client should use.

>   In my opinion it = also need to specify PCP/proxy LAN side behavior.

>   (or reference a = homenet document if one existed)

>   Suggestion: Get = thorough review in PCP and HOMENET. Incorporate LAN side = requirements.

Provision manually or use a new = DHCPv6 option.  SPs = who are = testing PCP can respond as well.  These minor issues should not block adding = a PCP client to the rfc6204bis document.  Further = draft-dupont-pcp-dslite-01 is not in RFC form nor in the = IESG.  Additionally the = pcp-dslite document needs = a peer review.  What is the Appendix A in pcp-dslite = talking about including mention of a "tag"?  = Why is the tag needed = when = pcp-base already supports = the necessary = protocol?  Here is how.

The basic PCP header includes the = source IP address of the PCP client issuing the PCP request.  Thus = even though the IPv4 PCP request reaches the CGN in an IPv6 tunnel, the = CGN decapsulates the tunneled packet and passes the packet to the IPv4 = stack on the CGN.  The IPv4 stack passes the PCP Request to the PCP = server.  Snipped from section 6.1 of pcp-base it this = text.

[IPv4 is represented using an = IPv4-mapped IPv6 address.]

Thus the PCP server is able to = reply back to the PCP client in an IPv6 tunneled PCP response = back.

I question why pcp-dslite document is needed if = pcp-base already covers the technical details.

Hemant

------_=_NextPart_001_01CCFE1E.24087078-- From dr@cluenet.de Fri Mar 9 13:41:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDDD21F85EE for ; Fri, 9 Mar 2012 13:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, 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 7rUUm74hJDSz for ; Fri, 9 Mar 2012 13:41:40 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id C501921F85EA for ; Fri, 9 Mar 2012 13:41:40 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id 4B23F10808A; Fri, 9 Mar 2012 22:41:38 +0100 (CET) Date: Fri, 9 Mar 2012 22:41:38 +0100 From: Daniel Roesen To: v6ops@ietf.org, v6ops-chairs@tools.ietf.org Message-ID: <20120309214138.GA1736@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org, v6ops-chairs@tools.ietf.org References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 21:41:41 -0000 Hi, WAA-4: I've seen vendors appending DHCPv6-received DNS servers to the list of already learned DNS servers and thus not actually using them unless the formerly learned DNS servers become unresponsive. My operator-hat expectation would be that the communicated list of DNS servers upon RENEW is the only set of DNS servers to be used in the future. Should we add further text making the (to an operator) obvious explicit to close that hole? WAA-5: I've seen vendors requesting SNTP servers but not using them. Passes RFC6204 by-the-letters verification, but certainly not the intention. Further text required to close such loopholes? Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From shemant@cisco.com Fri Mar 9 14:09:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9A221E8044 for ; Fri, 9 Mar 2012 14:09:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.501 X-Spam-Level: X-Spam-Status: No, score=-10.501 tagged_above=-999 required=5 tests=[AWL=2.097, BAYES_00=-2.599, GB_I_LETTER=-2, 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 TAB8gZfZFfQp for ; Fri, 9 Mar 2012 14:09:49 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC7D21E8025 for ; Fri, 9 Mar 2012 14:09:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=10193; q=dns/txt; s=iport; t=1331330989; x=1332540589; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=89UFXUp77gRuOyGSNLAvW65trNpZ/iswdmMejYMeEas=; b=jgKW5VbNT0c165yGITbNkvXaq1QbmYMIj5HQh5rC0iwEENuRNEySPLSe R9X73H4ALoJEyI4MUJkqWRAIYayKTpK0lCIJBoV6Kq0v3UDuZDuE8eKGD QemkmImtAX83TyVES97rL/pGc9Un2QHpn7E1zTFlJOg7gx1LupanqK2zd s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKd+Wk+tJXG+/2dsb2JhbABCtUCBB4IKAQEBBBIBCREDVQQCAQgOAwQBAQsGFwEGAUUJCAEBBAESCBqHaKAQAZcLkBVjBIhTnRKDAg X-IronPort-AV: E=Sophos;i="4.73,560,1325462400"; d="scan'208,217";a="65249951" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 09 Mar 2012 22:09:48 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q29M9mCp019221; Fri, 9 Mar 2012 22:09:48 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 16:09:48 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCFE41.57D84F60" Date: Fri, 9 Mar 2012 16:09:47 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDEA0@XMB-RCD-109.cisco.com> In-Reply-To: <20120309214138.GA1736@srv03.cluenet.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6204bis WGLC Thread-Index: Acz+PXBJk7Yl1uZoR8Cy1IUvGqaiTgAAnP+w References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> <20120309214138.GA1736@srv03.cluenet.de> From: "Hemant Singh (shemant)" To: "Daniel Roesen" , , X-OriginalArrivalTime: 09 Mar 2012 22:09:48.0985 (UTC) FILETIME=[58036A90:01CCFE41] Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 22:09:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFE41.57D84F60 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Daniel, -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Daniel Roesen Sent: Friday, March 09, 2012 4:42 PM To: v6ops@ietf.org; v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC >WAA-5: I've seen vendors requesting SNTP servers but not using them. >Passes RFC6204 by-the-letters verification, but certainly not the >intention. Further text required to close such loopholes? Does the following change work for you? Old ---- WAA-5: The IPv6 CE router SHOULD support the DHCPv6 Simple Network Time Protocol (SNTP) option [RFC4075] and the Information Refresh Time option [RFC4242]. New ---- WAA-5: The IPv6 CE router SHOULD support the Simple Network Time Protocol (SNTP) as specified in [RFC 2030]. If the CE router implements SNTP, then the CE router requests the SNTP option [RFC4075]=20 and the Information Refresh Time option [RFC4242] in DHCPv6 messages. I will get back to you on the other issue you raised related to WAA-4. Thanks much, Best regards back, Hemant ------_=_NextPart_001_01CCFE41.57D84F60 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: [v6ops] draft-ietf-v6ops-6204bis WGLC

Daniel,

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]= On Behalf Of Daniel Roesen
Sent: Friday, March 09, 2012 4:42 PM
To: v6ops@ietf.org; v6ops-chairs@tools.ietf.org
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC

>WAA-5: I've seen vendors requesting SNTP servers = but not using them.

>Passes RFC6204 by-the-letters verification, but = certainly not the

>intention. Further text required to close such = loopholes?

Does the following change work for you?

Old

----

WAA-5:  The IPv6 CE router SHOULD = support the DHCPv6 Simple Network

           Time = Protocol (SNTP) option [RFC4075] and the Information

           = Refresh Time option [RFC4242].

New

----

WAA-5:  The IPv6 CE router SHOULD = support the Simple Network

           Time = Protocol (SNTP) = as specified = in [RFC = 2030].  If the CE router

        = implements SNTP, then the CE router = requests the SNTP option [RFC4075] =

         = and the = Information = Refresh Time = option [RFC4242] in DHCPv6 messages.

I will get back to you on the other issue you = raised related to WAA-4.

Thanks much,

Best regards back,

Hemant

------_=_NextPart_001_01CCFE41.57D84F60-- From shemant@cisco.com Fri Mar 9 14:26:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6422A21F85F4 for ; Fri, 9 Mar 2012 14:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.611 X-Spam-Level: X-Spam-Status: No, score=-9.611 tagged_above=-999 required=5 tests=[AWL=0.987, 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 Gv5StKfFRwwK for ; Fri, 9 Mar 2012 14:26:33 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id A0CCE21F85FC for ; Fri, 9 Mar 2012 14:26:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=7951; q=dns/txt; s=iport; t=1331331989; x=1332541589; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=TsGVAnP9EtxLp4ITTw86XD1Xcwmv73XZJYJ2xYnz1n0=; b=FpBzaJi7S/6W2bifYzAGFr9Vz+rEwTaw6mFvwiot4u/EftSejayqJJXi TsWy0IOyefjfjIUIOSKo2ZwrmG8U1OD9EQCawyMq74UfSXb3TdFJwsroH 0s3UNCl5Gh6Rrhis9DJhYFM8qPltkRmC8vEdA5IiwsJj5bJW5Wotq8Ead c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAO2CWk+tJXG9/2dsb2JhbABDtTOBB4IKAQEBBBIBCREDSQwEAgEIDgMEAQELBhcBBgFFCQgBAQQBEggah2icCQGecpAVYwSIU50SgwKBPQ X-IronPort-AV: E=Sophos;i="4.73,560,1325462400"; d="scan'208,217";a="65250697" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-2.cisco.com with ESMTP; 09 Mar 2012 22:26:29 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q29MQTxo028822; Fri, 9 Mar 2012 22:26:29 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 16:26:29 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCFE43.ABCC0530" Date: Fri, 9 Mar 2012 16:26:27 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDEA9@XMB-RCD-109.cisco.com> In-Reply-To: <20120309214138.GA1736@srv03.cluenet.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6204bis WGLC Thread-Index: Acz+PXBJk7Yl1uZoR8Cy1IUvGqaiTgABGd9g References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> <20120309214138.GA1736@srv03.cluenet.de> From: "Hemant Singh (shemant)" To: "Daniel Roesen" , , X-OriginalArrivalTime: 09 Mar 2012 22:26:29.0134 (UTC) FILETIME=[AC260AE0:01CCFE43] Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 22:26:34 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFE43.ABCC0530 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Daniel, -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Daniel Roesen Sent: Friday, March 09, 2012 4:42 PM To: v6ops@ietf.org; v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC >WAA-4: I've seen vendors appending DHCPv6-received DNS servers to the list >of already learned DNS servers and thus not actually using them unless >the formerly learned DNS servers become unresponsive. My operator-hat >expectation would be that the communicated list of DNS servers upon >RENEW is the only set of DNS servers to be used in the future. >Should we add further text making the (to an operator) obvious explicit >to close that hole? I agree and also verified that RFC 3646 does not prohibit the new behavior you asked of above. After all, one use case is when the SP signals a DHCPv6 Reconfigure from the DHCPv6 server to the client to ask the client to Renew. On receiving the Reconfigure message, the client issues a RENEW. After all, the motive of the SP with the Reconfigure was to ask the client to obtain new information and a DNS server(s) list qualifies as new information. The client should purge any old information. Cced this email to Bernie (DHCPv6 guru) and Dan (DNS guru) for any comments.=20 If others agree, text in WAA-4 can be updated. Best regards, Hemant ------_=_NextPart_001_01CCFE43.ABCC0530 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: [v6ops] draft-ietf-v6ops-6204bis WGLC

Daniel,

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]= On Behalf Of Daniel Roesen
Sent: Friday, March 09, 2012 4:42 PM
To: v6ops@ietf.org; v6ops-chairs@tools.ietf.org
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC

>WAA-4: I've seen vendors = appending DHCPv6-received DNS servers to the list

>of already learned DNS servers = and thus not actually using them unless

>the formerly learned DNS = servers become unresponsive. My operator-hat

>expectation would be that the = communicated list of DNS servers upon

>RENEW is the only set of DNS = servers to be used in the future.

>Should we add further text = making the (to an operator) obvious explicit

>to close that = hole?

I agree and also verified that = RFC 3646 does not prohibit the new behavior you asked of above.  After all, one use case is = when the SP signals a DHCPv6 Reconfigure from the DHCPv6 server to the client = to ask the client to Renew.  On receiving the Reconfigure = message, the client = issues a RENEW.  After all, the motive of the SP with the = Reconfigure was to ask the = client to obtain new information and a DNS server(s) list = qualifies as new = information.  The = client should purge any old information.  Cced this email to Bernie = (DHCPv6 guru) and Dan (DNS guru) for any comments.

If others agree, text in WAA-4 can be = updated.

Best regards,

Hemant

------_=_NextPart_001_01CCFE43.ABCC0530-- From dr@cluenet.de Fri Mar 9 14:39:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDAE21E8088 for ; Fri, 9 Mar 2012 14:39:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, 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 w5l01M-pOSr8 for ; Fri, 9 Mar 2012 14:39:08 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id 130FB21E805F for ; Fri, 9 Mar 2012 14:38:55 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id C672A10808A; Fri, 9 Mar 2012 23:38:54 +0100 (CET) Date: Fri, 9 Mar 2012 23:38:54 +0100 From: Daniel Roesen To: v6ops@ietf.org, v6ops-chairs@tools.ietf.org Message-ID: <20120309223854.GA10517@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org, v6ops-chairs@tools.ietf.org References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> <20120309214138.GA1736@srv03.cluenet.de> <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDEA0@XMB-RCD-109.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDEA0@XMB-RCD-109.cisco.com> X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 22:39:09 -0000 Hi Hemant, On Fri, Mar 09, 2012 at 04:09:47PM -0600, Hemant Singh (shemant) wrote: > >WAA-5: I've seen vendors requesting SNTP servers but not using them. > >Passes RFC6204 by-the-letters verification, but certainly not the > >intention. Further text required to close such loopholes? > > Does the following change work for you? > > Old > ---- > > WAA-5: The IPv6 CE router SHOULD support the DHCPv6 Simple Network > Time Protocol (SNTP) option [RFC4075] and the Information > Refresh Time option [RFC4242]. > > > New > ---- > > WAA-5: The IPv6 CE router SHOULD support the Simple Network > Time Protocol (SNTP) as specified in [RFC 2030]. If the CE router > implements SNTP, then the CE router requests the SNTP option [RFC4075] > and the Information Refresh Time option [RFC4242] in DHCPv6 messages. Hm, I don't think that buys us anything. The implementation I had in mind actually does implement (S)NTP, but keeps using the configured set of NTP servers (pool.ntp.org servers by default). Your lingo still would allow that. Also, the proposed text probably unintentionally conditionalizes the IRT option request to wether the CE implements SNTP. Where the SNTP and IRT topics are actually totally orthogonal and should probably be splitted into two requirements. What about: WAA-5: The IPv6 CE router SHOULD implement the Simple Network Time Protocol (SNTP) as specified in [RFC 2030]. If the CE router implements SNTP, it requests the SNTP option [RFC4075] and uses the received list of servers as primary time reference, unless explicitly configured otherwise. WAA-$NEW: The IPv6 CE router SHOULD implement the Information Refresh Time option [RFC4242] and associated behaviour. This WAA-4 lingo makes sure operators can switch customers over to using a different set of servers via RENEW (unless the end user overrides automatic time reference acquisition by explicitly configuring a set of servers). Similar goes for the WAA-4 problem. CE UIs should either use "auto" (DHCPv6 DNS/SNTP options) _OR_ local config overrides. And if using "auto", a received set of DNS/SNTP servers are supposed to be the only servers to be used from now on. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From volz@cisco.com Fri Mar 9 14:39:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFFB21E805F for ; Fri, 9 Mar 2012 14:39:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.815 X-Spam-Level: X-Spam-Status: No, score=-9.815 tagged_above=-999 required=5 tests=[AWL=0.783, 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 FWy79Y2T1FLs for ; Fri, 9 Mar 2012 14:39:36 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADC521E80A6 for ; Fri, 9 Mar 2012 14:39:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=12257; q=dns/txt; s=iport; t=1331332776; x=1332542376; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=opBm2SkKLVriWUbOFwKzYVDHOfYbZFRfK2vTp2Qfl1M=; b=BX1uYF5NneCfMUYYVNOVxRuUTX43FPjaT8oDM7YatczMWx4r4A+R6K5J vXF7rC7fwHOjAQXb4a1FKzy+Ua5IgqLOiOE3N15Cmuy7lPIR9UdbCmsnk tGyg9fkaCNi+RShZ6nLFFEOGqt6JvDjbrYA8PwBQDLD7cN5bvhHVPvvR5 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAN+FWk+tJV2a/2dsb2JhbABCtUCBB4IKAQEBBBIBCREDSQwEAgEIEQQBAQsGFwEGAUUJCAEBBAESCBqHaKASAZcOkBVjBIhTnRKDAoE9 X-IronPort-AV: E=Sophos;i="4.73,560,1325462400"; d="scan'208,217";a="65256293" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP; 09 Mar 2012 22:39:35 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q29MdZJh023796; Fri, 9 Mar 2012 22:39:35 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 16:39:35 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCFE45.80B85D1A" Date: Fri, 9 Mar 2012 16:39:34 -0600 Message-ID: In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDEA9@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6204bis WGLC Thread-Index: Acz+PXBJk7Yl1uZoR8Cy1IUvGqaiTgABGd9gAACtEVA= References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> <20120309214138.GA1736@srv03.cluenet.de> <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDEA9@XMB-RCD-109.cisco.com> From: "Bernie Volz (volz)" To: "Hemant Singh (shemant)" , "Daniel Roesen" , , X-OriginalArrivalTime: 09 Mar 2012 22:39:35.0787 (UTC) FILETIME=[8107C3B0:01CCFE45] Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 22:39:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFE45.80B85D1A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Perhaps I missed it, but I don't see any good text in RFC 3315 one can point that says exactly what a client should do with "updated" other-configuration options. The assumption would be to replace it (remove the old, add the new). Though of course there are interesting corner cases - what if the new Reply doesn't have the option (remove the old?). >From RFC 3315: 18.1.8. Receipt of Reply Messages ... Management of the specific configuration information is detailed in the definition of each option in section 22. So I guess by extension responsibility for this falls on the option specification documents. Yet, RFC 3646 is silent about this (as I suspect are more of the documents). - Bernie _____________________________________________ From: Hemant Singh (shemant)=20 Sent: Friday, March 09, 2012 5:26 PM To: Daniel Roesen; v6ops@ietf.org; v6ops-chairs@tools.ietf.org Cc: Dan Wing (dwing); Bernie Volz (volz) Subject: RE: [v6ops] draft-ietf-v6ops-6204bis WGLC Daniel, -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Daniel Roesen Sent: Friday, March 09, 2012 4:42 PM To: v6ops@ietf.org; v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC >WAA-4: I've seen vendors appending DHCPv6-received DNS servers to the list >of already learned DNS servers and thus not actually using them unless >the formerly learned DNS servers become unresponsive. My operator-hat >expectation would be that the communicated list of DNS servers upon >RENEW is the only set of DNS servers to be used in the future. >Should we add further text making the (to an operator) obvious explicit >to close that hole? I agree and also verified that RFC 3646 does not prohibit the new behavior you asked of above. After all, one use case is when the SP signals a DHCPv6 Reconfigure from the DHCPv6 server to the client to ask the client to Renew. On receiving the Reconfigure message, the client issues a RENEW. After all, the motive of the SP with the Reconfigure was to ask the client to obtain new information and a DNS server(s) list qualifies as new information. The client should purge any old information. Cced this email to Bernie (DHCPv6 guru) and Dan (DNS guru) for any comments.=20 If others agree, text in WAA-4 can be updated. Best regards, Hemant ------_=_NextPart_001_01CCFE45.80B85D1A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [v6ops] draft-ietf-v6ops-6204bis WGLC

Perhaps I missed it, but I = don’t see any good text in RFC 3315 one can point that says = exactly what a client should do with “updated” other-configuration options. The = assumption would be to replace it (remove the old, add the new). Though = of course there are interesting corner cases – what if the new = Reply doesn’t have = the option (remove the old?).

From RFC 3315:

18.1.8. Receipt of Reply = Messages

…

   Management of the specific = configuration information is detailed in

   the definition of each option in = section 22.

So I guess by extension responsibility for this falls = on the option specification documents. Yet, RFC 3646 is silent about this (as I suspect are = more of the documents).

-       = Bernie

_____________________________________________
From: Hemant Singh (shemant)
Sent: Friday, March 09, 2012 5:26 PM
To: Daniel Roesen; v6ops@ietf.org; = v6ops-chairs@tools.ietf.org
Cc: Dan Wing (dwing); Bernie Volz (volz)
Subject: RE: [v6ops] = draft-ietf-v6ops-6204bis WGLC

Daniel,

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Daniel = Roesen
Sent: Friday, March 09, 2012 4:42 PM
To: v6ops@ietf.org; v6ops-chairs@tools.ietf.org
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis = WGLC

>WAA-4: = I've seen vendors appending DHCPv6-received DNS servers to the = list

>of = already learned DNS servers and thus not actually using them = unless

>the = formerly learned DNS servers become unresponsive. My = operator-hat

>expectation would be that the communicated list of DNS servers = upon

>RENEW = is the only set of DNS servers to be used in the = future.

>Should = we add further text making the (to an operator) obvious = explicit

>to = close that hole?

I agree and also verified that = RFC 3646 does not prohibit the new behavior you asked of above.  = After all, one use case is when the SP signals a DHCPv6 Reconfigure from = the DHCPv6 server to the client to ask the client to Renew.  On = receiving the Reconfigure message, the client issues a RENEW.  = After all, the motive of the SP with the Reconfigure was to ask the = client to obtain new information and a DNS server(s) list qualifies as = new information.  The client should purge any old = information.  Cced this email to Bernie (DHCPv6 guru) and Dan (DNS = guru) for any comments.

If others agree, text in WAA-4 can be = updated.

Best regards,

Hemant

------_=_NextPart_001_01CCFE45.80B85D1A-- From dr@cluenet.de Fri Mar 9 14:46:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFDAF21E80A6 for ; Fri, 9 Mar 2012 14:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.6 X-Spam-Level: X-Spam-Status: No, score=-4.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, 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 O-7HcWvPilHd for ; Fri, 9 Mar 2012 14:46:18 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id 6165421E805F for ; Fri, 9 Mar 2012 14:46:18 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id C0BDF10808A; Fri, 9 Mar 2012 23:46:17 +0100 (CET) Date: Fri, 9 Mar 2012 23:46:17 +0100 From: Daniel Roesen To: "Hemant Singh (shemant)" Message-ID: <20120309224617.GB10517@srv03.cluenet.de> Mail-Followup-To: "Hemant Singh (shemant)" , v6ops@ietf.org, v6ops-chairs@tools.ietf.org References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> <20120309214138.GA1736@srv03.cluenet.de> <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDEA9@XMB-RCD-109.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDEA9@XMB-RCD-109.cisco.com> X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 22:46:19 -0000 On Fri, Mar 09, 2012 at 04:26:27PM -0600, Hemant Singh (shemant) wrote: > I agree and also verified that RFC 3646 does not prohibit the new > behavior you asked of above. After all, one use case is when the SP > signals a DHCPv6 Reconfigure from the DHCPv6 server to the client to ask > the client to Renew. On receiving the Reconfigure message, the client > issues a RENEW. After all, the motive of the SP with the Reconfigure > was to ask the client to obtain new information and a DNS server(s) list > qualifies as new information. The client should purge any old > information. Exactly that was what we tested, and observed behaviour was quite "suprising" and unpleasant, but still legal to the letters. I wonder wether have to make that more explicit in other areas as well. Think of AFTR_FQDN for example. I'd love to see some requirement text in RFC6204bis which explicitly outlines that information obtained via RENEW MUST override any other information earlier via DHCPv6. This avoids discussing that for all options one by one (DNS servers, SNTP servers, AFTR FQDN, 6RD BR, ...). Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From dr@cluenet.de Fri Mar 9 15:06:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F3221F8564 for ; Fri, 9 Mar 2012 15:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.6 X-Spam-Level: X-Spam-Status: No, score=-3.6 tagged_above=-999 required=5 tests=[AWL=-1.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 VAS9bnFvp1HJ for ; Fri, 9 Mar 2012 15:06:47 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id CBD3321F8559 for ; Fri, 9 Mar 2012 15:06:46 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id 32E0810808A; Sat, 10 Mar 2012 00:06:46 +0100 (CET) Date: Sat, 10 Mar 2012 00:06:46 +0100 From: Daniel Roesen To: "Bernie Volz (volz)" Message-ID: <20120309230646.GA19015@srv03.cluenet.de> Mail-Followup-To: "Bernie Volz (volz)" , "Hemant Singh (shemant)" , v6ops@ietf.org, v6ops-chairs@tools.ietf.org References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> <20120309214138.GA1736@srv03.cluenet.de> <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDEA9@XMB-RCD-109.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 23:06:47 -0000 On Fri, Mar 09, 2012 at 04:39:34PM -0600, Bernie Volz (volz) wrote: > Perhaps I missed it, but I don't see any good text in RFC 3315 one can > point that says exactly what a client should do with "updated" > other-configuration options. The assumption would be to replace it > (remove the old, add the new). Indeed. Not everyone seems to share that assumption though. :) > Though of course there are interesting corner cases - what if the new > Reply doesn't have the option (remove the old?). I would expect that, yes. There is no point in strict additive behaviour. Then again, "replace" behaviour raises the question what a multihomed CE should do which receives conflicting information from multiple DHCPv6 servers. This might/will lead to "flapping" behaviour, especially with short RENEW timers. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From volz@cisco.com Fri Mar 9 15:10:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C19421E8047 for ; Fri, 9 Mar 2012 15:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.571 X-Spam-Level: X-Spam-Status: No, score=-10.571 tagged_above=-999 required=5 tests=[AWL=1.428, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_13=0.6, 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 YmaahVercvhG for ; Fri, 9 Mar 2012 15:10:16 -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 7DA1E21E8028 for ; Fri, 9 Mar 2012 15:10:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=2081; q=dns/txt; s=iport; t=1331334616; x=1332544216; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=lVElmBlc8wRM/sogJPkjNyFrNQ3tyJ7jK2RPNGvjf9A=; b=bWWAnV1jCmdQBSvWVaRdAmkRq56btIiQpLb9R8iRo8U5AvVnbmIUKgvc 8VVxzHY16UTm/u661Q1k2xJVHh7BuBdmw5AY+rQrWQwN2Y3p+SqJcXZYm YO+NqrOmI76IqXjhQQaW2BqvkNHQFVPv81CgqUfkJnZqj7wakZ/m9SQl2 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGuNWk+tJXG9/2dsb2JhbABDtTSBB4IKAQEBBAEBAQ8BHQo0CwwEAgEIDgMEAQEBCgYXAQYBJh8JCAEBBAESCBMHh2gLnAIBnm0EkBVjBIhTnRKDAg X-IronPort-AV: E=Sophos;i="4.73,560,1325462400"; d="scan'208";a="65272031" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 09 Mar 2012 23:10:16 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q29NAFTA021550; Fri, 9 Mar 2012 23:10:15 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 17:10:15 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 9 Mar 2012 17:10:14 -0600 Message-ID: In-Reply-To: <20120309224617.GB10517@srv03.cluenet.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6204bis WGLC Thread-Index: Acz+RneF+K4lkfseS+CSLH1iN92q1gAAnDGQ References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com><20120309214138.GA1736@srv03.cluenet.de><5B6B2B64C9FE2A489045EEEADDAFF2C3042FDEA9@XMB-RCD-109.cisco.com> <20120309224617.GB10517@srv03.cluenet.de> From: "Bernie Volz (volz)" To: "Daniel Roesen" , "Hemant Singh (shemant)" X-OriginalArrivalTime: 09 Mar 2012 23:10:15.0839 (UTC) FILETIME=[C9C96AF0:01CCFE49] Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 23:10:17 -0000 Another solution (or in addition to) may be to file ERRATA on the particular RFC(s). A general statement in RFC 3315 might also be an ERRATA to consider, but I suspect it would be difficult to write and might lead to problems if applied to options it wasn't intended to apply to. That's probably why RFC 3315 is silent about it. Add something the DHC WG should consider when writing new option drafts. - Bernie -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Daniel Roesen Sent: Friday, March 09, 2012 5:46 PM To: Hemant Singh (shemant) Cc: v6ops@ietf.org; v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC On Fri, Mar 09, 2012 at 04:26:27PM -0600, Hemant Singh (shemant) wrote: > I agree and also verified that RFC 3646 does not prohibit the new=20 > behavior you asked of above. After all, one use case is when the SP=20 > signals a DHCPv6 Reconfigure from the DHCPv6 server to the client to=20 > ask the client to Renew. On receiving the Reconfigure message, the=20 > client issues a RENEW. After all, the motive of the SP with the=20 > Reconfigure was to ask the client to obtain new information and a DNS=20 > server(s) list qualifies as new information. The client should purge=20 > any old information. Exactly that was what we tested, and observed behaviour was quite "suprising" and unpleasant, but still legal to the letters. I wonder wether have to make that more explicit in other areas as well. Think of AFTR_FQDN for example. I'd love to see some requirement text in RFC6204bis which explicitly outlines that information obtained via RENEW MUST override any other information earlier via DHCPv6. This avoids discussing that for all options one by one (DNS servers, SNTP servers, AFTR FQDN, 6RD BR, ...). Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From shemant@cisco.com Fri Mar 9 15:57:22 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 838C421F85F2 for ; Fri, 9 Mar 2012 15:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.661 X-Spam-Level: X-Spam-Status: No, score=-9.661 tagged_above=-999 required=5 tests=[AWL=0.937, 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 oT9AbNCeRdhW for ; Fri, 9 Mar 2012 15:57:21 -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 9A4AE21F85EE for ; Fri, 9 Mar 2012 15:57:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7644; q=dns/txt; s=iport; t=1331337441; x=1332547041; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=yM/SjXGSrhKKpYbN5t99353yO6JAsGHjXvBrBE6qLPw=; b=IaGzErNVlAHx1JDr93CJg87KDSjzWaoNTtlc+uurkUxIYdGZdDAZXL5t z7tGzOIAoq8GQq1+43d5Sem5lXh/F5UBrCnV7BMEIWYL5oOMRY72TVHbV rBktw8WDns0dYor8SMPNHQoot97JT+JRXs5roCdqhLJAXQIHSE/jkdwMl 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEmYWk+tJXHA/2dsb2JhbABDtTWBB4IKAQEBAwESAQkRA04HBAIBCA4DBAEBCwYXAQYBRQkIAQEEARIIGodjBZwIAZ5xkBVjBIhTnRKDAg X-IronPort-AV: E=Sophos;i="4.73,560,1325462400"; d="scan'208,217";a="62236087" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 09 Mar 2012 23:57:21 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q29NvKhZ017310; Fri, 9 Mar 2012 23:57:21 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 17:56:19 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCFE50.38EE8B58" Date: Fri, 9 Mar 2012 17:56:18 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDEDF@XMB-RCD-109.cisco.com> In-Reply-To: <20120309223854.GA10517@srv03.cluenet.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6204bis WGLC Thread-Index: Acz+RXeR/oJvgTAHRqOxF+cn5RS1EwABjXMw References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com><20120309214138.GA1736@srv03.cluenet.de><5B6B2B64C9FE2A489045EEEADDAFF2C3042FDEA0@XMB-RCD-109.cisco.com> <20120309223854.GA10517@srv03.cluenet.de> From: "Hemant Singh (shemant)" To: "Daniel Roesen" , , X-OriginalArrivalTime: 09 Mar 2012 23:56:19.0541 (UTC) FILETIME=[3914E050:01CCFE50] Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 23:57:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFE50.38EE8B58 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Daniel, -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Daniel Roesen Sent: Friday, March 09, 2012 5:39 PM To: v6ops@ietf.org; v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC >What about: > >WAA-5: The IPv6 CE router SHOULD implement the Simple Network Time > Protocol (SNTP) as specified in [RFC 2030]. If the CE router > implements SNTP, it requests the SNTP option [RFC4075] and uses > the received list of servers as primary time reference, unless > explicitly configured otherwise. Works for me. > >WAA-$NEW: The IPv6 CE router SHOULD implement the Information Refresh Time > option [RFC4242] and associated behaviour. Splitting to a new bullet makes perfect sense. Slightly changed text below. WAA-$NEW: The IPv6 CE router SHOULD implement the Information Refresh Time option and associated client behavior as specified in [RFC4242]. Thanks much. Best Regards, Hemant ------_=_NextPart_001_01CCFE50.38EE8B58 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: [v6ops] draft-ietf-v6ops-6204bis WGLC

Daniel,

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org]= On Behalf Of Daniel Roesen
Sent: Friday, March 09, 2012 5:39 PM
To: v6ops@ietf.org; v6ops-chairs@tools.ietf.org
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC

>What about:

>

>WAA-5:  The IPv6 CE = router SHOULD implement the Simple Network Time

>        Protocol (SNTP) as = specified in [RFC 2030].  If the CE router

>        implements SNTP, it = requests the SNTP option [RFC4075] and uses

>        the received list of = servers as primary time reference, unless

>        explicitly configured = otherwise.

Works for me.

>

>WAA-$NEW: The IPv6 CE router = SHOULD implement the Information Refresh Time

>        option [RFC4242] and = associated behaviour.

Splitting to a new bullet makes = perfect sense.  Slightly changed text = below.

WAA-$NEW: The IPv6 CE router = SHOULD implement the Information Refresh Time

        = option = and associated client = behavior as = specified in [RFC4242].

Thanks much.

Best Regards,

Hemant

------_=_NextPart_001_01CCFE50.38EE8B58-- From shemant@cisco.com Fri Mar 9 16:11:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3BF421F852A for ; Fri, 9 Mar 2012 16:11:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.405 X-Spam-Level: X-Spam-Status: No, score=-9.405 tagged_above=-999 required=5 tests=[AWL=0.593, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 6TS-65VrKL1t for ; Fri, 9 Mar 2012 16:11:13 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8023721F8528 for ; Fri, 9 Mar 2012 16:11:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=7825; q=dns/txt; s=iport; t=1331338273; x=1332547873; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=8/StH4cqSO3HLTnnDzlh0ZwBAYsRTlMkDbkV2Ojbq6Q=; b=a18YibJewcQv5LgX1ABmVQAVZuppQ+/koGBolt+8BF/jPfYD14pqFU9p lMjYTbYKWaE3xKVoYGZKueCegdVsVgopjg1jOyxicHgs0P2FRlUZdSV5g FY8FkISCPEkdDvt89HwwHg3iq+LuLx6i6a0uV6x9XyNUSXcDObGNRk5Zj M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFANqaWk+tJV2Z/2dsb2JhbABDgkWycIEHggoBAQEEEgEJEQNJEAIBCBEEAQELBhgGAU4IAQEEARIIGodonA0BnnCQFWMEiFOdEoMC X-IronPort-AV: E=Sophos;i="4.73,561,1325462400"; d="scan'208,217";a="65274374" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 10 Mar 2012 00:11:13 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2A0BDlD017161; Sat, 10 Mar 2012 00:11:13 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 18:11:13 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCFE52.4D90FB38" Date: Fri, 9 Mar 2012 18:11:12 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDEE7@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6204bis WGLC Thread-Index: Acz+PXBJk7Yl1uZoR8Cy1IUvGqaiTgABGd9gAACtEVAAAxM1YA== References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> <20120309214138.GA1736@srv03.cluenet.de> <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDEA9@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Bernie Volz (volz)" , "Daniel Roesen" , , X-OriginalArrivalTime: 10 Mar 2012 00:11:13.0182 (UTC) FILETIME=[4DBBABE0:01CCFE52] Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 00:11:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFE52.4D90FB38 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Bernie, _____________________________________________ From: Bernie Volz (volz)=20 Sent: Friday, March 09, 2012 5:40 PM To: Hemant Singh (shemant); 'Daniel Roesen'; 'v6ops@ietf.org'; 'v6ops-chairs@tools.ietf.org' Cc: Dan Wing (dwing); Ralph Droms (rdroms) Subject: RE: [v6ops] draft-ietf-v6ops-6204bis WGLC =20 =20 >Perhaps I missed it, but I don't see any good text in RFC 3315 one can point that says exactly what a client should do with "updated" >other-configuration options. The assumption would be to replace it (remove the old, add the new). Though of course there are interesting >corner cases - what if the new Reply doesn't have the option (remove the old?). =20 I would remove the old because the old would have been asked of in the Renew and the server did not include the option in the reply. It would be good to initiate a discussion in the DHC WG and cc v6ops on this topic. I think we may have a critical mass of issues to embark on a rfc3315bis. It is also interesting that we have to go to other RFCs related to DHCPv6 options to specific such specific behavior there. Maybe there is a magic wand that specifies text in a rfc3315bis to apply to options in the other RFCs.=20 =20 Thanks much for jumping in on this one right away! =20 Hemant=20 ------_=_NextPart_001_01CCFE52.4D90FB38 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Bernie,

_____________________________________________
From: = Bernie Volz (volz)
Sent: Friday, March 09, 2012 5:40 = PM
To: Hemant Singh (shemant); 'Daniel Roesen'; = 'v6ops@ietf.org'; 'v6ops-chairs@tools.ietf.org'
Cc: Dan Wing = (dwing); Ralph Droms (rdroms)
Subject: RE: [v6ops] = draft-ietf-v6ops-6204bis WGLC

 

 

>Perhaps I missed it, = but I don’t see any good text in RFC 3315 one can point that says = exactly what a client should do with “updated” = >other-configuration options. The assumption would be to replace it = (remove the old, add the new). Though of course there are interesting = >corner cases – what if the new Reply doesn’t have the = option (remove the old?).

 

I would remove the old = because the old would have been asked of in the Renew and the server did = not include the option in the reply.  It would be good to initiate = a discussion in the DHC WG and cc v6ops on this topic.  I think we = may have a critical mass of issues to embark on a rfc3315bis.  It = is also interesting that we have to go to other RFCs related to DHCPv6 = options to specific such specific behavior there.  Maybe there is a = magic wand that specifies text in a rfc3315bis to apply to options in = the other RFCs.

 

Thanks much for jumping = in on this one right away!

 

Hemant =

------_=_NextPart_001_01CCFE52.4D90FB38-- From shemant@cisco.com Fri Mar 9 16:21:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B840021F8576 for ; Fri, 9 Mar 2012 16:21:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.732 X-Spam-Level: X-Spam-Status: No, score=-9.732 tagged_above=-999 required=5 tests=[AWL=0.866, 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 KIgV-flxWMIJ for ; Fri, 9 Mar 2012 16:21:00 -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 5B1DB21E8018 for ; Fri, 9 Mar 2012 16:21:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=5500; q=dns/txt; s=iport; t=1331338860; x=1332548460; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=qJp4TaEgMry28ulwa4aKzA9HQT3HHdH/mSYO6eCW0fI=; b=clJXAiW0RgWMo698FSAxiHTxH4Xgc4dl5Or8/RBTEbslH0JEsamFlSN/ 1iQxjIVgWDDjDBuHxWJ0oHQ8QcYKrjWRTP8CvpFggquC4OhnGZFOzJ1MQ E6Ufy5IgxANaUm+Lhp75bv6ueVUHBbdKsALk7aqZ+UKU2l52eA31WG12M I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADOdWk+tJV2c/2dsb2JhbABDgkWycIEHggoBAQEEEgEJEQNJDAQCAQgOAwQBAQsGFwEGAUUJCAEBBAESCBqHaJwMAZ5ukBVjBIhTnRKDAg X-IronPort-AV: E=Sophos;i="4.73,561,1325462400"; d="scan'208,217";a="65282628" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 10 Mar 2012 00:21:00 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id q2A0Kxgh011416; Sat, 10 Mar 2012 00:20:59 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Mar 2012 18:21:00 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCFE53.AB51BF98" Date: Fri, 9 Mar 2012 18:20:58 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDEE9@XMB-RCD-109.cisco.com> In-Reply-To: <20120309230646.GA19015@srv03.cluenet.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6204bis WGLC Thread-Index: Acz+SU/t8CKFuWhNQreWauxa3CKXewACS+nw References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> <20120309214138.GA1736@srv03.cluenet.de> <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDEA9@XMB-RCD-109.cisco.com> <20120309230646.GA19015@srv03.cluenet.de> From: "Hemant Singh (shemant)" To: "Daniel Roesen" , "Bernie Volz (volz)" X-OriginalArrivalTime: 10 Mar 2012 00:21:00.0024 (UTC) FILETIME=[AB84A780:01CCFE53] Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 00:21:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFE53.AB51BF98 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Daniel, =20 -----Original Message----- From: Daniel Roesen [mailto:dr@cluenet.de]=20 Sent: Friday, March 09, 2012 6:07 PM To: Bernie Volz (volz) Cc: Hemant Singh (shemant); v6ops@ietf.org; v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC =20 >Then again, "replace" behaviour raises the question what a multihomed >CE should do which receives conflicting information from multiple DHCPv6 >servers. This might/will lead to "flapping" behaviour, especially with >short RENEW timers. =20 For what it's worth, each DHCPv6 reply is associated with a specific DHCPv6 client-id and server-id. Thus each client updates specific information for options received. I suppose each ipv6 address in the multihomed situation has its own DNS to go to etc., so conflicting information does not matter. =20 =20 Best regards, =20 Hemant ------_=_NextPart_001_01CCFE53.AB51BF98 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Daniel,

 

-----Original Message-----
From: Daniel Roesen = [mailto:dr@cluenet.de]
Sent: Friday, March 09, 2012 6:07 PM
To: = Bernie Volz (volz)
Cc: Hemant Singh (shemant); v6ops@ietf.org; = v6ops-chairs@tools.ietf.org
Subject: Re: [v6ops] = draft-ietf-v6ops-6204bis WGLC

 

>Then again, "replace" behaviour raises = the question what a multihomed

>CE should do which receives conflicting = information from multiple DHCPv6

>servers. This might/will lead to = "flapping" behaviour, especially with

>short RENEW timers.

 

For what it’s worth, each = DHCPv6 reply is associated with a specific DHCPv6 client-id and = server-id.  Thus each client updates specific information for = options received.  I suppose each ipv6 address in the multihomed = situation has its own DNS to go to etc., so conflicting information does = not matter. 

 

Best = regards,

 

Hemant

------_=_NextPart_001_01CCFE53.AB51BF98-- From aservin@lacnic.net Fri Mar 9 16:36:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E9921F84E4 for ; Fri, 9 Mar 2012 16:36:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.43 X-Spam-Level: X-Spam-Status: No, score=0.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.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 BlHHUVzm8jR6 for ; Fri, 9 Mar 2012 16:36:46 -0800 (PST) Received: from mail.lacnic.net.uy (mail.lacnic.net.uy [IPv6:2001:13c7:7001:4000::3]) by ietfa.amsl.com (Postfix) with ESMTP id 46FA121F84E6 for ; Fri, 9 Mar 2012 16:36:46 -0800 (PST) Received: from [10.196.232.94] (unknown [199.91.194.1]) by mail.lacnic.net.uy (Postfix) with ESMTP id E52AA308445; Fri, 9 Mar 2012 22:36:27 -0200 (UYST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_CA18E063-5BB1-400A-9545-30FCD07BAD81" From: Arturo Servin In-Reply-To: Date: Fri, 9 Mar 2012 18:36:26 -0600 Message-Id: <05BDF31B-8149-4398-8185-50F87ED1FFED@lacnic.net> References: <51865E1A72F61D48A247348DCCBA5CFB05B9154C@XMB-AMS-105.cisco.com> To: Mohacsi Janos X-Mailer: Apple Mail (2.1257) X-LACNIC.uy-MailScanner-Information: Please contact the ISP for more information X-LACNIC.uy-MailScanner: Found to be clean X-LACNIC.uy-MailScanner-SpamCheck: X-LACNIC.uy-MailScanner-From: aservin@lacnic.net Cc: v6ops@ietf.org, "Michael Behringer \(mbehring\)" Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 00:36:47 -0000 --Apple-Mail=_CA18E063-5BB1-400A-9545-30FCD07BAD81 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Janos, draft-ietf-grow-private-ip-sp-cores-00 Regards, .as On 8 Mar 2012, at 10:35, Mohacsi Janos wrote: > Hi Michael, >=20 > We are using such a setup for more than 6-8 years now. I always = talking advantages and disadvantages of using link-local addresses on = various IPv6 tutorial. I did not think it should have been documented as = a draft, but if you think worth it, I can support it. (NB: are there any = draft to use private IPv4 addresses in the Network Core? ) >=20 > Janos Mohacsi > Head of HBONE+ project > Network Engineer, Deputy Director of Network Planning and Projects > NIIF/HUNGARNET, HUNGARY > Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 >=20 > On Thu, 8 Mar 2012, Michael Behringer (mbehring) wrote: >=20 >> V6ops WG, >>=20 >> Eric and myself published a new draft, which is in the context of = v6ops. >> We'd like to solicit feedback. >>=20 >> We feel there are substantial advantages to only using link-local >> addresses on core links, and propose this model as a "best common >> practice". However, there are some caveats. >>=20 >> Our draft lists advantages and disadvantages to allow network = operators >> to make a factual decision on whether this model fits their needs. >>=20 >> Feedback? >> Michael >>=20 >>=20 >> http://wiki.tools.ietf.org/html/draft-behringer-lla-only-00 >>=20 >>> -- >>> Using Only Link-Local Address in Network Core >>> draft-behringer-lla-only-00 >>>=20 >>> Abstract >>>=20 >>> This document proposes to use only IPv6 link-local addresses on >>> infrastructure links between routers, wherever possible. It >>> discusses the advantages and disadvantages of this approach to aide >>> the decision process for a given network, >>> -- >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_CA18E063-5BB1-400A-9545-30FCD07BAD81 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii  draft-ietf-grow-private-ip-sp-cores-00


=
Regards,
.as


On 8 = Mar 2012, at 10:35, Mohacsi Janos wrote:

Hi = Michael,

= We are using such a setup for more than 6-8 years now. I always = talking advantages and disadvantages of using link-local addresses on = various IPv6 tutorial. I did not think it should have been documented as = a draft, but if you think worth it, I can support it. (NB: are there any = draft to use private IPv4 addresses in the Network Core? )

Janos = Mohacsi
Head of HBONE+ project
Network Engineer, Deputy Director = of Network Planning and Projects
NIIF/HUNGARNET, HUNGARY
Key = 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF = 9882

On Thu, 8 Mar 2012, Michael Behringer (mbehring) = wrote:

V6ops = WG,

Eric and myself published a new draft, which is in the = context of v6ops.
We'd like to = solicit feedback.

We feel there = are substantial advantages to only using = link-local
addresses on core = links, and propose this model as a "best = common
practice". However, = there are some caveats.

Our draft lists = advantages and disadvantages to allow network = operators
to make a factual = decision on whether this model fits their = needs.

Feedback?
Michael


http:= //wiki.tools.ietf.org/html/draft-behringer-lla-only-00

--
=            Using = Only Link-Local Address in Network = Core
=             &n= bsp;       draft-behringer-lla-only-00<= br>

Abstract

 This document proposes to = use only IPv6 link-local addresses = on
 infrastructure links between routers, wherever = possible.  It
 discusses the advantages = and disadvantages of this approach to = aide
 the decision process for a given = network,
--
_______________________________________________
v6ops mailing = list
v6ops@ietf.org
https://www.ietf.org/= mailman/listinfo/v6ops

___________________________________________= ____
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/= mailman/listinfo/v6ops

= --Apple-Mail=_CA18E063-5BB1-400A-9545-30FCD07BAD81-- From phdgang@gmail.com Sat Mar 10 02:17:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B6621F8623 for ; Sat, 10 Mar 2012 02:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, 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 MNSrtRk8PY1I for ; Sat, 10 Mar 2012 02:17:55 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id BE95021F8622 for ; Sat, 10 Mar 2012 02:17:54 -0800 (PST) Received: by wibhj6 with SMTP id hj6so1165233wib.13 for ; Sat, 10 Mar 2012 02:17: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 :content-type:content-transfer-encoding; bh=xaDv4HwQw4VShsVljVB4UiKSOiS70atHe+RAmBEON7U=; b=e1eYu3hXSQLSdu3d76SL5ONd6Zf/+9S4tsPjoEy2s/tnsMJ1b/MnyPpOxhVo17f1ni wgf0n+bfJmd6QMLRBcXJhPq4gwp2BIBOHuGRok1dw/9dlJq1F1+SW3ZEMh8dFTiTvLZp 5YOFeU6JIO6L2J0dEe9cVEzEVXVCQsga8eaVE1SVgNRdrAAcWTu4Fq487KrvByD0pluP lbZPfYxCgoUuRumjWlYuwn1V8sd2yopQVSULhJ+Sr4d9Up6ZAeeR1fA5PTZ/VoSBrDdU dla6aIFgYiyCA32B/62sCn/Br/ozpbWTIg/W/mAJqlZvBod8vHSnncjqgQHP4LP57Rmk t1eA== MIME-Version: 1.0 Received: by 10.180.83.97 with SMTP id p1mr12029334wiy.19.1331374673869; Sat, 10 Mar 2012 02:17:53 -0800 (PST) Received: by 10.180.7.105 with HTTP; Sat, 10 Mar 2012 02:17:53 -0800 (PST) In-Reply-To: <11ECC355-6FAC-4D69-A615-AB43F2180CEE@laposte.net> References: <11ECC355-6FAC-4D69-A615-AB43F2180CEE@laposte.net> Date: Sat, 10 Mar 2012 18:17:53 +0800 Message-ID: From: GangChen To: =?ISO-8859-1?B?UultaSBEZXNwculz?= , v6ops@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] I-D Action: draft-chen-v6ops-nat64-experience-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 10:17:56 -0000 Hello Remi, > 1. > This kind of draft is IMHO useful because it discusses the global picture= . Thanks for the supports. > Maybe calling it NAT64 operational "issues" or "scenarios", would better > describe its contents than just "experiences" which, IMHO suggests a repo= rt > on already observed behaviors. Your interpretation is correct. The word of "experiences" came from last meeting discussions. People expected the draft provides NAT64 operational views and document experiences. It would like to draft what we have observed more than what we recommended to let IETF do some protocol enhancements. Therefore, I guess "experiences" is good to express the intention. > 2. > One point of substance: sec. 3.6 says "One approach avoiding this issue i= s > to configure IPv4 MTU>=3D1260, which would forbid the occurence of PTB<12= 80". > It should be possible for the IPv6 Internet to IPv4 network scenario of s= ec. > 3, but not for the IPv6 network to IPv4 Internet scenario of sec 2. This > should IMHO be clarified. Agree. It should be clarified. I will do in next version. > > 3. > Couldn' understand this sentence of sec. 1: > "Since the scenario of "The IPv6 Internet to the IPv4 Internet" seems the > ideal case for in-network translation technology, this document has focus= ed > on the three cases and categorized different NAT64 usages as NAT64-CGN an= d > NAT64-CE." Considering potential audiences, who want to get the information for their possible deployment of NAT64 in near future, we are focusing three common cases of NAT64. "The IPv6 Internet to the IPv4 Internet" may be too early to state some experiences. > 4. > Minor noted typos: > - 3.3 > "might a good choice" =3D> "might be a good choice" > - 3.1 > "is to distributed" =3D> "is to distribute" > - 3.5 > " a synthetic AAAA records" =3D> "a synthetic AAAA record" > - 3.6 > "occurence" =3D> "occurrence" Many thanks. I would fix that in next version. > 5. > For a further version, I would suggest to include more referenced documen= ts > (in particular about Lawful traceability, IAP, ALGs other than FTP, SYN > Proxy-cookie). Will do in next version. BRs Gang > Regards, > RD > > > > Le 2012-02-14 =E0 05:11, GangChen a =E9crit : > >> Hello all, >> >> We have published draft-chen-v6ops-nat64-experience-00, which >> described NAT64 operational expriences and updated with all the >> information from the presentation of draft-chen-v6ops-nat64-cpe at >> last meeting. Considering the new changes, authors would like to >> retire the old draft (i.e. draft-chen-v6ops-nat64-cpe) and continue >> the discussion on nat64 experiences. >> >> All comments are welcome. >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : NAT64 Operational Experiences >> Author(s) : Gang Chen >> Zhen Cao >> Cameron Byrne >> QiBo Niu >> Filename : draft-chen-v6ops-nat64-experience-00.txt >> Pages : 11 >> Date : 2012-02-13 >> >> This document summarizes some stateful NAT64 deployment scenarios and >> operational experiences for NAT64-CGN and NAT64-CE. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-experience-00= .txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-chen-v6ops-nat64-experience-00.= txt >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > From dr@cluenet.de Sat Mar 10 03:08:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27DF621F85B5 for ; Sat, 10 Mar 2012 03:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.05 X-Spam-Level: X-Spam-Status: No, score=-3.05 tagged_above=-999 required=5 tests=[AWL=-1.050, BAYES_00=-2.599, J_CHICKENPOX_64=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 GgqXmRr+-XmR for ; Sat, 10 Mar 2012 03:08:04 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id 64C6121F8585 for ; Sat, 10 Mar 2012 03:08:03 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id D2890108363; Sat, 10 Mar 2012 12:08:01 +0100 (CET) Date: Sat, 10 Mar 2012 12:08:01 +0100 From: Daniel Roesen To: "Hemant Singh (shemant)" Message-ID: <20120310110801.GA28234@srv03.cluenet.de> Mail-Followup-To: "Hemant Singh (shemant)" , "Bernie Volz (volz)" , v6ops@ietf.org, v6ops-chairs@tools.ietf.org References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> <20120309214138.GA1736@srv03.cluenet.de> <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDEA9@XMB-RCD-109.cisco.com> <20120309230646.GA19015@srv03.cluenet.de> <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDEE9@XMB-RCD-109.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDEE9@XMB-RCD-109.cisco.com> X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 11:08:05 -0000 On Fri, Mar 09, 2012 at 06:20:58PM -0600, Hemant Singh (shemant) wrote: > For what it's worth, each DHCPv6 reply is associated with a specific > DHCPv6 client-id and server-id. Thus each client updates specific > information for options received. I suppose each ipv6 address in the > multihomed situation has its own DNS to go to etc., so conflicting > information does not matter. DNS resolving is a system-wide matter, not a per-interface/IP matter. If a system wants to talk to random.fqdn, it resolves that FQDN via whatever DNS recursors available to it, and then looks up the egress interface (and thus source IP) to be used for connecting to that remote system. How could you know which interface-specific recursor you'll use before knowing which across which interface you're going to you to reach the remote system? It's a catch 22. Real world example: CE gets Internet uplink via PPPoE on one VLAN, and IPTV uplink via DHCP via another VLAN. From both connections, a conflicting set of DNS recursors are being obtained. Which set is the one to use to forward proxied requests from LAN clients to? LAN contains "Internet" clients as well as IPTV STBs - indistinguishable by the CE. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From dr@cluenet.de Sat Mar 10 03:10:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2800421F8559 for ; Sat, 10 Mar 2012 03:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.14 X-Spam-Level: X-Spam-Status: No, score=-3.14 tagged_above=-999 required=5 tests=[AWL=-0.540, 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 0grEw8j6NmsG for ; Sat, 10 Mar 2012 03:10:44 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id 9328821F8475 for ; Sat, 10 Mar 2012 03:10:43 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id 0752D108364; Sat, 10 Mar 2012 12:10:43 +0100 (CET) Date: Sat, 10 Mar 2012 12:10:43 +0100 From: Daniel Roesen To: v6ops@ietf.org, v6ops-chairs@tools.ietf.org Message-ID: <20120310111042.GA30841@srv03.cluenet.de> Mail-Followup-To: v6ops@ietf.org, v6ops-chairs@tools.ietf.org References: <20120309223854.GA10517@srv03.cluenet.de> <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDEDF@XMB-RCD-109.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDEDF@XMB-RCD-109.cisco.com> X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 11:10:45 -0000 On Fri, Mar 09, 2012 at 05:56:18PM -0600, Hemant Singh (shemant) wrote: > Splitting to a new bullet makes perfect sense. Slightly changed text > below. > > WAA-$NEW: The IPv6 CE router SHOULD implement the Information Refresh Time > option and associated client behavior as specified in [RFC4242]. That's even better indeed. Thanks! Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From shemant@cisco.com Sat Mar 10 07:10:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE4321F860E for ; Sat, 10 Mar 2012 07:10:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.47 X-Spam-Level: X-Spam-Status: No, score=-9.47 tagged_above=-999 required=5 tests=[AWL=0.528, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, 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 48pY+UlgYjKC for ; Sat, 10 Mar 2012 07:10:34 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3759A21F8596 for ; Sat, 10 Mar 2012 07:10:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=7632; q=dns/txt; s=iport; t=1331392234; x=1332601834; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=MgfsDkYz7/4BfBYasv2OMgX+6/hODrBLV+1vHDlrqjs=; b=i4YexNGtpQE2PcMW+hzPrw5UY8rtgI7MdhZIdTKSCNqjaspPF99FJc13 R4IUt6oQ5cAIOEoXDUhsHYF+T9EqLh5DjKfNjj+iXxzLVTEQg+kC/n1mt jdBsBkQolgoMxqKI42iaE5AdxnZd83Vdy/PxEYNxo33uu7NSL+QnEXN9J k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlEFALFuW0+tJV2b/2dsb2JhbABCgkWqBgGIcoEHggoBAQEEEgEJEQNJDAQCAQgOAwQBAQsGFwEGAUUJCAEBBBMIGodoC5tsAZ45kB5jBIhUnRuDAg X-IronPort-AV: E=Sophos;i="4.73,563,1325462400"; d="scan'208,217";a="65359642" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP; 10 Mar 2012 15:10:27 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2AFARO1031270; Sat, 10 Mar 2012 15:10:27 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 10 Mar 2012 09:10:27 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCFECF.ECC91438" Date: Sat, 10 Mar 2012 09:10:24 -0600 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDF07@XMB-RCD-109.cisco.com> In-Reply-To: <20120310110801.GA28234@srv03.cluenet.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6204bis WGLC Thread-Index: Acz+rhDDLmMcRerxSUyi3v7yblDdUwAIYYNA References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> <20120309214138.GA1736@srv03.cluenet.de> <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDEA9@XMB-RCD-109.cisco.com> <20120309230646.GA19015@srv03.cluenet.de> <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDEE9@XMB-RCD-109.cisco.com> <20120310110801.GA28234@srv03.cluenet.de> From: "Hemant Singh (shemant)" To: "Daniel Roesen" X-OriginalArrivalTime: 10 Mar 2012 15:10:27.0357 (UTC) FILETIME=[ECED6CD0:01CCFECF] Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 15:10:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFECF.ECC91438 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Daniel, =20 Agree with you. Thanks for the details below. Also, as an FYI, the both rfc6204 and rfc6204bis do not support multihoming for a feature. Multihoming is future work going on in homenet. =20 One work going on in the DNS server selection area is this document. =20 http://tools.ietf.org/html/draft-ietf-mif-dns-server-selection-01 =20 Best regards, =20 Hemant =20 -----Original Message----- From: Daniel Roesen [mailto:dr@cluenet.de]=20 Sent: Saturday, March 10, 2012 6:08 AM To: Hemant Singh (shemant) Cc: Bernie Volz (volz); v6ops@ietf.org; v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC =20 DNS resolving is a system-wide matter, not a per-interface/IP matter. =20 If a system wants to talk to random.fqdn, it resolves that FQDN via whatever DNS recursors available to it, and then looks up the egress interface (and thus source IP) to be used for connecting to that remote system. How could you know which interface-specific recursor you'll use before knowing which across which interface you're going to you to reach the remote system? It's a catch 22. =20 Real world example: CE gets Internet uplink via PPPoE on one VLAN, and IPTV uplink via DHCP via another VLAN. From both connections, a conflicting set of DNS recursors are being obtained. Which set is the one to use to forward proxied requests from LAN clients to? LAN contains "Internet" clients as well as IPTV STBs - indistinguishable by the CE. =20 Best regards, Daniel =20 --=20 CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 ------_=_NextPart_001_01CCFECF.ECC91438 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Daniel,

 

Agree with you.  Thanks for the = details below.  Also, as an FYI, the both rfc6204 and rfc6204bis do = not support multihoming for a feature.  Multihoming is future work = going on in homenet.

 

One work = going on in the DNS server selection area is this = document.

 

http://tools.ietf.org/html/draft-ietf-mif-dns-server-selection-01

 

Best = regards,

 

Hemant

 

-----Original Message-----
From: Daniel Roesen = [mailto:dr@cluenet.de]
Sent: Saturday, March 10, 2012 6:08 AM
To: = Hemant Singh (shemant)
Cc: Bernie Volz (volz); v6ops@ietf.org; = v6ops-chairs@tools.ietf.org
Subject: Re: [v6ops] = draft-ietf-v6ops-6204bis WGLC

 

DNS = resolving is a system-wide matter, not a per-interface/IP = matter.

 

If a system wants to talk to random.fqdn, it = resolves that FQDN via

whatever = DNS recursors available to it, and then looks up the = egress

interface (and thus source = IP) to be used for connecting to that remote

system. How could you know which interface-specific = recursor you'll use

before knowing = which across which interface you're going to you to = reach

the remote system? It's a = catch 22.

 

Real world example: CE gets Internet uplink via = PPPoE on one VLAN, and

IPTV uplink = via DHCP via another VLAN. From both connections, a

conflicting set of DNS recursors are being = obtained. Which set is the

one to = use to forward proxied requests from LAN clients to? LAN = contains

"Internet" = clients as well as IPTV STBs - indistinguishable by the = CE.

 

Best regards,

Daniel

 

-- =

CLUE-RIPE -- Jabber: = dr@cluenet.de -- dr@IRCnet -- PGP: = 0xA85C8AA0

------_=_NextPart_001_01CCFECF.ECC91438-- From dr@cluenet.de Sat Mar 10 08:40:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 488AF21F8655 for ; Sat, 10 Mar 2012 08:40:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.05 X-Spam-Level: X-Spam-Status: No, score=-3.05 tagged_above=-999 required=5 tests=[AWL=-0.450, 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 EAMv66yejEo6 for ; Sat, 10 Mar 2012 08:40:16 -0800 (PST) Received: from mail1.cluenet.de (mail1.cluenet.de [IPv6:2001:1440:201:101::5]) by ietfa.amsl.com (Postfix) with ESMTP id A8C5B21F864F for ; Sat, 10 Mar 2012 08:40:16 -0800 (PST) Received: by mail1.cluenet.de (Postfix, from userid 500) id D7048108363; Sat, 10 Mar 2012 17:40:12 +0100 (CET) Date: Sat, 10 Mar 2012 17:40:12 +0100 From: Daniel Roesen To: "Hemant Singh (shemant)" Message-ID: <20120310164012.GA14221@srv03.cluenet.de> Mail-Followup-To: "Hemant Singh (shemant)" , v6ops@ietf.org, v6ops-chairs@tools.ietf.org References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> <20120309214138.GA1736@srv03.cluenet.de> <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDEA9@XMB-RCD-109.cisco.com> <20120309230646.GA19015@srv03.cluenet.de> <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDEE9@XMB-RCD-109.cisco.com> <20120310110801.GA28234@srv03.cluenet.de> <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDF07@XMB-RCD-109.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDF07@XMB-RCD-109.cisco.com> X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.17 (2007-11-01) Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 16:40:17 -0000 On Sat, Mar 10, 2012 at 09:10:24AM -0600, Hemant Singh (shemant) wrote: > both rfc6204 and rfc6204bis do not support multihoming for a feature. > Multihoming is future work going on in homenet. Sure, but vendors out there already support some kind of multihoming and are certainly reluctant to implement behaviour incompatible with that. :-) It's about what we can reasonably ask for from those implementors. Perhaps we shall ask to replace the set of servers received from the same source. Which leads to the desired behaviour in the non-multihomed scenario assumed in RFC6204(bis) and doesn't preclude vendor's solution for multihomed scenarios. > One work going on in the DNS server selection area is this document. > > http://tools.ietf.org/html/draft-ietf-mif-dns-server-selection-01 Thanks for the reference. Complex stuff which is probably impossible to get right automagically (as noted in the draft as well). Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 From shemant@cisco.com Sun Mar 11 08:01:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50AB21F86FE for ; Sun, 11 Mar 2012 08:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.792 X-Spam-Level: X-Spam-Status: No, score=-9.792 tagged_above=-999 required=5 tests=[AWL=0.806, 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 mer3QMvKEd2t for ; Sun, 11 Mar 2012 08:01:43 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id A41F321F86FD for ; Sun, 11 Mar 2012 08:01:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=8974; q=dns/txt; s=iport; t=1331478103; x=1332687703; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=pB+WNAhBT1/SHnuc2Pz35x3Bn2W/87KbNMn3qDDNFeM=; b=Y1kYOsICLEuJD8eAhatJe1ohWsoF7JTia5O3LKsZCWk34STTGGuPOESB u1vzTPkfLLkGtEwXLXhHaeD/4CNZ/tf3nVbz3QfRHev4QW7d9xw9mSel4 O5dFDdukTiXhVyP8B1An2Z20RvdI+QgQhyrs88PrTFTwaDdFINiRfSpHC Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKq9XE+tJXG+/2dsb2JhbABCgkWyfIEHggkBAQEEEgEJEQNJDAQCAQgOAwQBAQsGFwEGAUUJCAEBBBMIGodom10BnXCQHmMEiFSdG4MB X-IronPort-AV: E=Sophos;i="4.73,566,1325462400"; d="scan'208,217";a="65471933" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 11 Mar 2012 15:01:40 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2BF1eJN015611; Sun, 11 Mar 2012 15:01:40 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Mar 2012 10:01:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCFF97.DD0C6ED8" Date: Sun, 11 Mar 2012 10:01:38 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDF39@XMB-RCD-109.cisco.com> In-Reply-To: <20120309224617.GB10517@srv03.cluenet.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6204bis WGLC Thread-Index: Acz+RnIv06iKvvvZTeSxBGYnF6//0ABT8ZgA References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> <20120309214138.GA1736@srv03.cluenet.de> <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDEA9@XMB-RCD-109.cisco.com> <20120309224617.GB10517@srv03.cluenet.de> From: "Hemant Singh (shemant)" To: "Daniel Roesen" X-OriginalArrivalTime: 11 Mar 2012 15:01:40.0277 (UTC) FILETIME=[DD2D2650:01CCFF97] Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 15:01:44 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFF97.DD0C6ED8 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Daniel and Bernie, =20 Please see a stab at the requirement Daniel asked for.=20 =20 -----Original Message----- From: Daniel Roesen [mailto:dr@cluenet.de]=20 Sent: Friday, March 09, 2012 5:46 PM To: Hemant Singh (shemant) Cc: v6ops@ietf.org; v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC =20 >I wonder wether have to make that more explicit in other areas as well. >Think of AFTR_FQDN for example. =20 >I'd love to see some requirement text in RFC6204bis which explicitly >outlines that information obtained via RENEW MUST override any other >information earlier via DHCPv6. This avoids discussing that for all >options one by one (DNS servers, SNTP servers, AFTR FQDN, 6RD BR, ...). =20 WAA-x Information in DHCPv6 options in a DHCPv6 REPLY in response to a DHCPv6 RENEW message=20 MUST override existing information learnt via DHCPv6. Further, if the DHCPv6 RENEW message includes an option in the DHCPv6 ORO option but the server does not return the option in the REPLY,=20 the CE router purges existing information related to the option. =20 Note the history of rfc6204/rfc6204bis has been that the document does tighten text if the text in the existing protocol RFC is not as tight. The reason is because the IPv6 CE router document is a device-specific specification that can include tighter text. One example is the W-5 bullet in rfc6204/rfc6204bis related to the MUST use a persistent DHCPv6 DUID. RFC 3315 has a SHOULD requirement on the DUID persistence. Thus I think the rfc6240bis document can move forward with a new bullet above while the DHCPv6 ERRATA takes its due course of action on existing DHCPv6 documents. Of course, the new text above is open to review by the DHC WG. =20 Best regards, =20 Hemant ------_=_NextPart_001_01CCFF97.DD0C6ED8 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Daniel and = Bernie,

 

Please = see a stab at the requirement Daniel asked for.

 

-----Original Message-----
From: = Daniel Roesen [mailto:dr@cluenet.de] =
Sent: Friday, March 09, 2012 5:46 PM
To: Hemant Singh = (shemant)
Cc: v6ops@ietf.org; = v6ops-chairs@tools.ietf.org
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis = WGLC

 

>I = wonder wether have to make that more explicit in other areas as = well.

>Think of AFTR_FQDN for = example.

 

>I'd = love to see some requirement text in RFC6204bis which = explicitly

>outlines that information = obtained via RENEW MUST override any other

>information earlier via DHCPv6. This avoids discussing that = for all

>options one by one (DNS servers, = SNTP servers, AFTR FQDN, 6RD BR, ...).

 

WAA-x Information in DHCPv6 options = in a DHCPv6 REPLY in response to a DHCPv6 RENEW message =

      MUST override existing = information learnt via DHCPv6.  Further, if the DHCPv6 RENEW = message

      = includes an option in the DHCPv6 ORO option but the server does not = return the option in the REPLY,

      the CE router purges existing = information related to the option.

 

Note the history of = rfc6204/rfc6204bis has been that the document does tighten text if the = text in the existing protocol RFC is not as tight.  The reason is = because the IPv6 CE router document is a device-specific specification = that can include tighter text.  One example is the W-5 bullet in = rfc6204/rfc6204bis related to the MUST use a persistent DHCPv6 DUID. =  RFC 3315 has a SHOULD requirement on the DUID persistence.  = Thus I think the rfc6240bis document can move forward with a new bullet = above while the DHCPv6 ERRATA takes its due course of action on existing = DHCPv6 documents.  Of course, the new text above is open to review = by the DHC WG.

 

Best = regards,

 

Hemant

------_=_NextPart_001_01CCFF97.DD0C6ED8-- From denghui02@gmail.com Sun Mar 11 08:35:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D237421F860D for ; Sun, 11 Mar 2012 08:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.004 X-Spam-Level: X-Spam-Status: No, score=-103.004 tagged_above=-999 required=5 tests=[AWL=-0.006, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, 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 CW1pyBsrBClC for ; Sun, 11 Mar 2012 08:35:15 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id E866921F867F for ; Sun, 11 Mar 2012 08:35:14 -0700 (PDT) Received: by ggmi1 with SMTP id i1so2132707ggm.31 for ; Sun, 11 Mar 2012 08:35:14 -0700 (PDT) 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=VUVUuSa7gA87adjHaH1F3UIbzvekS4wRfeOZ9dUnb4w=; b=TtERHlA2m43W0Nv8bK+wIcfYa9zeLBOvYHTP+LDKfxIuewvkI8Ws1NBfzQdZryAfOH c6xK1QNYyQHyzqb2UntAoyzkpQiOZkhsKRvxaBij32X4stohmw71NQxQa0NKKPlzmd+O G1ovX27WIqfZQRkDA/7/8QCZaIy2PBM5Sc+xY41AZs7PZaVNOHQXPc7NIGnLv9Rtgpw9 BPUdKs4TwavXtDGyt5Ig6wJDs5wHt7kf/oR3G4x7Wg7vw4VXRUdSxUFzIg4MZzEEDvM/ j8rN3K+16IzpKhQu+va/cbUoAfwFnUAOeYZRGK+Iu9rr34RE2mhT235cKJPjzlM/nHrM TreQ== MIME-Version: 1.0 Received: by 10.236.184.8 with SMTP id r8mr10115789yhm.110.1331480114500; Sun, 11 Mar 2012 08:35:14 -0700 (PDT) Received: by 10.147.123.12 with HTTP; Sun, 11 Mar 2012 08:35:14 -0700 (PDT) In-Reply-To: <4F45B554.2060103@gmail.com> References: <4F45B554.2060103@gmail.com> Date: Sun, 11 Mar 2012 23:35:14 +0800 Message-ID: From: Hui Deng To: Brian E Carpenter Content-Type: multipart/alternative; boundary=20cf305640674014a204baf95f64 Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action: draft-carpenter-v6ops-icp-guidance-03.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 15:35:15 -0000 --20cf305640674014a204baf95f64 Content-Type: text/plain; charset=ISO-8859-1 Hi Authors, I have several comments about this draft: 1) do you want to classify different level of ICP, from the reading, this document is targetting at the ICP who are not faimliar with IPv6, but sometimes, ICP may deploy their server in some IDC or some may be based on their own location, which may have different consideration; 2) Most of ICP consider end to end IPv4 together with outside in and inside out; 3) Load balance is still needed which is same as today IPv4 even there are no more traffic for IPv6, for most ICP, they need to know the geo-location information during the packet going through the load balance. 4) ICP need to fully understand how to avoid DDOS when they launch the IPv6, otherwise they will always need NAT solution Regards, -Hui 2012/2/23 Brian E Carpenter > Hi, > > This version has various updates due to comments from the WG. > > We are not asking for a meeting slot in Paris, but we'd like the > chairs to put the question whether the WG wants to adopt this > draft. In any case we still want more input to correct and > expand the draft. > > Brian + Sheng > > -------- Original Message -------- > Subject: I-D Action: draft-carpenter-v6ops-icp-guidance-03.txt > Date: Wed, 22 Feb 2012 14:30:09 -0800 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > Title : IPv6 Guidance for Internet Content and > Application Service Providers > Author(s) : Brian Carpenter > Sheng Jiang > Filename : draft-carpenter-v6ops-icp-guidance-03.txt > Pages : 18 > Date : 2012-02-22 > > This document provides guidance and suggestions for Internet > Content > Providers and Application Service Providers who wish to offer > their > service to both IPv6 and IPv4 customers. Many of the points will > also apply to any enterprise network preparing for IPv6 users. > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > > ftp://ftp.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance-03.txt > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --20cf305640674014a204baf95f64 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Authors,
=A0
I have several comments about this draft:
1) do you want to classif= y different level of ICP, from the reading, this document is targetting at<= br>the ICP who are not faimliar with IPv6, but sometimes, ICP may deploy th= eir server in some IDC or some may
be based on their own location, which may have different consideration;
=A0
2) Most of ICP consider end to end IPv4 together with outside in and i= nside out;
=A0
3) Load balance is still needed which is same as today IPv4 even there= are no more traffic for IPv6,
for most ICP, they need to know the geo-= location information during the packet going through the load balance.
=A0
4) ICP need to fully understand how to avoid DDOS when they launch the= IPv6, otherwise they will always need NAT solution
=A0
Regards,
=A0
-Hui


2012/2/23 Brian E Carpenter &l= t;brian.e.carpenter@gmail.co= m>
Hi,

This version has various u= pdates due to comments from the WG.

We are not asking for a meeting = slot in Paris, but we'd like the
chairs to put the question whether the WG wants to adopt this
draft. In = any case we still want more input to correct and
expand the draft.
=A0 =A0Brian + Sheng

-------- Original Message --------
Subject= : I-D Action: draft-carpenter-v6ops-icp-guidance-03.txt
Date: Wed, 22 Feb 2012 14:30:09 -0800
From: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org


A New Internet-Draft is available from the on-line
Internet-Draf= ts directories.

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : IPv6 Guid= ance for Internet Content and
Application Service Providers
=A0 =A0 = =A0 =A0Author(s) =A0 =A0 =A0 : Brian Carpenter
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Sheng Jiang
=A0 =A0 = =A0 =A0Filename =A0 =A0 =A0 =A0: draft-carpenter-v6ops-icp-guidance-03.txt<= br>=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 18
=A0 =A0 =A0 =A0Date =A0= =A0 =A0 =A0 =A0 =A0: 2012-02-22

=A0 This document provides guidance= and suggestions for Internet
Content
=A0 Providers and Application Service Providers who wish to offe= r
their
=A0 service to both IPv6 and IPv4 customers. =A0Many of the p= oints will
=A0 also apply to any enterprise network preparing for IPv6 u= sers.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance-0= 3.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-carpent= er-v6ops-icp-guidance-03.txt

_______________________________________________
I-D-Announce mailing= list
I-D-Announce@ietf.org=
https://www.ietf.org/mailman/listinfo/i-d-announce<= br> Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.or= g/ietf/1shadow-sites.txt


_______________________________________________
v6ops mailing li= st
v6ops@ietf.org
https://www.ie= tf.org/mailman/listinfo/v6ops

--20cf305640674014a204baf95f64-- From brian.e.carpenter@gmail.com Sun Mar 11 12:15:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68D021F863E for ; Sun, 11 Mar 2012 12:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.191 X-Spam-Level: X-Spam-Status: No, score=-103.191 tagged_above=-999 required=5 tests=[AWL=-0.192, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, 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 H3XakHnqtVOc for ; Sun, 11 Mar 2012 12:15:16 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id D415921F8627 for ; Sun, 11 Mar 2012 12:15:15 -0700 (PDT) Received: by eeke51 with SMTP id e51so868325eek.31 for ; Sun, 11 Mar 2012 12:15:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=q2yRtWOIvO9dvOfNWwrA1pa4Npz2GQtNQ+bwuh/0+NA=; b=dSVCvRojQGNbIcZcFLy3qS1V7b0AdZytOOz41nXqKgXehiOzhIgfpTKb+aljrpUn6e ZxTTOKAnhb3paD+o7sMB326y0XcQSqsTDvUBqnLdD/KdJvJRv/jEvZF5tTgbp8A3aMqH rWnlu2ppUUqVZYb5iiCU1SsuMTTFNF3bmii9N0Jl+RcIe/f2YHwIvIt01bfzh07/DCDA 2jDqnmIkY8pZSxQ2WWzprfymyytp1ZA958HS4S8dtylXmoS5b1bMvp8HfwcXkRXth8qK alQX9yF2zrt0mq5x84GcDkm0VhQMbF78utvKaJ0xU40uMqnAaG2TkVKF7h2l7X05Fv62 sjfw== Received: by 10.14.194.72 with SMTP id l48mr89509een.100.1331493314942; Sun, 11 Mar 2012 12:15:14 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id h47sm41579834eea.10.2012.03.11.12.15.10 (version=SSLv3 cipher=OTHER); Sun, 11 Mar 2012 12:15:14 -0700 (PDT) Message-ID: <4F5CF9B2.5070702@gmail.com> Date: Mon, 12 Mar 2012 08:14:58 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hui Deng References: <4F45B554.2060103@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action: draft-carpenter-v6ops-icp-guidance-03.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 19:15:17 -0000 Hi Deng, On 2012-03-12 04:35, Hui Deng wrote: > Hi Authors, > > I have several comments about this draft: > 1) do you want to classify different level of ICP, from the reading, this > document is targetting at > the ICP who are not faimliar with IPv6, but sometimes, ICP may deploy their > server in some IDC or some may > be based on their own location, which may have different consideration; I think that our main target is an ICP that is mainly familiar with IPv4. In the case of an ICP hosted by a hosting provider or IDC, I suppose we are addressing the hosting provider, and we should say that. > > 2) Most of ICP consider end to end IPv4 together with outside in and inside > out; Yes, we are assuming they are already supporting e2e IPv4. > > 3) Load balance is still needed which is same as today IPv4 even there are > no more traffic for IPv6, Not if only 1% of the traffics is from IPv6. It's only when the traffic becomes large that you need load balancing. > for most ICP, they need to know the geo-location information during the > packet going through the load balance. Sure. The point is only that the quality of the geolocation lookup is alleged to be weaker for IPv6 today. Obviously this will improve. > > 4) ICP need to fully understand how to avoid DDOS when they launch the > IPv6, otherwise they will always need NAT solution Can you explain that please? Thanks Brian > > Regards, > > -Hui > > > 2012/2/23 Brian E Carpenter > >> Hi, >> >> This version has various updates due to comments from the WG. >> >> We are not asking for a meeting slot in Paris, but we'd like the >> chairs to put the question whether the WG wants to adopt this >> draft. In any case we still want more input to correct and >> expand the draft. >> >> Brian + Sheng >> >> -------- Original Message -------- >> Subject: I-D Action: draft-carpenter-v6ops-icp-guidance-03.txt >> Date: Wed, 22 Feb 2012 14:30:09 -0800 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> >> A New Internet-Draft is available from the on-line >> Internet-Drafts directories. >> >> Title : IPv6 Guidance for Internet Content and >> Application Service Providers >> Author(s) : Brian Carpenter >> Sheng Jiang >> Filename : draft-carpenter-v6ops-icp-guidance-03.txt >> Pages : 18 >> Date : 2012-02-22 >> >> This document provides guidance and suggestions for Internet >> Content >> Providers and Application Service Providers who wish to offer >> their >> service to both IPv6 and IPv4 customers. Many of the points will >> also apply to any enterprise network preparing for IPv6 users. >> >> >> A URL for this Internet-Draft is: >> >> http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance-03.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> >> ftp://ftp.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance-03.txt >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > From arturo.servin@gmail.com Sun Mar 11 12:19:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3D4D21F8694 for ; Sun, 11 Mar 2012 12:19:37 -0700 (PDT) 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 UWVKkHooNEhu for ; Sun, 11 Mar 2012 12:19:37 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 088D421F8603 for ; Sun, 11 Mar 2012 12:19:37 -0700 (PDT) Received: by dakl33 with SMTP id l33so4427980dak.31 for ; Sun, 11 Mar 2012 12:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=I4N96ppDCcnKH54toGIHzjwygL1lv8e2UDz4gAuo6ho=; b=GqdAcTgCi0KF7c7KH9pytm19kyzDB+ty3nDnsrYuoxvCu39BEb+RUT8/gf5Xessrpu ZBuCDIsrKEM/06mJH00jnbzoZiESKaz6nDx3HD4uvPuMSfaT4SMHTrXV/5KmW4UkrII4 QazA54eebjXbbrPHb9nXTL9uGAkuQ5Tb329MDs6/r0YnmMLXPvgB/wzXIU4+lRGLeu8A YqCq5TpCgRLaExB2DlIsltSP4kBKWPHR3XNMV9ekSm111saEhJhepEKx1xnhXzHSFHA1 HNc16XykxoxtDAwJJJ5LK5HZQc3UILVwyJ0i7YRnmPdeXirBQ2E6UUQIcg/zheoZ3x2t 6gfg== Received: by 10.68.130.233 with SMTP id oh9mr15479623pbb.92.1331493576875; Sun, 11 Mar 2012 12:19:36 -0700 (PDT) Received: from [10.196.232.181] ([199.91.194.1]) by mx.google.com with ESMTPS id 6sm5142759pbv.5.2012.03.11.12.19.34 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 11 Mar 2012 12:19:35 -0700 (PDT) References: <4F45B554.2060103@gmail.com> <4F5CF9B2.5070702@gmail.com> In-Reply-To: <4F5CF9B2.5070702@gmail.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: <841AC88C-3C04-4793-AEB9-59A66B8922DE@gmail.com> X-Mailer: iPad Mail (9A405) From: Arturo Servin Date: Sun, 11 Mar 2012 13:23:28 -0600 To: Brian E Carpenter Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action: draft-carpenter-v6ops-icp-guidance-03.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 19:19:37 -0000 Brian, Even 1% may need load balancing for high availability. IMHO. Regards, as > >> >> 3) Load balance is still needed which is same as today IPv4 even there are >> no more traffic for IPv6, > > Not if only 1% of the traffics is from IPv6. It's only when the traffic > becomes large that you need load balancing. > >> From joelja@bogus.com Sun Mar 11 12:23:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B06E21F8486 for ; Sun, 11 Mar 2012 12:23:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.909 X-Spam-Level: X-Spam-Status: No, score=-101.909 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 v-W6DbAkX6Wo for ; Sun, 11 Mar 2012 12:23:44 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id 74E7121F8483 for ; Sun, 11 Mar 2012 12:23:43 -0700 (PDT) Received: from Joels-MacBook-Pro.local (46.sub-166-250-35.myvzw.com [166.250.35.46]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q2BJNf3i025484 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sun, 11 Mar 2012 19:23:42 GMT (envelope-from joelja@bogus.com) Message-ID: <4F5CFBB8.9050502@bogus.com> Date: Sun, 11 Mar 2012 12:23:36 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Hui Deng References: <4F45B554.2060103@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sun, 11 Mar 2012 19:23:42 +0000 (UTC) Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action: draft-carpenter-v6ops-icp-guidance-03.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 19:23:45 -0000 On 3/11/12 08:35 , Hui Deng wrote: > 4) ICP need to fully understand how to avoid DDOS when they launch the > IPv6, otherwise they will always need NAT solution I'm mystified by this statement... network address translators that aren't stateless (much like firewalls) are a huge DOS bottleneck in a service that accepts unsolicited incoming connections. As far as I'm concerned they shouldn't be employeed unless they can be load-balanced. If they cause the loss of the original v6 source address along the way that's no good since I need that. > Regards, > > -Hui > > > 2012/2/23 Brian E Carpenter > > > Hi, > > This version has various updates due to comments from the WG. > > We are not asking for a meeting slot in Paris, but we'd like the > chairs to put the question whether the WG wants to adopt this > draft. In any case we still want more input to correct and > expand the draft. > > Brian + Sheng > > -------- Original Message -------- > Subject: I-D Action: draft-carpenter-v6ops-icp-guidance-03.txt > Date: Wed, 22 Feb 2012 14:30:09 -0800 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. > > Title : IPv6 Guidance for Internet Content and > Application Service Providers > Author(s) : Brian Carpenter > Sheng Jiang > Filename : draft-carpenter-v6ops-icp-guidance-03.txt > Pages : 18 > Date : 2012-02-22 > > This document provides guidance and suggestions for Internet > Content > Providers and Application Service Providers who wish to offer > their > service to both IPv6 and IPv4 customers. Many of the points will > also apply to any enterprise network preparing for IPv6 users. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance-03.txt > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft > > directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From brian.e.carpenter@gmail.com Sun Mar 11 12:39:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E752921F85F9 for ; Sun, 11 Mar 2012 12:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.489 X-Spam-Level: X-Spam-Status: No, score=-103.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 y+9IaUsReyFx for ; Sun, 11 Mar 2012 12:39:57 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA5D21F85DA for ; Sun, 11 Mar 2012 12:39:56 -0700 (PDT) Received: by eeke51 with SMTP id e51so871253eek.31 for ; Sun, 11 Mar 2012 12:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Y/TtOtygVcK2qqXgTBoxVSZdYbehbqZ4GPatn/9tj3U=; b=IpRVzB8c7BVh9Oh4rbrpAKjvFljWTy/Z2ttfVD/Aml70pq9DiGGU5WqVRY4Jz+ZrLh jUJTAfbCgmBKqHLk2KVQOESvKnOOJUlpib5Psl68to8rnqAG1AvlOsB5n4fese2WmrAk FiB+nOdx/BwnMc6XGTyOWB5T3nUR4QbD7ud5B5UQwJm/aJN+QoztY/QlPi6HWnAdJvAB D2BSKg5ZHWjmfMp/vyIQ1KXG0VwHCLaQu4EmmmXOLfxrtq7tUf6JXk+dJH9Ev1rf+p2l FwlndNGX3ACXldbCVqDeIRW2KlQ0jNgT9WfFfAfqLk+fsq6zQKiLfv/las79/dyCtJBo 9Jbg== Received: by 10.14.133.10 with SMTP id p10mr1484198eei.36.1331494796270; Sun, 11 Mar 2012 12:39:56 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id p57sm26380986eei.8.2012.03.11.12.39.52 (version=SSLv3 cipher=OTHER); Sun, 11 Mar 2012 12:39:55 -0700 (PDT) Message-ID: <4F5CFF81.1020108@gmail.com> Date: Mon, 12 Mar 2012 08:39:45 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Arturo Servin References: <4F45B554.2060103@gmail.com> <4F5CF9B2.5070702@gmail.com> <841AC88C-3C04-4793-AEB9-59A66B8922DE@gmail.com> In-Reply-To: <841AC88C-3C04-4793-AEB9-59A66B8922DE@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action: draft-carpenter-v6ops-icp-guidance-03.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 19:39:58 -0000 On 2012-03-12 08:23, Arturo Servin wrote: > Brian, > > Even 1% may need load balancing for high availability. IMHO. At least you need server redundancy, yes, good point. Brian > > Regards, > as > >>> 3) Load balance is still needed which is same as today IPv4 even there are >>> no more traffic for IPv6, >> Not if only 1% of the traffics is from IPv6. It's only when the traffic >> becomes large that you need load balancing. >> > From brian.e.carpenter@gmail.com Sun Mar 11 14:14:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE12921F8592 for ; Sun, 11 Mar 2012 14:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.19 X-Spam-Level: X-Spam-Status: No, score=-103.19 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, 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 uEEYs9ydsbWQ for ; Sun, 11 Mar 2012 14:14:15 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id F34C521F85A3 for ; Sun, 11 Mar 2012 14:14:14 -0700 (PDT) Received: by eeke51 with SMTP id e51so881582eek.31 for ; Sun, 11 Mar 2012 14:14:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=W7wEqQlQpKWIQ4lioFaPlVqSvJ6fRsNVe3FD/K2lExI=; b=CAHa1MQlvZvHQEZ8NQHDgOLcSTKA3yxoeBcbcKNBajoDXdIirXBE7/AcKqDXGPv4ZD fjn1O6Ivjr5I404XPSte5seE1WsGgPF69UnWRu9fGAfyJL5Uyq9CT4/5xiaClztnuTWA NuYF4Fw44xylhzpAw1viCM50NDu1coMlUKWqmdElqcbmGxUKJrsZcO7ElG4tE+Qhh9FP i5lOBVkfPP6mLOV5TME44C5AiMjIOicQ3PfOiLASCx+0mtqhLtkpV+YyW+LiUd2j/lUf fPNUzTUFmTgxs14/KXw+4Zk79Et3UdnoMsAu77XiBYysxaSCMJH6WZgB+5xs6Uegb8lj 0I9w== Received: by 10.213.15.144 with SMTP id k16mr818327eba.10.1331500454095; Sun, 11 Mar 2012 14:14:14 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id n55sm42471247eef.6.2012.03.11.14.14.09 (version=SSLv3 cipher=OTHER); Sun, 11 Mar 2012 14:14:13 -0700 (PDT) Message-ID: <4F5D159A.7060600@gmail.com> Date: Mon, 12 Mar 2012 10:14:02 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fred Baker References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> In-Reply-To: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 21:14:15 -0000 Hi, > 1. Introduction ... > The document also covers IP transition technologies. Two transition > technologies in 6rd [RFC5969] and DS-Lite [RFC6333] are covered in > the document. At the time of writing this document these were the > only two transition technologies available in RFC form to be included > in this document. The last sentence is untrue. There are many older transition technologies in RFC form. Rather than trying to find an accurate formulation, I suggest just dropping the sentence. Along the same grounds, there is no mention in the document of protocol 41. I realise that the draft is about IPv6, but should there be a note that when the CPE is supporting IPv6 traffic, then there is no requirement for it to allow protocol 41 in IPv4 traffic? (A stronger statement would be that protocol 41 MUST be blocked by default, but that seems out of scope for an IPv6 CPE document.) Brian On 2012-03-09 10:30, Fred Baker wrote: > This is to initiate a two week working group last call of draft-ietf-v6ops-6204bis. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list. The draft will be on the agenda at IETF 83, and I would like to send the authors home with a work plan to complete it if it is not to the WG's liking. > > We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From shemant@cisco.com Sun Mar 11 14:50:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C0121F85FF for ; Sun, 11 Mar 2012 14:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.824 X-Spam-Level: X-Spam-Status: No, score=-9.824 tagged_above=-999 required=5 tests=[AWL=0.774, 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 wqmm55o000Oz for ; Sun, 11 Mar 2012 14:49:59 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 424CB21F859A for ; Sun, 11 Mar 2012 14:49:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=7685; q=dns/txt; s=iport; t=1331502599; x=1332712199; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=R8fhwSmJ2P+qzJDWt7sUPDrw0zZccMt7SRYmxz59RyM=; b=A7uBXleZIXnBqvndkFuHTlFgxAvMmO1yVhEaNSg5X+9m4/M69N+iz919 qpq+NRbzXk/dUTJh4QwuZL/Tjm0OmJNRSKYeqmK8B3Purkt4WE2Y4x5tv mmIHpqxIhNxOgEUCzTKa3VgnYXeQbinqcZlHvRmO7A7ppJEMkB4Pcsphp U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADAdXU+tJXHB/2dsb2JhbABBglKzAIEHggkBAQEEEgEJEQNJDAQCAQgRBAEBCwYXAQYBRQkIAQEEARIIGodon3kBlgeQHmMEiFSdG4MB X-IronPort-AV: E=Sophos;i="4.73,568,1325462400"; d="scan'208,217";a="65505576" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 11 Mar 2012 21:49:59 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q2BLnwxS003854; Sun, 11 Mar 2012 21:49:58 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Mar 2012 16:49:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CCFFD0.E7453638" Date: Sun, 11 Mar 2012 16:49:57 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDF45@XMB-RCD-109.cisco.com> In-Reply-To: <4F5D159A.7060600@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6204bis WGLC Thread-Index: Acz/y/Dez+nr1EIvRgSEmE+6LiEW+AAA0nDA References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> <4F5D159A.7060600@gmail.com> From: "Hemant Singh (shemant)" To: "Brian E Carpenter" , "Fred Baker (fred)" X-OriginalArrivalTime: 11 Mar 2012 21:49:58.0844 (UTC) FILETIME=[E775CFC0:01CCFFD0] Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 21:50:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CCFFD0.E7453638 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Brian, =20 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Brian E Carpenter Sent: Sunday, March 11, 2012 5:14 PM To: Fred Baker (fred) Cc: v6ops@ietf.org; v6ops-chairs@tools.ietf.org; Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC =20 =20 >The last sentence is untrue. There are many older transition technologies >in RFC form. Rather than trying to find an accurate formulation, I >suggest just dropping the sentence. =20 The intent was to count only DS-Lite and 6rd since all other past transition tech before these two were generally phased out. However, your point is taken and the sentence can be dropped. There can be some disagreement as to which prior transition tech is phased out or not. =20 >Along the same grounds, there is no mention in the document of protocol 41. >I realise that the draft is about IPv6, but should there be a note that >when the CPE is supporting IPv6 traffic, then there is no requirement for >it to allow protocol 41 in IPv4 traffic? (A stronger statement would be >that protocol 41 MUST be blocked by default, but that seems out of scope >for an IPv6 CPE document.) =20 I think the document can be silent on protocol 41 since the document is already supportive of 6rd. Deciding any defaults for protocol 41 can be a protracted discussion as well. =20 Thanks for the review. =20 Regards, =20 Hemant ------_=_NextPart_001_01CCFFD0.E7453638 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Brian,

 

-----Original Message-----
From: = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = Brian E Carpenter
Sent: Sunday, March 11, 2012 5:14 PM
To: Fred = Baker (fred)
Cc: v6ops@ietf.org; v6ops-chairs@tools.ietf.org; Ron = Bonica
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis = WGLC

 

 

>The last sentence is untrue. = There are many older transition technologies

>in = RFC form. Rather than trying to find an accurate formulation, = I

>suggest just dropping the = sentence.

 

The intent was to count only DS-Lite and 6rd since all = other past transition tech before these two were generally phased out. =  However, your point is taken and the sentence can be dropped. =  There can be some disagreement as to which prior transition tech = is phased out or not.

 

>Along = the same grounds, there is no mention in the document of protocol = 41.

>I realise that the draft is = about IPv6, but should there be a note that

>when = the CPE is supporting IPv6 traffic, then there is no requirement = for

>it to allow protocol 41 in IPv4 = traffic? (A stronger statement would be

>that = protocol 41 MUST be blocked by default, but that seems out of = scope

>for an IPv6 CPE = document.)

 

I think = the document can be silent on protocol 41 since the document is already = supportive of 6rd.  Deciding any defaults for protocol 41 can be a = protracted discussion as well.

 

Thanks for the = review.

 

Regards,

 

Hemant

------_=_NextPart_001_01CCFFD0.E7453638-- From sgundave@cisco.com Sun Mar 11 20:45:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5B6221F8568 for ; Sun, 11 Mar 2012 20:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.775 X-Spam-Level: X-Spam-Status: No, score=-8.775 tagged_above=-999 required=5 tests=[AWL=1.124, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_BIZOP=0.7] 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 zGGfec+89bCz for ; Sun, 11 Mar 2012 20:45:44 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id F199621F8557 for ; Sun, 11 Mar 2012 20:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=1822; q=dns/txt; s=iport; t=1331523941; x=1332733541; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=l3TFKQmzpsxue6MnQI0tfZjhTUI3nPOVkAnZuZJ+c9c=; b=myj2kAvciieok8HxuInaqmt0Kfaf2cHHi4TbcuktWUK1rUisMhki/Qzi tlOyfu91luuMuzfel5QgblcxP0qhP7GRnhldf7xGO8zcFD1OQ4ZieeYHs ixlGIJWVvdCxDwNitEh/+c4Njvr/6Tw4ScSWpcEBJyPqTYdwYrhuVeSOZ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANtwXU+rRDoH/2dsb2JhbABCtUyBB4IJAQEBBBIBJwIBOhQBCBEDAQJ8AQEFAwEBBBMJCw6HZwELmjmBJwGdfo1fgyIEiFSMeJAjgwQ X-IronPort-AV: E=Sophos;i="4.73,568,1325462400"; d="scan'208";a="35549817" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 12 Mar 2012 03:45:40 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2C3jePq012412 for ; Mon, 12 Mar 2012 03:45:40 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 11 Mar 2012 20:45:40 -0700 Received: from 10.32.246.211 ([10.32.246.211]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Mon, 12 Mar 2012 03:45:40 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Sun, 11 Mar 2012 20:45:39 -0800 From: Sri Gundavelli To: Message-ID: Thread-Topic: New Version Notification for draft-gundavelli-v6ops-community-wifi-svcs-03.txt Thread-Index: Ac0AApcviZFmafn0LEi6j6/ougEEyA== In-Reply-To: <20120312031433.18188.71888.idtracker@ietfa.amsl.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 12 Mar 2012 03:45:40.0696 (UTC) FILETIME=[9831FD80:01CD0002] Subject: [v6ops] FW: New Version Notification for draft-gundavelli-v6ops-community-wifi-svcs-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 03:45:44 -0000 Comments appreciated. http://www.ietf.org/id/draft-gundavelli-v6ops-community-wifi-svcs-03.txt Sri ------ Forwarded Message From: Date: Sun, 11 Mar 2012 20:14:33 -0700 To: Cc: , , Subject: New Version Notification for draft-gundavelli-v6ops-community-wifi-svcs-03.txt A new version of I-D, draft-gundavelli-v6ops-community-wifi-svcs-03.txt has been successfully submitted by Sri Gundavelli and posted to the IETF repository. Filename: draft-gundavelli-v6ops-community-wifi-svcs Revision: 03 Title: Service Provider Wi-Fi Services Over Residential Architectures Creation date: 2012-03-11 WG ID: Individual Submission Number of pages: 17 Abstract: The tremendous growth in Wi-Fi technology adoption over the last decade has met the ultimate possible goal of 100% adoption rate. All most every new mobile device is now equipped with IEEE 802.11-based wireless interface and with pre-configured policy to prefer Wi-Fi to cellular access. Matching this evolution is every service provider's desire to offer Wi-Fi based broadband services; a new business opportunity even for fixed line operators. Operators are exploring options to monetize their existing networks, most with nation-wide footprint, to build a high-speed Wi-Fi service that can be the basis for offering new wireless broadband services. This document identifies the requirements for supporting these new Wi-Fi community services and the mobility tools which have been standardized in IETF that can be used for enabling these architectures. The IETF Secretariat ------ End of Forwarded Message From denghui02@gmail.com Sun Mar 11 21:00:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C693921F852A for ; Sun, 11 Mar 2012 21:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.003 X-Spam-Level: X-Spam-Status: No, score=-103.003 tagged_above=-999 required=5 tests=[AWL=-0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, 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 DWRlP03LG2Jg for ; Sun, 11 Mar 2012 21:00:32 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id BAFAE21F8528 for ; Sun, 11 Mar 2012 21:00:32 -0700 (PDT) Received: by ggmi1 with SMTP id i1so2432037ggm.31 for ; Sun, 11 Mar 2012 21:00:32 -0700 (PDT) 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=zv2OXwz5uJeebLZ4o8ves9z1CfauNO6VcgM80ZrPn8c=; b=nmPSuYQkfzlRbG++AJGAdzHyxBwGEa5fh7t2gVU24hme86Mn+r0v4Ncc9oNOflSAOl AXRT551tYNnWTLJy0Pc7ISfOkcwEcKVedMlP4WxDBGyIiMUclUOyb3yJwpkuQ7lFEuWh DldW6IQCcC6CKfN6PGDhM/q07HlaW0HjNiRF9sV1vggulGmPNGZXyQSJIbgA1CcvdC0s zowUwPEvDX2CTDunkq8U5uEODgEYMtxgwRTdpEUg7WmDEo4R/2SHIm55sxteHzETqSRb rspGr8L5lrTnY7YSIPDPQp+Gp4eQJTul8oLT6lvGcb088C38u4/aQvA5SGXTJ58i8O44 KY1g== MIME-Version: 1.0 Received: by 10.100.254.2 with SMTP id b2mr3652215ani.18.1331524832258; Sun, 11 Mar 2012 21:00:32 -0700 (PDT) Received: by 10.147.123.12 with HTTP; Sun, 11 Mar 2012 21:00:32 -0700 (PDT) In-Reply-To: <4F5CF9B2.5070702@gmail.com> References: <4F45B554.2060103@gmail.com> <4F5CF9B2.5070702@gmail.com> Date: Mon, 12 Mar 2012 12:00:32 +0800 Message-ID: From: Hui Deng To: Brian E Carpenter Content-Type: multipart/alternative; boundary=0016369fa371a2ec0d04bb03c8b3 Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action: draft-carpenter-v6ops-icp-guidance-03.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 04:00:33 -0000 --0016369fa371a2ec0d04bb03c8b3 Content-Type: text/plain; charset=ISO-8859-1 inline please, 2012/3/12 Brian E Carpenter > Hi Deng, > > On 2012-03-12 04:35, Hui Deng wrote: > > Hi Authors, > > > > I have several comments about this draft: > > 1) do you want to classify different level of ICP, from the reading, this > > document is targetting at > > the ICP who are not faimliar with IPv6, but sometimes, ICP may deploy > their > > server in some IDC or some may > > be based on their own location, which may have different consideration; > > I think that our main target is an ICP that is mainly familiar with IPv4. > In the case of an ICP hosted by a hosting provider or IDC, I suppose we > are addressing the hosting provider, and we should say that. > > > > > 2) Most of ICP consider end to end IPv4 together with outside in and > inside > > out; > > Yes, we are assuming they are already supporting e2e IPv4. > > > > > > 3) Load balance is still needed which is same as today IPv4 even there > are > > no more traffic for IPv6, > > Not if only 1% of the traffics is from IPv6. It's only when the traffic > becomes large that you need load balancing. > loading balancing is sitting together with DDOS prevention and many other features, even 1%, they still need it. > > > for most ICP, they need to know the geo-location information during the > > packet going through the load balance. > > Sure. The point is only that the quality of the geolocation lookup > is alleged to be weaker for IPv6 today. Obviously this will improve. > this information is bundled with many other ICP services, this have to be considered anyway by them. > > > > > 4) ICP need to fully understand how to avoid DDOS when they launch the > > IPv6, otherwise they will always need NAT solution > > Can you explain that please? > this expecting that this document could explain how to avoid DDOS in detail, otherwise, they have to deploy special NAT to handle this by configure some policy over there. -Hui > > Thanks > > Brian > > > > Regards, > > > > -Hui > > > > > > 2012/2/23 Brian E Carpenter > > > >> Hi, > >> > >> This version has various updates due to comments from the WG. > >> > >> We are not asking for a meeting slot in Paris, but we'd like the > >> chairs to put the question whether the WG wants to adopt this > >> draft. In any case we still want more input to correct and > >> expand the draft. > >> > >> Brian + Sheng > >> > >> -------- Original Message -------- > >> Subject: I-D Action: draft-carpenter-v6ops-icp-guidance-03.txt > >> Date: Wed, 22 Feb 2012 14:30:09 -0800 > >> From: internet-drafts@ietf.org > >> Reply-To: internet-drafts@ietf.org > >> To: i-d-announce@ietf.org > >> > >> > >> A New Internet-Draft is available from the on-line > >> Internet-Drafts directories. > >> > >> Title : IPv6 Guidance for Internet Content and > >> Application Service Providers > >> Author(s) : Brian Carpenter > >> Sheng Jiang > >> Filename : draft-carpenter-v6ops-icp-guidance-03.txt > >> Pages : 18 > >> Date : 2012-02-22 > >> > >> This document provides guidance and suggestions for Internet > >> Content > >> Providers and Application Service Providers who wish to offer > >> their > >> service to both IPv6 and IPv4 customers. Many of the points will > >> also apply to any enterprise network preparing for IPv6 users. > >> > >> > >> A URL for this Internet-Draft is: > >> > >> > http://www.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance-03.txt > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> This Internet-Draft can be retrieved at: > >> > >> > ftp://ftp.ietf.org/internet-drafts/draft-carpenter-v6ops-icp-guidance-03.txt > >> > >> _______________________________________________ > >> I-D-Announce mailing list > >> I-D-Announce@ietf.org > >> https://www.ietf.org/mailman/listinfo/i-d-announce > >> Internet-Draft directories: http://www.ietf.org/shadow.html > >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > >> > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >> > > > --0016369fa371a2ec0d04bb03c8b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable inline please,

2012/3/12 Brian E Carpenter &l= t;brian.e.carpenter@gmail.co= m>
Hi Deng,

On 2012-03-12 04:35, Hui Deng wrote:
> Hi Autho= rs,
>
> I have several comments about this draft:
> 1) do= you want to classify different level of ICP, from the reading, this
> document is targetting at
> the ICP who are not faimliar with IP= v6, but sometimes, ICP may deploy their
> server in some IDC or some = may
> be based on their own location, which may have different consid= eration;

I think that our main target is an ICP that is mainly familiar wi= th IPv4.
In the case of an ICP hosted by a hosting provider or IDC, I su= ppose we
are addressing the hosting provider, and we should say that.

>
> 2) Most of ICP consider end to end IPv4 = together with outside in and inside
> out;

Yes, we are a= ssuming they are already supporting e2e IPv4.

=A0
>
> 3) Load balance is still needed which is sam= e as today IPv4 even there are
> no more traffic for IPv6,

Not if only 1% of the traffics is from IPv6. It's only when the traf= fic
becomes large that you need load balancing.
loading balancing is sitting together with DDOS prevention and many ot= her features, even 1%, they still need it.
=A0

> for most ICP, they need to know the geo-location= information during the
> packet going through the load balance.
<= br>
Sure. The point is only that the quality of the geolocation lookup=
is alleged to be weaker for IPv6 today. Obviously this will improve.
this information is bundled with many other ICP services, this have to= be considered anyway by them.
=A0

>
> 4) ICP need to fully understand how to a= void DDOS when they launch the
> IPv6, otherwise they will always nee= d NAT solution

Can you explain that please?
this expecting that this document could explain how to avoid DDOS in d= etail, otherwise, they have to deploy special NAT to handle this by configu= re some policy over there.
=A0
-Hui
=A0
=A0

Thanks
=
=A0 =A0Brian
>
> Regards,
>
> -Hui
>
>= ;
> 2012/2/23 Brian E Carpenter <brian.e.carpenter@gmail.com>
>
>> Hi, >>
>> This version has various updates due to comments from = the WG.
>>
>> We are not asking for a meeting slot in Par= is, but we'd like the
>> chairs to put the question whether th= e WG wants to adopt this
>> draft. In any case we still want more input to correct and
>= > expand the draft.
>>
>> =A0 =A0Brian + Sheng
>= >
>> -------- Original Message --------
>> Subject: I-= D Action: draft-carpenter-v6ops-icp-guidance-03.txt
>> Date: Wed, 22 Feb 2012 14:30:09 -0800
>> From: internet-drafts@ietf.org
>> = Reply-To: internet-drafts@ietf.= org
>> To: i-d-announce@ietf.org=
>>
>>
>> A New Internet-Draft is available = from the on-line
>> Internet-Drafts directories.
>>
>> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : IPv6 Guidance for Inter= net Content and
>> Application Service Providers
>> =A0 = =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Brian Carpenter
>> =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Sheng Jiang
>> =A0 =A0 =A0 = =A0Filename =A0 =A0 =A0 =A0: draft-carpenter-v6ops-icp-guidance-03.txt
>> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 18
>> =A0 =A0 = =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-02-22
>>
>> =A0= This document provides guidance and suggestions for Internet
>> C= ontent
>> =A0 Providers and Application Service Providers who wish= to offer
>> their
>> =A0 service to both IPv6 and IPv4 customers. =A0= Many of the points will
>> =A0 also apply to any enterprise networ= k preparing for IPv6 users.
>>
>>
>> A URL for t= his Internet-Draft is:
>>
>> http://www.ietf.org/i= nternet-drafts/draft-carpenter-v6ops-icp-guidance-03.txt
>> >> Internet-Drafts are also available by anonymous FTP at:
>>= ; ftp://f= tp.ietf.org/internet-drafts/
>>
>> This Internet-Draf= t can be retrieved at:
>>
>> ftp://ftp.ietf.org/int= ernet-drafts/draft-carpenter-v6ops-icp-guidance-03.txt
>>
&= gt;> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.o= rg/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or = ftp= ://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>
>> __________________________________________= _____
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo= /v6ops
>>
>

--0016369fa371a2ec0d04bb03c8b3-- From denghui02@gmail.com Sun Mar 11 21:02:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0169F21F859A for ; Sun, 11 Mar 2012 21:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.303 X-Spam-Level: X-Spam-Status: No, score=-103.303 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 yK04fLe+dM+6 for ; Sun, 11 Mar 2012 21:02:52 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEC921F852B for ; Sun, 11 Mar 2012 21:02:52 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2418403ghb.31 for ; Sun, 11 Mar 2012 21:02:52 -0700 (PDT) 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=l1xeITD3wBY0/Bbqhi8881ACs91FheKQ6Z29tAF/nGY=; b=zedmn24C/RTQku1TjV7VgjuPuIm1eV5zP18bxHe+4xchcTpxl1i6a94iU608kRloN/ tNl5D2V0c4+5R3kkxZKD6ZM1kKcbxm+xdOQGleKnbbloITr10ArDQaJd1jmvVQTT6iv9 TkS/t5Exp6fEviuWtl7bnhc7ZtTsZCFWBOHRma6wC9WhyisxRt5X4H5IAssfo+par1zT U0yESoA2szXL82r23hB29+KUc+jopHWCYtV7g+WfXJ09+uAo/3P7kgsH20fRkzF6fqP6 8I3mbeLXQEuD08VwQT1HuEvczvtns+t2iumw2HRaLo1GNsAs1JQz8yE8UKGKU1iJwtam D8uQ== MIME-Version: 1.0 Received: by 10.236.197.74 with SMTP id s50mr11423850yhn.127.1331524971942; Sun, 11 Mar 2012 21:02:51 -0700 (PDT) Received: by 10.147.123.12 with HTTP; Sun, 11 Mar 2012 21:02:51 -0700 (PDT) In-Reply-To: <4F5CFBB8.9050502@bogus.com> References: <4F45B554.2060103@gmail.com> <4F5CFBB8.9050502@bogus.com> Date: Mon, 12 Mar 2012 12:02:51 +0800 Message-ID: From: Hui Deng To: Joel jaeggli Content-Type: multipart/alternative; boundary=20cf3040e37af6544704bb03d01f Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action: draft-carpenter-v6ops-icp-guidance-03.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 04:02:53 -0000 --20cf3040e37af6544704bb03d01f Content-Type: text/plain; charset=ISO-8859-1 2012/3/12 Joel jaeggli > On 3/11/12 08:35 , Hui Deng wrote: > > 4) ICP need to fully understand how to avoid DDOS when they launch the > > IPv6, otherwise they will always need NAT solution > > I'm mystified by this statement... network address translators that > aren't stateless (much like firewalls) are a huge DOS bottleneck in a > service that accepts unsolicited incoming connections. As far as I'm > concerned they shouldn't be employeed unless they can be load-balanced. > > If they cause the loss of the original v6 source address along the way > that's no good since I need that. > you are right, NAT is stateful as well, but by configuring some policy on the NAT, then such kind of DOS could be avoided, which save those servers sitting behind. -Hui --20cf3040e37af6544704bb03d01f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/3/12 Joel jaeggli <joelja@bogus.com>
On 3/11/12 08:35 , Hui Deng wrote:
> 4) ICP need to= fully understand how to avoid DDOS when they launch the
> IPv6, othe= rwise they will always need NAT solution

I'm mystified by = this statement... network address translators that
aren't stateless =A0(much like firewalls) are a huge DOS bottleneck in = a
service that accepts unsolicited incoming connections. As far as I'= ;m
concerned they shouldn't be employeed unless they can be load-bal= anced.

If they cause the loss of the original v6 source address along the way<= br>that's no good since I need that.
you are right, NAT is stateful as well, but by configuring some policy= on the NAT, then
such kind of DOS could be avoided, which save=A0those servers sitting = behind.
=A0
-Hui
=A0
--20cf3040e37af6544704bb03d01f-- From Carl.Wuyts@technicolor.com Mon Mar 12 00:39:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06EFB21F84F9 for ; Mon, 12 Mar 2012 00:39:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.808 X-Spam-Level: X-Spam-Status: No, score=-5.808 tagged_above=-999 required=5 tests=[AWL=-0.409, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_64=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 hAehbhOFB3C4 for ; Mon, 12 Mar 2012 00:39:01 -0700 (PDT) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9B121F8548 for ; Mon, 12 Mar 2012 00:38:32 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKT12n9ytXE7mG1L7sjvCgMdnjYQdEkga8@postini.com; Mon, 12 Mar 2012 00:39:01 PDT Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 12 Mar 2012 08:38:20 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Mon, 12 Mar 2012 08:38:25 +0100 From: Wuyts Carl To: Daniel Roesen , "Hemant Singh (shemant)" Date: Mon, 12 Mar 2012 08:38:24 +0100 Thread-Topic: [v6ops] draft-ietf-v6ops-6204bis WGLC Thread-Index: Acz+rh0rhZpvISTIQDqXzSd4WaRvvQBc99fg Message-ID: <867F4B6A1672E541A94676D556793ACD0EB990CE2C@MOPESMBX01.eu.thmulti.com> References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> <20120309214138.GA1736@srv03.cluenet.de> <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDEA9@XMB-RCD-109.cisco.com> <20120309230646.GA19015@srv03.cluenet.de> <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDEE9@XMB-RCD-109.cisco.com> <20120310110801.GA28234@srv03.cluenet.de> In-Reply-To: <20120310110801.GA28234@srv03.cluenet.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 07:39:02 -0000 Well, I agree/confirm that it's a system wide decision, not per IP interfac= e or whatever, but I don't really see an issue with it. Maybe just a view = on how it works on our CPEs, not sure how it is on others of course.=20 Our DNS proxy can get its DNS Servers through static or dynamic configurati= on (PPP, DHCPv4/v6 ,...), so it can basically come from any "home" over any= "IP interface". On top, some configuration can be done to match certain c= riteria to prefer a certain DNS server to be selected for a specific query = from the LAN segments. When this is done, the packet is being handed over = to the router, and this one will make the routing decision. So indeed it i= s possible that DNS requests are being sent over another/"wrong" interface = (than expected), but I'd say this is just configuration. I mean, I can put= some blackhole/null route in and make it go wrong too.... just FYI. We w= ork in a system with managed CPEs, so less vulnarable to thses kind of thin= gs I guess, but I don't agree that the CPE "doesn't know", it's a matter of= proper configuration. Situation might be different for retail I guess, a= s less control present, but still, it must be possible to put some configur= ation on it somehow, as it must be told what setup to serve anyway. I also think this is not different from the past. In a v4-only world, you = can hit the same issue today, without RFc6204 presence, no ? Regs Carl -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of D= aniel Roesen Sent: zaterdag 10 maart 2012 12:08 To: Hemant Singh (shemant) Cc: v6ops@ietf.org; v6ops-chairs@tools.ietf.org Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC On Fri, Mar 09, 2012 at 06:20:58PM -0600, Hemant Singh (shemant) wrote: > For what it's worth, each DHCPv6 reply is associated with a specific > DHCPv6 client-id and server-id. Thus each client updates specific=20 > information for options received. I suppose each ipv6 address in the=20 > multihomed situation has its own DNS to go to etc., so conflicting=20 > information does not matter. DNS resolving is a system-wide matter, not a per-interface/IP matter. If a system wants to talk to random.fqdn, it resolves that FQDN via whateve= r DNS recursors available to it, and then looks up the egress interface (an= d thus source IP) to be used for connecting to that remote system. How coul= d you know which interface-specific recursor you'll use before knowing whic= h across which interface you're going to you to reach the remote system? It= 's a catch 22. Real world example: CE gets Internet uplink via PPPoE on one VLAN, and IPTV= uplink via DHCP via another VLAN. From both connections, a conflicting set= of DNS recursors are being obtained. Which set is the one to use to forwar= d proxied requests from LAN clients to? LAN contains "Internet" clients as = well as IPTV STBs - indistinguishable by the CE. Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0 ________= _______________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From rick@openfortress.nl Mon Mar 12 01:16:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B006821F84F7 for ; Mon, 12 Mar 2012 01:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.443 X-Spam-Level: X-Spam-Status: No, score=-0.443 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_EQ_NL=1.545] 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 y9RkJ3Ip++jw for ; Mon, 12 Mar 2012 01:16:25 -0700 (PDT) Received: from fame.vanrein.org (openfortress.nl [213.189.19.244]) by ietfa.amsl.com (Postfix) with ESMTP id E527221F85B5 for ; Mon, 12 Mar 2012 01:16:24 -0700 (PDT) Received: from phantom.vanrein.org (phantom.vanrein.org [83.163.207.110]) by fame.vanrein.org (Postfix) with ESMTP id DA3974040D1 for ; Mon, 12 Mar 2012 08:16:21 +0000 (GMT) Received: by phantom.vanrein.org (Postfix, from userid 1000) id 8F6AE22634; Mon, 12 Mar 2012 09:21:02 +0100 (CET) Date: Mon, 12 Mar 2012 08:21:02 +0000 From: Rick van Rein To: v6ops@ietf.org Message-ID: <20120312082102.GB29228@newphantom.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-My-Coolest-Hack: http://rick.vanrein.org/linux/badram -> Exploit broken RAM Fcc: =ofo User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [v6ops] Fwd: New Version Notification for draft-vanrein-v6ops-6bed4-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 08:16:25 -0000 Hello, I've updated my I-D for the 6bed4 tunnel. Please comment; I would like to present it in Paris if it meets appreciation. https://datatracker.ietf.org/doc/draft-vanrein-v6ops-6bed4/ The focus is on getting peer-to-peer working with IPv6, even on IPv6-only. To be able to rely on that, a remote peer must be trusted to run IPv6, so a simple tunnel that works in any environment, even as an add-on to an application such as a SIP phone, chat tool, ... None of the current tunnels has been able to meet those criteria. Pointwise summary of the protocol: * tunnel packs IPv6 into UDP/IPv4, works behind any NAT/firewall sequence * obtain an IPv6 address through Router Sol / Router Adv * incorporate external IPv4 address and UDP port into the IPv6 address * validate packet sender's IPv6 address with the originating UDP/IPv4 * try direct routes to peers' UDP/IPv4 through Neighbor Sol / Neighbor Adv * optionally lookup same-LAN peers through multicast to 224.0.0.1 + UDP port * use Redirect to ensure symmetric routes at the lowest cost metric found * router finding mechanisms are not specified; use config, DNS, anycast, ... Thank you all for the feedback on v00, it has really helped me grow a better protocol. Cheers, Rick van Rein OpenFortress ----- Forwarded message from internet-drafts@ietf.org ----- Date: Sun, 11 Mar 2012 14:24:48 -0700 From: internet-drafts@ietf.org To: rick@openfortress.nl Subject: New Version Notification for draft-vanrein-v6ops-6bed4-01.txt A new version of I-D, draft-vanrein-v6ops-6bed4-01.txt has been successfully submitted by Rick van Rein and posted to the IETF repository. Filename: draft-vanrein-v6ops-6bed4 Revision: 01 Title: 6bed4: Peer-to-Peer IPv6 on Any Internetwork Creation date: 2012-03-11 WG ID: Individual Submission Number of pages: 26 Abstract: The intention of 6bed4 is to support IPv6-only applications, even on IPv4-only networks. A specific area of concern is that of peer-to- peer protocols such as SIP or document exchange during a chat session. Such protocols are designed to run in any environment, which means that they cannot rely on IPv6 for themselves, or their peers. The 6bed4 tunnel mechanism ensures that IPv6 can be assumed on all peers, without a need to configure it explicitly. The 6bed4 mechanism is meant as a fallback mechanism for IPv6 connectivity on networks that do not support it natively, by running a tunnel over UDP and IPv4. The IPv4 address is used to support traceability of the traffic originator, which means that no user account or other configuration is needed. The tunnel mechanism builds on existing IPv6 mechanisms; it employs Stateless Address Autoconfiguration [RFC4862] to setup an IPv6 address on a 6bed4 Peer, and Neighbor Discovery [RFC4861] to find the most direct route to a remote 6bed4 Peer. The IETF Secretariat ----- End forwarded message ----- From shtsuchi@cisco.com Mon Mar 12 10:31:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35A5421F8924; Mon, 12 Mar 2012 10:31:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.899 X-Spam-Level: X-Spam-Status: No, score=-3.899 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_26=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_84=0.6, 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 4O-NTgwcUfTe; Mon, 12 Mar 2012 10:31:45 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8C821F891D; Mon, 12 Mar 2012 10:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shtsuchi@cisco.com; l=4803; q=dns/txt; s=iport; t=1331573505; x=1332783105; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=XtnXJw8fKYgm1f8SQYVNshK1tAbAo8x/3LVmwOJkZSY=; b=HJfxkMyQCSUviGXLb7ZNUuoo00fCQFkXmmu0jfMmxFeNvH9FCc186Q6W NsqWtiJAVkkw1hanazMQHe2v3ID1wsdyyuFC5Ewg7CvqdAN0dt9xJ361j +9RC6/+weOcFCJh3Q3Kd12NVhHLUDbAVXNZQPtDKpj2tKSgKhHSD6F9Ah s=; X-IronPort-AV: E=Sophos;i="4.73,572,1325462400"; d="scan'208";a="7702899" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 12 Mar 2012 17:31:43 +0000 Received: from [10.71.44.89] (tky-shtsuchi-8918.cisco.com [10.71.44.89]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2CHVVnU032266; Mon, 12 Mar 2012 17:31:32 GMT Message-ID: <4F5E32F2.50302@cisco.com> Date: Tue, 13 Mar 2012 02:31:30 +0900 From: Shishio Tsuchiya User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: <20111114092126.3494.19513.idtracker@ietfa.amsl.com><4F320549.20100@cisco.com> <4F34A0AD.4040300@cisco.com> In-Reply-To: <4F34A0AD.4040300@cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: softwires@ietf.org, draft-sakura-6rd-datacenter@tools.ietf.org, armd@ietf.org Subject: Re: [v6ops] [armd] Fwd: I-D Action: draft-sakura-6rd-datacenter-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 17:31:50 -0000 v6ops I published 04,add some comments. 4.2. Configuration 4.4. Traffic Pattern http://tools.ietf.org/html/draft-sakura-6rd-datacenter-04 I believe native IPv6 data center is ideal,but the operators sometimes can not reach the ideal. Server based 6rd would be useful to provide IPv6 to customer as solution. Could you share presentation time slot in IETF83? Regards, -Shishio (2012/02/10 13:44), Shishio Tsuchiya wrote: > Linda > Thanks for comments. > > (2012/02/10 8:26), Linda Dunbar wrote: >> Shishio, >> >> Thank you very much for sharing the v6 deployment in data center. >> >> I am not an IPv6 expert. So I have a simple question: when you say "server-based 6rd", do you mean that server does the IPv4 encapsulation? > > Yes. > 6rd is IPv6 over IPv4 tunnel technology. > So backbone operator does not need to care to IPv6 on the core. > Additionally 6rd has stateless feature. > Once the operator has placed/configured 6rd BR on the exit point to the IPv6 internet,does not need additional operation to add 6rd CE(server based 6rd). > And if the server would like to go to the IPv6 internet,then IPv4 packets will through 6rd BR and de-capsulate. > If the server would like to communicate other 6rd server within the data center,then IPv4 packets will reach 6rd server directly and de-capsulate. > >> >> >> Does your data center allow hosts/servers under one IPv6 subnet (e.g. /64) to be placed under different server racks? > > In Sakura internet 6rd cases,each of 6rd server has one 6rd delegate prefix(/64). > http://tools.ietf.org/html/draft-sakura-6rd-datacenter-03#section-4.1 > > The 6rd delegate prefix calculates from Sakura's IPv6 prefix(/32) and IPv4 address. > Sakura has the scalability problem which is same as ARMD draft. > http://tools.ietf.org/html/draft-ietf-armd-problem-statement-00 > > They also had to update switches to resolve security issue(Rogue RA). > http://tools.ietf.org/html/rfc6104 > > They selected "server-based 6rd" as the solution to avoid scalability and security problem. > > Regards, > -Shishio > > >> >> Thanks, Linda Dunbar >> >> >> >> >> >> On Tue, Feb 7, 2012 at 11:16 PM, Shishio Tsuchiya> wrote: >> >> v6ops and ARMD >> Sakura internet are providing IPv6 service without scalability impact to core network equipment to customer using 6rd. >> We thought this is interesting idea,so published the draft. >> >> http://tools.ietf.org/html/draft-sakura-6rd-datacenter-03 >> >> I think both of mailing list participants are also interesting in this technique. >> If you have any comment and question of the draft,please let me know. >> >> Regards, >> -Shishio >> -------- Original Message -------- >> Subject: I-D Action: draft-sakura-6rd-datacenter-03.txt >> Date: Mon, 14 Nov 2011 17:21:26 +0800 >> From:> >> Reply-To:> >> To:> >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> Title : IPv6 Rapid Deployment (6rd) in a Large Data Center >> Author(s) : Shishio Tsuchiya >> Mark Townsley >> Shuichi Ohkubo >> Filename : draft-sakura-6rd-datacenter-03.txt >> Pages : 15 >> Date : 2011-11-14 >> >> IPv6 Rapid Deployment (6rd) as defined in RFC 5969 focuses on rapid >> deployment of IPv6 by an access service provider which has difficulty >> deploying native IPv6. This document describes how 6rd can be used >> to deliver IPv6 within a Large Data Center. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-sakura-6rd-datacenter-03.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-sakura-6rd-datacenter-03.txt >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> >> >> _______________________________________________ >> armd mailing list >> armd@ietf.org >> https://www.ietf.org/mailman/listinfo/armd >> >> > > From Francis.Dupont@fdupont.fr Mon Mar 12 13:13:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8086721F8984 for ; Mon, 12 Mar 2012 13:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=-0.122, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] 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 5Mm02AuaZ4KI for ; Mon, 12 Mar 2012 13:13:20 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id C6BB421F8976 for ; Mon, 12 Mar 2012 13:13:19 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2CKD9Ib010733; Mon, 12 Mar 2012 21:13:09 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203122013.q2CKD9Ib010733@givry.fdupont.fr> From: Francis Dupont To: =?iso-8859-1?Q?Ole_Tr=F8an?= In-reply-to: Your message of Fri, 09 Mar 2012 12:50:37 +0100. <9B1C4EC1-50ED-436F-876A-1F2512BB54C9@employees.org> Date: Mon, 12 Mar 2012 21:13:09 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "v6ops@ietf.org WG" , "v6ops-chairs@tools.ietf.org Chairs" , Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 20:13:20 -0000 In your previous mail you wrote: > 2. PCP text is incomplete. As specified PCP support in the document > is incomplete. => I have a concern about the PCP text too (W-6 and/or change 12): I believed we agreed to ask only for the functionality, not to specify one of the protocols which provides it (even it is the only designed by the IETF... did you say NIH? :-) > If this has been added for DS-lite support draft-dupont-pcp-dslite-01 > should be referenced. => I agree: if you have both PCP and DS-lite in the same document you have to cite both the base spec and the environment application I-Ds. > Currently the requirement is not testable. E.g. > it doesn't even specify which PCP server the client should use. => hum, perhaps we should add the PCP server discovery document (when it will be available) too? > In my opinion it also need to specify PCP/proxy LAN side behavior. > (or reference a homenet document if one existed) => it looks like a good idea but unconstrainted PCP/proxy raises a security issue so IMHO we should keep this out of the scope of the document. And also on the LAN side you have other protocols which are already heavily used. > Suggestion: Get thorough review in PCP and HOMENET. Incorporate LAN > side requirements. => this is a more generic issue. I think the other transition mechanims are the same, so the idea to jump to 6204ter is not bad... Regards Francis.Dupont@fdupont.fr From brian.e.carpenter@gmail.com Mon Mar 12 13:14:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C9021F89A0 for ; Mon, 12 Mar 2012 13:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.432 X-Spam-Level: X-Spam-Status: No, score=-103.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 A-UDT7k3u5kU for ; Mon, 12 Mar 2012 13:14:37 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 559BF21F871D for ; Mon, 12 Mar 2012 13:14:36 -0700 (PDT) Received: by ggmi1 with SMTP id i1so3429378ggm.31 for ; Mon, 12 Mar 2012 13:14:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=qtzqlbI5fAS1pu0ai6XxY6sp9Png9A4/k6Q7zDvOKZ8=; b=K/6axYaFsouwiw11va5sUoYtNEpWC7izHneSpmexFvFIbcQ56K8VCEeogLWEZPDvfH xKJ82MZrhgw5iOyLRqEsvRsooZ1ZoZ+fohWkafBkCteY1Zu7p9aFhnDdfY2HSi0Hk0f3 nh+1v5bAO22BoqgTOQpl+NcwcrNncItoi3LXeBGVRWPZ0heEAVNkN+W9i3pBCYVnKKDe VuRoTJWZRKk20lgqNsAMugvViOyrR6kBAKqq/eCtOIMecPqPSPU6DSamLz7HV/uoy9D9 bfJ1/X66cqf5aobbywlghczWEy1BylnPnIP43/aR6CF/3AkRGbM9xl8VO7oR3U9MPnHB 7VgA== Received: by 10.182.48.36 with SMTP id i4mr8886601obn.72.1331583275255; Mon, 12 Mar 2012 13:14:35 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id h9sm22083859obr.20.2012.03.12.13.14.33 (version=SSLv3 cipher=OTHER); Mon, 12 Mar 2012 13:14:34 -0700 (PDT) Message-ID: <4F5E5922.4050501@gmail.com> Date: Tue, 13 Mar 2012 09:14:26 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Hui Deng References: <4F45B554.2060103@gmail.com> <4F5CF9B2.5070702@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action: draft-carpenter-v6ops-icp-guidance-03.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 20:14:38 -0000 Hi, On 2012-03-12 17:00, Hui Deng wrote: ... >>> 4) ICP need to fully understand how to avoid DDOS when they launch the >>> IPv6, otherwise they will always need NAT solution >> Can you explain that please? >> > this expecting that this document could explain how to avoid DDOS in > detail, otherwise, they have to deploy special NAT to handle this by > configure some policy over there. I am very confused about how a NAT algorithm can be configured to detect a DDOS attack. I can certainly understand that a box that contains a NAT algorithm might also contain a DDOS detection algorithm, but that is a separate question. Maybe what we need is a specific document on detecting and defeating DDOS attacks in IPv6? That sounds like a major topic in itself, and it isn't only for ICPs. Brian From bingxuere@gmail.com Mon Mar 12 13:15:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8E321E803D for ; Mon, 12 Mar 2012 13:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.393 X-Spam-Level: X-Spam-Status: No, score=-3.393 tagged_above=-999 required=5 tests=[AWL=-0.394, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 QaLvZnYiRgf2 for ; Mon, 12 Mar 2012 13:15:33 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 39FE521E8026 for ; Mon, 12 Mar 2012 13:15:33 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so3521530wib.13 for ; Mon, 12 Mar 2012 13:15:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=P+RAqe5NDg9F8In+SXQ07F7NjaAN7JK3NDzK8ELNYyo=; b=KObhDXZaMLG0OBDnCwL+hOTMi98bXrdazS/fDYnNgz+LiXMDjPn7ngI2JyIuL80b7R D/hgmJTfjhj6MHvF1i61zQGCoLj6k1k7gAlF/hDqA/rOyMM0fCRwmHRmETrdVepDFI1I vjQ/KPlydGH9n5Hzv3QFtFp31bAUSK3z8U8KXsDORM+BIf7MWWfEi04rtQKEfBnLLob2 419LiFWnLJekffIM7NxXwTpleCbF68WZGHzde2DfNvxYyIbDVw2hvglBqnANV4RW8UsO lwTmnEd96kItUWUbVWsm+DX7/sRnQrvL2H94Q7FO3czAO8o2LCmiaCOpyvHg5xN3jiff QBPA== Received: by 10.180.92.34 with SMTP id cj2mr961969wib.8.1331583332401; Mon, 12 Mar 2012 13:15:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.88.21 with HTTP; Mon, 12 Mar 2012 13:14:52 -0700 (PDT) In-Reply-To: References: <25E067CE-65BF-462E-9A45-2D09451256F9@cisco.com> From: Qiong Date: Tue, 13 Mar 2012 04:14:52 +0800 Message-ID: To: "George, Wes" Content-Type: multipart/alternative; boundary=f46d043892b584429704bb1167f6 Cc: v6ops v6ops WG Subject: Re: [v6ops] Agenda discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 20:15:34 -0000 --f46d043892b584429704bb1167f6 Content-Type: text/plain; charset=UTF-8 Dear George and all, We have submitted an updated version of draft-sunq-v6ops-contents-transition based on our practices of IPv4/IPv6 transition system for data center. Since China Telecom has deployed the transition system for data center, we would like to share our experience. Please find it in the following link: http://tools.ietf.org/html/draft-sunq-v6ops-contents-transition-03 We would be appreciated to have your comments and suggestions. Best wishes Qiong On Thu, Mar 8, 2012 at 4:29 AM, George, Wes wrote: > IMO draft-ma-v6ops-terminal-test is not ready for discussion in Paris. > I'll provide a few comments separately on that one, but I don't want those > to be misconstrued as interest in seeing the draft presented. > > I'm interested in draft-gundavelli, but I think it has an awful lot of > placeholders for it to be effectively discussed in Paris. Perhaps next > meeting, unless the authors are currently working on a -01 draft to be > posted later this week that fills in some of the gaps. > > Regarding draft-lopez, As with previous documents of this type, I think > there's a certain burden of proof that we need another cookbook document on > "IPv6 deployment in [foo]" and that IETF is the proper venue for it. As > other work (like ARMD) in IETF is finding out, "datacenter" is such a > nebulous concept that purporting to represent a deployment strategy for a > datacenter is probably simplistic and overbroad. It will either be so > generic that it won't say anything new, or it will be so specific that it > won't be applicable to very many applications, and either way that's not > overly helpful. > While Brian is correct in his observation than ICP != datacenter, many of > the same things are suggested/useful, so I do think that there's a lot of > overlap. The authors either need to propose solving for a different problem > space, or identify a way to eliminate the overlap. > > Thanks, > > Wes George > > > > -----Original Message----- > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Fred > > Baker > > Sent: Monday, March 05, 2012 11:59 PM > > To: v6ops v6ops WG > > Subject: Re: [v6ops] Agenda discussion > > > > Downloading the new drafts, I observe three new ones: > > > > -rw-rw-r-- 1 fred fred 10823 Mar 5 17:46 > draft-ma-v6ops-terminal-test- > > 00.txt > > -rw-rw-r-- 1 fred fred 18058 Mar 6 08:44 > draft-gundavelli-v6ops-community- > > wifi-svcs-00.txt > > -rw-rw-r-- 1 fred fred 21172 Mar 6 10:08 > draft-lopez-v6ops-dc-ipv6-00.txt > > > > (the date/time stamp reflects the fact that I'm in Japan and therefore a > day > > ahead) > > > > In each case, I will be looking for list traffic related to them as my > cue for > > agenda time. Authors, please provoke list traffic... > > > > > > On Mar 6, 2012, at 1:46 PM, Fred Baker wrote: > > > > > Stated in no particular order, we have the following documents that > meet > > these criteria: > > > - not in the IESG process somewhere > > > - posted or updated since IETF 82 > > > - have had list discussion since IETF 82 or responds to discussion at > IETF > > 82 > > > > > > At this point, I take them as our agenda at IETF 83. If I am missing a > > document (if you have posted it since Sunday, I may well be missing it), > > please remind me. > > > > > > > > > http://tools.ietf.org/html/draft-carpenter-v6ops-icp-guidance > > > "IPv6 Guidance for Internet Content and Application Service > Providers", > > > Brian Carpenter, Sheng Jiang, 22-Feb-12 > > > > > > No presentation expected, but the authors would like working group > adoption. > > We need to decide whether we want to do that. > > > > > > http://tools.ietf.org/html/draft-carpenter-v6ops-label-balance > > > "Using the IPv6 Flow Label for Server Load Balancing", Brian > Carpenter, > > > Sheng Jiang, Willy Tarreau, 17-Jan-12 > > > > > > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat > > > "464XLAT: Combination of Stateful and Stateless Translation", Masataka > > > Mawatari, Masanobu Kawashima, Cameron Byrne, 14-Feb-12 > > > > > > http://tools.ietf.org/html/draft-ietf-v6ops-6204bis > > > "Basic Requirements for IPv6 Customer Edge Routers", Barbara Stark, > > > Chris Donley, Hemant Singh, Ole Troan, Wes Beebee, 22-Dec-11 > > > > > > http://tools.ietf.org/html/draft-ietf-v6ops-ivi-icmp-address > > > "Stateless Source Address Mapping for ICMPv6 Packets", Xing Li, > Congxiao > > > Bao, Dan Wing, Ramji Vaithianathan, Geoff Huston, 24-Feb-12 > > > > > > http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation > > > "Implementation Advice for IPv6 Router Advertisement Guard > (RA-Guard)", > > > Fernando Gont, 3-Mar-12 > > > > > > http://tools.ietf.org/html/draft-ietf-v6ops-wireline-incremental-ipv6 > > > "Wireline Incremental IPv6", Victor Kuarsingh, Lee Howard, 1-Feb-12 > > > > > > In the coming week, I am told to expect one additional -00 draft, and I > > could imagine other drafts being updated. I will be looking for those > drafts > > to meet the criteria above as well, but please drop the chairs a note. > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely > for the use of the individual or entity to which it is addressed. If you > are not the intended recipient of this E-mail, you are hereby notified that > any dissemination, distribution, copying, or action taken in relation to > the contents of and attachments to this E-mail is strictly prohibited and > may be unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any copy of > this E-mail and any printout. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --f46d043892b584429704bb1167f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear George and all,

We have submitted an updated version of draft-s= unq-v6ops-contents-transition based on our practices of IPv4/IPv6 transitio= n system for data center. Since China Telecom has deployed the transition s= ystem for data center, we would like to share our experience.

Please find it in the following link:
http://tools.ietf.org/html= /draft-sunq-v6ops-contents-transition-03

We would be appreciated= to have your comments and suggestions.

Best wishes

Qiong


=C2=A0

On Thu, Mar 8, 2012 at 4:29 AM, George, Wes <wesley.george@twcable.com>= wrote:
IMO draft-ma-v6ops-terminal-test is not read= y for discussion in Paris. I'll provide a few comments separately on th= at one, but I don't want those to be misconstrued as interest in seeing= the draft presented.

I'm interested in draft-gundavelli, but I think it has an awful lot of = placeholders for it to be effectively discussed in Paris. Perhaps next meet= ing, unless the authors are currently working on a -01 draft to be posted l= ater this week that fills in some of the gaps.

Regarding draft-lopez, As with previous documents of this type, I think the= re's a certain burden of proof that we need another cookbook document o= n "IPv6 deployment in [foo]" and that IETF is the proper venue fo= r it. As other work (like ARMD) in IETF is finding out, "datacenter&qu= ot; is such a nebulous concept that purporting to represent a deployment st= rategy for a datacenter is probably simplistic and overbroad. It will eithe= r be so generic that it won't say anything new, or it will be so specif= ic that it won't be applicable to very many applications, and either wa= y that's not overly helpful.
While Brian is correct in his observation than ICP !=3D datacenter, many of= the same things are suggested/useful, so I do think that there's a lot= of overlap. The authors either need to propose solving for a different pro= blem space, or identify a way to eliminate the overlap.

Thanks,

Wes George


> -----Original Message-----
> From: v6ops-bounces@ietf.org= [mailto:v6ops-bounces@ietf.o= rg] On Behalf Of Fred
> Baker
> Sent: Monday, March 05, 2012 11:59 PM
> To: v6ops v6ops WG
> Subject: Re: [v6ops] Agenda discussion
>
> Downloading the new drafts, I observe three new ones:
>
> -rw-rw-r-- =C2=A01 fred =C2=A0fred =C2=A010823 Mar =C2=A05 17:46 draft= -ma-v6ops-terminal-test-
> 00.txt
> -rw-rw-r-- =C2=A01 fred =C2=A0fred =C2=A018058 Mar =C2=A06 08:44 draft= -gundavelli-v6ops-community-
> wifi-svcs-00.txt
> -rw-rw-r-- =C2=A01 fred =C2=A0fred =C2=A021172 Mar =C2=A06 10:08 draft= -lopez-v6ops-dc-ipv6-00.txt
>
> (the date/time stamp reflects the fact that I'm in Japan and there= fore a day
> ahead)
>
> In each case, I will be looking for list traffic related to them as my= cue for
> agenda time. Authors, please provoke list traffic...
>
>
> On Mar 6, 2012, at 1:46 PM, Fred Baker wrote:
>
> > Stated in no particular order, we have the following documents th= at meet
> these criteria:
> > =C2=A0- not in the IESG process somewhere
> > =C2=A0- posted or updated since IETF 82
> > =C2=A0- have had list discussion since IETF 82 or responds to dis= cussion at IETF
> 82
> >
> > At this point, I take them as our agenda at IETF 83. If I am miss= ing a
> document (if you have posted it since Sunday, I may well be missing it= ),
> please remind me.
> >
> >
> > http://tools.ietf.org/html/draft-carpenter-v6ops= -icp-guidance
> > =C2=A0"IPv6 Guidance for Internet Content and Application Se= rvice Providers",
> > =C2=A0Brian Carpenter, Sheng Jiang, 22-Feb-12
> >
> > No presentation expected, but the authors would like working grou= p adoption.
> We need to decide whether we want to do that.
> >
> > http://tools.ietf.org/html/draft-carpenter-v6op= s-label-balance
> > =C2=A0"Using the IPv6 Flow Label for Server Load Balancing&q= uot;, Brian Carpenter,
> > =C2=A0Sheng Jiang, Willy Tarreau, 17-Jan-12
> >
> > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat > > =C2=A0"464XLAT: Combination of Stateful and Stateless Transl= ation", Masataka
> > =C2=A0Mawatari, Masanobu Kawashima, Cameron Byrne, 14-Feb-12
> >
> > http://tools.ietf.org/html/draft-ietf-v6ops-6204bis > > =C2=A0"Basic Requirements for IPv6 Customer Edge Routers&quo= t;, Barbara Stark,
> > =C2=A0Chris Donley, Hemant Singh, Ole Troan, Wes Beebee, 22-Dec-1= 1
> >
> > http://tools.ietf.org/html/draft-ietf-v6ops-ivi-i= cmp-address
> > =C2=A0"Stateless Source Address Mapping for ICMPv6 Packets&q= uot;, Xing Li, Congxiao
> > =C2=A0Bao, Dan Wing, Ramji Vaithianathan, Geoff Huston, 24-Feb-12=
> >
> > http://tools.ietf.org/html/draft-ietf-v6op= s-ra-guard-implementation
> > =C2=A0"Implementation Advice for IPv6 Router Advertisement G= uard (RA-Guard)",
> > =C2=A0Fernando Gont, 3-Mar-12
> >
> > http://tools.ietf.org/html/draft-ietf-v6= ops-wireline-incremental-ipv6
> > =C2=A0"Wireline Incremental IPv6", Victor Kuarsingh, Le= e Howard, 1-Feb-12
> >
> > In the coming week, I am told to expect one additional -00 draft,= and I
> could imagine other drafts being updated. I will be looking for those = drafts
> to meet the criteria above as well, but please drop the chairs a note.=
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

This E-mail and any of its attachments may contain Time Warner = Cable proprietary information, which is privileged, confidential, or subjec= t to copyright belonging to Time Warner Cable. This E-mail is intended sole= ly for the use of the individual or entity to which it is addressed. If you= are not the intended recipient of this E-mail, you are hereby notified tha= t any dissemination, distribution, copying, or action taken in relation to = the contents of and attachments to this E-mail is strictly prohibited and m= ay be unlawful. If you have received this E-mail in error, please notify th= e sender immediately and permanently delete the original and any copy of th= is E-mail and any printout.
_________________________________________= ______
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--f46d043892b584429704bb1167f6-- From fred@cisco.com Mon Mar 12 13:39:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F84D11E80E0 for ; Mon, 12 Mar 2012 13:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.033 X-Spam-Level: X-Spam-Status: No, score=-110.033 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 4JYOzXdu7KIE for ; Mon, 12 Mar 2012 13:39:17 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id F1C6B11E80D7 for ; Mon, 12 Mar 2012 13:39:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=15828; q=dns/txt; s=iport; t=1331584757; x=1332794357; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=PSLFIhzFoN9PEhaURxYHRfE2HEUmcTQxs6pbVZTFCM8=; b=HtlDVmT4YFkeTY6UhoLZhh0X9qjUDkWZ/lCMlg1+mHmCgu4HfDmujXrn cNUBzUH7XDrHzZfEs2gm1mKnmGO3kqcy0QbZIFF7IwJabhU4M41wKG4S9 7Gk+L2YcMeqgibnX265wDTQ7/asrl692DAhwiyj0lX4fApMLwNbXsJ+sA I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FALJeXk+tJXHA/2dsb2JhbAA5CqxXAYh7gQeCCQEBAQMBAQEBCwQBUgkEBwUHBAsRBAEBAScHJx8JCAYTFA6HYwULnQYBnn2KLAmFaWMEiFSMeIVpijqDA4E8 X-IronPort-AV: E=Sophos;i="4.73,573,1325462400"; d="scan'208,217";a="65779755" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 12 Mar 2012 20:39:16 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q2CKccPO030139; Mon, 12 Mar 2012 20:39:15 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Mon, 12 Mar 2012 13:39:15 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Mon, 12 Mar 2012 13:39:15 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Mon, 12 Mar 2012 13:39:15 -0700 Message-Id: References: <25E067CE-65BF-462E-9A45-2D09451256F9@cisco.com> To: Qiong X-Mailer: Apple Mail (2.1084) Content-Type: multipart/alternative; boundary=Apple-Mail-27--1057246621 Cc: v6ops v6ops WG Subject: Re: [v6ops] Agenda discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 20:39:19 -0000 --Apple-Mail-27--1057246621 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii As with all submissions, I'm looking for interest expressed on the = mailing list by other operators. On Mar 12, 2012, at 1:14 PM, Qiong wrote: > Dear George and all, >=20 > We have submitted an updated version of = draft-sunq-v6ops-contents-transition based on our practices of IPv4/IPv6 = transition system for data center. Since China Telecom has deployed the = transition system for data center, we would like to share our = experience. >=20 > Please find it in the following link: > http://tools.ietf.org/html/draft-sunq-v6ops-contents-transition-03 >=20 > We would be appreciated to have your comments and suggestions. >=20 > Best wishes >=20 > Qiong >=20 >=20 > =20 >=20 > On Thu, Mar 8, 2012 at 4:29 AM, George, Wes = wrote: > IMO draft-ma-v6ops-terminal-test is not ready for discussion in Paris. = I'll provide a few comments separately on that one, but I don't want = those to be misconstrued as interest in seeing the draft presented. >=20 > I'm interested in draft-gundavelli, but I think it has an awful lot of = placeholders for it to be effectively discussed in Paris. Perhaps next = meeting, unless the authors are currently working on a -01 draft to be = posted later this week that fills in some of the gaps. >=20 > Regarding draft-lopez, As with previous documents of this type, I = think there's a certain burden of proof that we need another cookbook = document on "IPv6 deployment in [foo]" and that IETF is the proper venue = for it. As other work (like ARMD) in IETF is finding out, "datacenter" = is such a nebulous concept that purporting to represent a deployment = strategy for a datacenter is probably simplistic and overbroad. It will = either be so generic that it won't say anything new, or it will be so = specific that it won't be applicable to very many applications, and = either way that's not overly helpful. > While Brian is correct in his observation than ICP !=3D datacenter, = many of the same things are suggested/useful, so I do think that there's = a lot of overlap. The authors either need to propose solving for a = different problem space, or identify a way to eliminate the overlap. >=20 > Thanks, >=20 > Wes George >=20 >=20 > > -----Original Message----- > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of Fred > > Baker > > Sent: Monday, March 05, 2012 11:59 PM > > To: v6ops v6ops WG > > Subject: Re: [v6ops] Agenda discussion > > > > Downloading the new drafts, I observe three new ones: > > > > -rw-rw-r-- 1 fred fred 10823 Mar 5 17:46 = draft-ma-v6ops-terminal-test- > > 00.txt > > -rw-rw-r-- 1 fred fred 18058 Mar 6 08:44 = draft-gundavelli-v6ops-community- > > wifi-svcs-00.txt > > -rw-rw-r-- 1 fred fred 21172 Mar 6 10:08 = draft-lopez-v6ops-dc-ipv6-00.txt > > > > (the date/time stamp reflects the fact that I'm in Japan and = therefore a day > > ahead) > > > > In each case, I will be looking for list traffic related to them as = my cue for > > agenda time. Authors, please provoke list traffic... > > > > > > On Mar 6, 2012, at 1:46 PM, Fred Baker wrote: > > > > > Stated in no particular order, we have the following documents = that meet > > these criteria: > > > - not in the IESG process somewhere > > > - posted or updated since IETF 82 > > > - have had list discussion since IETF 82 or responds to = discussion at IETF > > 82 > > > > > > At this point, I take them as our agenda at IETF 83. If I am = missing a > > document (if you have posted it since Sunday, I may well be missing = it), > > please remind me. > > > > > > > > > http://tools.ietf.org/html/draft-carpenter-v6ops-icp-guidance > > > "IPv6 Guidance for Internet Content and Application Service = Providers", > > > Brian Carpenter, Sheng Jiang, 22-Feb-12 > > > > > > No presentation expected, but the authors would like working group = adoption. > > We need to decide whether we want to do that. > > > > > > http://tools.ietf.org/html/draft-carpenter-v6ops-label-balance > > > "Using the IPv6 Flow Label for Server Load Balancing", Brian = Carpenter, > > > Sheng Jiang, Willy Tarreau, 17-Jan-12 > > > > > > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat > > > "464XLAT: Combination of Stateful and Stateless Translation", = Masataka > > > Mawatari, Masanobu Kawashima, Cameron Byrne, 14-Feb-12 > > > > > > http://tools.ietf.org/html/draft-ietf-v6ops-6204bis > > > "Basic Requirements for IPv6 Customer Edge Routers", Barbara = Stark, > > > Chris Donley, Hemant Singh, Ole Troan, Wes Beebee, 22-Dec-11 > > > > > > http://tools.ietf.org/html/draft-ietf-v6ops-ivi-icmp-address > > > "Stateless Source Address Mapping for ICMPv6 Packets", Xing Li, = Congxiao > > > Bao, Dan Wing, Ramji Vaithianathan, Geoff Huston, 24-Feb-12 > > > > > > = http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation > > > "Implementation Advice for IPv6 Router Advertisement Guard = (RA-Guard)", > > > Fernando Gont, 3-Mar-12 > > > > > > = http://tools.ietf.org/html/draft-ietf-v6ops-wireline-incremental-ipv6 > > > "Wireline Incremental IPv6", Victor Kuarsingh, Lee Howard, = 1-Feb-12 > > > > > > In the coming week, I am told to expect one additional -00 draft, = and I > > could imagine other drafts being updated. I will be looking for = those drafts > > to meet the criteria above as well, but please drop the chairs a = note. > > > _______________________________________________ > > > v6ops mailing list > > > v6ops@ietf.org > > > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops >=20 > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 --Apple-Mail-27--1057246621 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii As with all submissions, I'm looking for interest expressed on the mailing list by other operators.

On Mar 12, 2012, at 1:14 PM, Qiong wrote:

Dear George and all,

We have submitted an updated version of draft-sunq-v6ops-contents-transition based on our practices of IPv4/IPv6 transition system for data center. Since China Telecom has deployed the transition system for data center, we would like to share our experience.

Please find it in the following link:
http://tools.ietf.org/html/draft-sunq-v6ops-contents-transition-03

We would be appreciated to have your comments and suggestions.

Best wishes

Qiong


 

On Thu, Mar 8, 2012 at 4:29 AM, George, Wes <wesley.george@twcable.com> wrote:
IMO draft-ma-v6ops-terminal-test is not ready for discussion in Paris. I'll provide a few comments separately on that one, but I don't want those to be misconstrued as interest in seeing the draft presented.

I'm interested in draft-gundavelli, but I think it has an awful lot of placeholders for it to be effectively discussed in Paris. Perhaps next meeting, unless the authors are currently working on a -01 draft to be posted later this week that fills in some of the gaps.

Regarding draft-lopez, As with previous documents of this type, I think there's a certain burden of proof that we need another cookbook document on "IPv6 deployment in [foo]" and that IETF is the proper venue for it. As other work (like ARMD) in IETF is finding out, "datacenter" is such a nebulous concept that purporting to represent a deployment strategy for a datacenter is probably simplistic and overbroad. It will either be so generic that it won't say anything new, or it will be so specific that it won't be applicable to very many applications, and either way that's not overly helpful.
While Brian is correct in his observation than ICP != datacenter, many of the same things are suggested/useful, so I do think that there's a lot of overlap. The authors either need to propose solving for a different problem space, or identify a way to eliminate the overlap.

Thanks,

Wes George


> -----Original Message-----
> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred
> Baker
> Sent: Monday, March 05, 2012 11:59 PM
> To: v6ops v6ops WG
> Subject: Re: [v6ops] Agenda discussion
>
> Downloading the new drafts, I observe three new ones:
>
> -rw-rw-r--  1 fred  fred  10823 Mar  5 17:46 draft-ma-v6ops-terminal-test-
> 00.txt
> -rw-rw-r--  1 fred  fred  18058 Mar  6 08:44 draft-gundavelli-v6ops-community-
> wifi-svcs-00.txt
> -rw-rw-r--  1 fred  fred  21172 Mar  6 10:08 draft-lopez-v6ops-dc-ipv6-00.txt
>
> (the date/time stamp reflects the fact that I'm in Japan and therefore a day
> ahead)
>
> In each case, I will be looking for list traffic related to them as my cue for
> agenda time. Authors, please provoke list traffic...
>
>
> On Mar 6, 2012, at 1:46 PM, Fred Baker wrote:
>
> > Stated in no particular order, we have the following documents that meet
> these criteria:
> >  - not in the IESG process somewhere
> >  - posted or updated since IETF 82
> >  - have had list discussion since IETF 82 or responds to discussion at IETF
> 82
> >
> > At this point, I take them as our agenda at IETF 83. If I am missing a
> document (if you have posted it since Sunday, I may well be missing it),
> please remind me.
> >
> >
> > http://tools.ietf.org/html/draft-carpenter-v6ops-icp-guidance
> >  "IPv6 Guidance for Internet Content and Application Service Providers",
> >  Brian Carpenter, Sheng Jiang, 22-Feb-12
> >
> > No presentation expected, but the authors would like working group adoption.
> We need to decide whether we want to do that.
> >
> > http://tools.ietf.org/html/draft-carpenter-v6ops-label-balance
> >  "Using the IPv6 Flow Label for Server Load Balancing", Brian Carpenter,
> >  Sheng Jiang, Willy Tarreau, 17-Jan-12
> >
> > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat
> >  "464XLAT: Combination of Stateful and Stateless Translation", Masataka
> >  Mawatari, Masanobu Kawashima, Cameron Byrne, 14-Feb-12
> >
> > http://tools.ietf.org/html/draft-ietf-v6ops-6204bis
> >  "Basic Requirements for IPv6 Customer Edge Routers", Barbara Stark,
> >  Chris Donley, Hemant Singh, Ole Troan, Wes Beebee, 22-Dec-11
> >
> > http://tools.ietf.org/html/draft-ietf-v6ops-ivi-icmp-address
> >  "Stateless Source Address Mapping for ICMPv6 Packets", Xing Li, Congxiao
> >  Bao, Dan Wing, Ramji Vaithianathan, Geoff Huston, 24-Feb-12
> >
> > http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation
> >  "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)",
> >  Fernando Gont, 3-Mar-12
> >
> > http://tools.ietf.org/html/draft-ietf-v6ops-wireline-incremental-ipv6
> >  "Wireline Incremental IPv6", Victor Kuarsingh, Lee Howard, 1-Feb-12
> >
> > In the coming week, I am told to expect one additional -00 draft, and I
> could imagine other drafts being updated. I will be looking for those drafts
> to meet the criteria above as well, but please drop the chairs a note.
> > _______________________________________________
> > v6ops mailing list
> > v6ops@ietf.org
> > https://www.ietf.org/mailman/listinfo/v6ops
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops


--Apple-Mail-27--1057246621-- From Francis.Dupont@fdupont.fr Mon Mar 12 13:40:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA0711E80EA for ; Mon, 12 Mar 2012 13:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, J_CHICKENPOX_13=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 0XE9OVeZPYfi for ; Mon, 12 Mar 2012 13:40:31 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 752C011E80E9 for ; Mon, 12 Mar 2012 13:40:31 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2CKeKKD012370; Mon, 12 Mar 2012 21:40:21 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203122040.q2CKeKKD012370@givry.fdupont.fr> From: Francis Dupont To: "Hemant Singh (shemant)" In-reply-to: Your message of Fri, 09 Mar 2012 11:57:48 CST. <5B6B2B64C9FE2A489045EEEADDAFF2C3042FDD4E@XMB-RCD-109.cisco.com> Date: Mon, 12 Mar 2012 21:40:20 +0100 Sender: Francis.Dupont@fdupont.fr Cc: v6ops-chairs@tools.ietf.org, v6ops@ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 20:40:32 -0000 In your previous mail you wrote: > Ole, authors of pcp-dslite, any SP testing PCP with DS-Lite, and v6ops, => seems I belong to this list (:-) > Please see below. > > Further draft-dupont-pcp-dslite-01 is not in RFC form nor in the IESG. => I don't parse the 'in RFC form': do you have some concerns about the pcp-dslite document (other than below)? > Additionally the pcp-dslite document needs a peer review. => of course it does. Are you candidate to review it (or co-author it)? BTW I can explain the pcp-dslite document history: there are two possible different modes so I asked one and only one would be chosen. The answer was "help yourself" so I polled other PCP implementors to get their opinion and co-authoring, became the editor of the document which in fact is mainly about the mode choice. Since the last version the WG moved all the DS-Lite related details from the base spec to the pcp-dslite document (so a new version will be needed, for instance for some security considerations which was removed). > What is the Appendix A in pcp-dslite talking about including mention > of a "tag"? Why is the tag needed when pcp-base already supports > the necessary protocol? Here is how. => it is an appendix (so not normative) which tries to explain how to implement the "other" mode on the server side. BTW I used the verb "tag" because it is less overloaded than "label" and stronger than "link". > The basic PCP header includes the source IP address of the PCP client > issuing the PCP request. Thus even though the IPv4 PCP request reaches > the CGN in an IPv6 tunnel, the CGN decapsulates the tunneled packet and > passes the packet to the IPv4 stack on the CGN. The IPv4 stack passes > the PCP Request to the PCP server. Snipped from section 6.1 of pcp-base > it this text. > > [IPv4 is represented using an IPv4-mapped IPv6 address.] > > Thus the PCP server is able to reply back to the PCP client in an IPv6 > tunneled PCP response back. => no, it is not able if it doesn't get the IPv6 address to select the right tunnel, and this IPv6 is thrown away when the request tunneled is decapsulated. To summary you didn't understand the appendix A... > I question why pcp-dslite document is needed if pcp-base already covers > the technical details. => it is needed because there is an alternative to the encapsulation mode (so two modes, i.e., one too many) which has some technical advantages (mainly simpler to implement at the server side). Note if you consider DS-Lite as being a particular case it should always be a good idea to push it to a dedicated document as the base spec has far too many things in it. Regards Francis.Dupont@fdupont.fr From tjc@ecs.soton.ac.uk Mon Mar 12 14:54:13 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9F9121F899E for ; Mon, 12 Mar 2012 14:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.044, 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 lDWL2jkunN8o for ; Mon, 12 Mar 2012 14:54:11 -0700 (PDT) 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 0688F21E8051 for ; Mon, 12 Mar 2012 14:54:10 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q2CLs8Kl026295 for ; Mon, 12 Mar 2012 21:54:08 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q2CLs8Kl026295 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1331589248; bh=CF9Iu6ZLJVd3R+wV6WXiZxO8eR4=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=1Rc7zJIUTxmElgBVHATRTJ39gRqc51vP4UaOjU4z2yqoqZ1sORjJcK2euTDfl0mNE TnoMd/RD2q/6tb6uuUbBq+eiCRnpGJpBocCcfjtbBXt91FX2+GTUV/CNnD73JQDkQ8 JTTjhPJvYYu0/PRYCKJ0AR5wNVvA1F/C65BABOFA= 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 id o2BLs805437369615l ret-id none; Mon, 12 Mar 2012 21:54:08 +0000 Received: from [192.168.1.102] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q2CLqmHX015770 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 12 Mar 2012 21:52:49 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Tim Chown In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C304076437@XMB-RCD-109.cisco.com> Date: Mon, 12 Mar 2012 21:52:48 +0000 Content-Transfer-Encoding: 7bit Message-ID: References: "29 Jan 2012 09:51:52PST."<85BE2EBF-C8AC-45E1-BF93-1E3066AD3172@apple.com><201201301936.q0UJaEft000156@givry.fdupont.fr><2D09D61DDFA73D4C884805CC7865E611025B49@GAALPA1MSGUSR9N.ITServices.sbc.com><4A687585-399D-4077-91AC-A1DC4F101E03@apple.com><2D09D61DDFA73D4C884805CC7865E611025BFE@GAALPA1MSGUSR9N.ITServices.sbc.com><30931DE1-9E57-4296-B0FE-FA98F840D78F@apple.com><5B6B2B64C9FE2A489045EEEADDAFF2C3040761AD@XMB-RCD-109.cisco.com> <4F43A296.2070207@viagenie.ca> <5B6B2B64C9FE2A489045EEEADDAFF2C304076437@XMB-RCD-109.cisco.com> <447B48D0-C66D-4051-A0D5-25A084745797@ecs.soton.ac.uk> To: IPv6 Operations X-Mailer: Apple Mail (2.1257) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o2BLs8054373696100; tid=o2BLs805437369615l; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q2CLs8Kl026295 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] PCP server in draft-ietf-v6ops-6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 21:54:14 -0000 On 21 Feb 2012, at 17:46, Hemant Singh (shemant) wrote: > > The other reason is that the LAN behavior of a CPE router is under the > homenet WG charter for over one year back. Rfc6204bis stays away from > any new LAN behavior for the CPE router. Well, at present the homenet architecture text states that transparent, end-to-end communications to/from the subnet should be supported, but at the same time that the default border policy is "Simple Security" with support for a hole-punching signalling protocol to accompany that. It also states that a "transparent" mode should be configurable at the border. Tim From internet-drafts@ietf.org Mon Mar 12 16:35:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7FC221E8212; Mon, 12 Mar 2012 16:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 JQ0SmbhUWy+f; Mon, 12 Mar 2012 16:35:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D9721E8202; Mon, 12 Mar 2012 16:35:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312233534.23224.71949.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 16:35:34 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 23:35:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : 464XLAT: Combination of Stateful and Stateless Translati= on Author(s) : Masataka Mawatari Masanobu Kawashima Cameron Byrne Filename : draft-ietf-v6ops-464xlat-01.txt Pages : 15 Date : 2012-03-12 This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation RFC 6146 in the core and stateless protocol translation RFC 6145 at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to mobile and wireline IPv6-only edge networks without encapsulation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-01.txt From kawashimam@vx.jp.nec.com Mon Mar 12 16:44:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7DA21E8246 for ; Mon, 12 Mar 2012 16:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.039 X-Spam-Level: X-Spam-Status: No, score=0.039 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] 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 lGy8tby7fiLA for ; Mon, 12 Mar 2012 16:44:44 -0700 (PDT) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by ietfa.amsl.com (Postfix) with ESMTP id B0B9121E8242 for ; Mon, 12 Mar 2012 16:44:40 -0700 (PDT) Received: from mailgate3.nec.co.jp ([10.7.69.195]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id q2CNie7u022845 for ; Tue, 13 Mar 2012 08:44:40 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id q2CNids25868 for v6ops@ietf.org; Tue, 13 Mar 2012 08:44:39 +0900 (JST) Received: from mail01b.kamome.nec.co.jp (mail01b.kamome.nec.co.jp [10.25.43.2]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id q2CNidP8024933 for ; Tue, 13 Mar 2012 08:44:39 +0900 (JST) Received: from zuizan.jp.nec.com ([10.26.220.9] [10.26.220.9]) by mail03.kamome.nec.co.jp with ESMTP id BT-MMP-45006; Tue, 13 Mar 2012 08:43:18 +0900 Received: from siznecatg159185 ([10.3.159.185] [10.3.159.185]) by mail.jp.nec.com with ESMTPA id BT-MMP-5037; Tue, 13 Mar 2012 08:43:18 +0900 To: v6ops@ietf.org In-reply-to: <20120312233534.23224.71949.idtracker@ietfa.amsl.com> Message-Id: <20120313084317kawashimam@mail.jp.nec.com> References: <20120312233534.23224.71949.idtracker@ietfa.amsl.com> Mime-Version: 1.0 X-Mailer: StarOffice21/MailClient[4.65 Step9] From: Masanobu Kawashima Date: Tue, 13 Mar 2012 08:43:16 +0900 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-464xlat-01.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 23:44:45 -0000 We have published draft-ietf-v6ops-464xlat-01. Changes are: - A normative language has been removed. - "IPv6 Fragment Header Consideration" section has been removed. - Some clarifications have been added. - Many comments have been added. All comments are welcome. Regards, Masanobu > >A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. > > Title : 464XLAT: Combination of Stateful and Stateless Translation > Author(s) : Masataka Mawatari > Masanobu Kawashima > Cameron Byrne > Filename : draft-ietf-v6ops-464xlat-01.txt > Pages : 15 > Date : 2012-03-12 > > This document describes an architecture (464XLAT) for providing > limited IPv4 connectivity across an IPv6-only network by combining > existing and well-known stateful protocol translation RFC 6146 in the > core and stateless protocol translation RFC 6145 at the edge. 464XLAT > is a simple and scalable technique to quickly deploy limited IPv4 > access service to mobile and wireline IPv6-only edge networks without > encapsulation. > > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-01.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >This Internet-Draft can be retrieved at: >ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-464xlat-01.txt > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops ======================================== NEC AccessTechnica, Ltd. Product Development Department Masanobu Kawashima kawashimam@vx.jp.nec.com http://www.necat.co.jp/ ======================================== From brian.e.carpenter@gmail.com Mon Mar 12 17:42:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D0C21E80C0 for ; Mon, 12 Mar 2012 17:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.434 X-Spam-Level: X-Spam-Status: No, score=-103.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 kQsIwGTciJHA for ; Mon, 12 Mar 2012 17:42:53 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 022F221E8073 for ; Mon, 12 Mar 2012 17:42:52 -0700 (PDT) Received: by yhpp34 with SMTP id p34so3673467yhp.31 for ; Mon, 12 Mar 2012 17:42:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=+tpArgYMfmk6vRyx2CV9IK+UmKZ9EEz1LWQIfckQmkY=; b=BI4jspajEXn1NoCB6ZAdosr+uvaiNDB5KJVwUBt6sFSpIrPumrxUVVWySaCf2dd7By OjvcpkhRvJQTyvDQS3w9/NyLbReK95n1w63MFoRJVPcuhiVfDYnvnqOw/ZATDEFpPxYQ UFLmpS/OdGGlCEIQGIDPoQQS3p6DdrQSb08FV5+qjl4BwXopBljK7OHVN0+IZ0Upd+6/ aLwyQrb4NCb5lwxyeRFLF7Sm2RUIfVKrv2IiyEaVC8V85SuZI32ib4iU1MxlmoiI+9+z er6gou5qM11IDbhfRJ59DboPx0JvYPsmxXr1kmYBQ95mYaLOsOflXtJQ1TBdYs9DhB1c dREg== Received: by 10.60.7.200 with SMTP id l8mr5374336oea.52.1331599372498; Mon, 12 Mar 2012 17:42:52 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id x9sm12944543oea.7.2012.03.12.17.42.50 (version=SSLv3 cipher=OTHER); Mon, 12 Mar 2012 17:42:52 -0700 (PDT) Message-ID: <4F5E9807.9030403@gmail.com> Date: Tue, 13 Mar 2012 13:42:47 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations References: <4F3ABDCB.80004@gmail.com> In-Reply-To: <4F3ABDCB.80004@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] NAT64 performance comparisons X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 00:42:53 -0000 The official handle for this is http://hdl.handle.net/2292/13586 Brian On 2012-02-15 09:02, Brian E Carpenter wrote: > On the subject of NAT64, I'v just filed a tech report on some work > done by Se-young Yu under my supervision. It will get an official > library handle soon, but here is an ad hoc URL to be going on with: > > http://www.cs.auckland.ac.nz/~brian/IPv4-IPv6coexistenceTechnique-TR.pdf > From fred@cisco.com Mon Mar 12 17:51:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E97121E806F for ; Mon, 12 Mar 2012 17:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.798 X-Spam-Level: X-Spam-Status: No, score=-108.798 tagged_above=-999 required=5 tests=[AWL=1.201, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 1k+5eEmAlgFN for ; Mon, 12 Mar 2012 17:51:51 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id B077421E80EC for ; Mon, 12 Mar 2012 17:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1041; q=dns/txt; s=iport; t=1331599911; x=1332809511; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=l7j9K+9ONEkw/SSh1N9ps8oUX0intu0ZvL1tHmtJd/w=; b=cKjDT+qMrmkrALcWKSfx5B/FMj1WtZDV8zalnilUzzYw0xllsKMEXIYe 6Fcl2sSO1l102AjLH6gOSf7JKj/itU3JcxPtdn2A5or65lroBxm6pQESH j8myyWm4TEoV7LkyJx4srMZ7TncT0M+tovrf4X2XeupksV/SyghHZzEGe A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAC2ZXk+rRDoH/2dsb2JhbABDFrVJgQeCCQEBAQIBAQEBAQ8BJzQLBQsLGC4nMAYTIodjBAycfgGNMpFYkAZjBIhUjHiFaYo6gwM X-IronPort-AV: E=Sophos;i="4.73,574,1325462400"; d="scan'208";a="35828955" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 13 Mar 2012 00:51:51 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2D0poM0020044; Tue, 13 Mar 2012 00:51:51 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Mon, 12 Mar 2012 17:51:51 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Mon, 12 Mar 2012 17:51:51 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4F5E9807.9030403@gmail.com> Date: Mon, 12 Mar 2012 17:51:21 -0700 Message-Id: <8B2D5BEF-32B9-4018-9055-575B85769BD8@cisco.com> References: <4F3ABDCB.80004@gmail.com> <4F5E9807.9030403@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] NAT64 performance comparisons X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 00:51:52 -0000 Hmm. It appears to have tested exactly one implementation and reported = results for the algorithms. It says that stateful NAT64 is better than = NAT-PT, which I might have expected, but appears to have not tested the = stateless mode. It seems like you would need to test more than one implementation before = your could generalize to a statement about the class of = implementations... On Mar 12, 2012, at 5:42 PM, Brian E Carpenter wrote: > The official handle for this is http://hdl.handle.net/2292/13586 >=20 > Brian >=20 > On 2012-02-15 09:02, Brian E Carpenter wrote: >> On the subject of NAT64, I'v just filed a tech report on some work >> done by Se-young Yu under my supervision. It will get an official >> library handle soon, but here is an ad hoc URL to be going on with: >>=20 >> = http://www.cs.auckland.ac.nz/~brian/IPv4-IPv6coexistenceTechnique-TR.pdf >>=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From brian.e.carpenter@gmail.com Mon Mar 12 18:18:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9642E21F881C for ; Mon, 12 Mar 2012 18:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.139 X-Spam-Level: X-Spam-Status: No, score=-103.139 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, 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 Vj1hGRiBcli2 for ; Mon, 12 Mar 2012 18:18:15 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9D61F21F881B for ; Mon, 12 Mar 2012 18:18:15 -0700 (PDT) Received: by mail-yw0-f44.google.com with SMTP id p34so7092yhp.31 for ; Mon, 12 Mar 2012 18:18:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Qp3t9PRaqPxFCHcVbCeEvN2AHwTjkhke+oPPaZWHvnY=; b=h5+by3y6XLwza65eTe4q8y91r77+MZjxzz50KUOeVHdjy9SwgT4TqRi+5isFfotl2i L0tkPlVP8cRS/dDQEYxDbU9+kmBHCjJNIBHOw8ITBCOzw4AQ1gDRP+XH8v7f9asUdd7k m0iAJhcx23ZyOUYlLf6Uy8BKLwtWXVLCxJeZCBVAVGcCv5rLN0R20oJ5aSocWOtP0cmR hjrVNsQcGx5ektK6tX2bowgpljApibsZUXNK8bYqCIJ+FlV7DorAoPSBNRO1hJxT6+g3 q6rZVqg8SSlzxpPfLDPEfB8AEMV24n56hOtuUJqt18OFJyrZ7RvT9+Utic2qpEhPGAcq 4FZA== Received: by 10.236.170.198 with SMTP id p46mr15438118yhl.63.1331601495483; Mon, 12 Mar 2012 18:18:15 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id l2sm25308492anq.12.2012.03.12.18.18.13 (version=SSLv3 cipher=OTHER); Mon, 12 Mar 2012 18:18:15 -0700 (PDT) Message-ID: <4F5EA052.60402@gmail.com> Date: Tue, 13 Mar 2012 14:18:10 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fred Baker References: <4F3ABDCB.80004@gmail.com> <4F5E9807.9030403@gmail.com> <8B2D5BEF-32B9-4018-9055-575B85769BD8@cisco.com> In-Reply-To: <8B2D5BEF-32B9-4018-9055-575B85769BD8@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] NAT64 performance comparisons X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 01:18:16 -0000 On 2012-03-13 13:51, Fred Baker wrote: > Hmm. It appears to have tested exactly one implementation and reported results for the algorithms. It says that stateful NAT64 is better than NAT-PT, which I might have expected, but appears to have not tested the stateless mode. Yes. > It seems like you would need to test more than one implementation before your could generalize to a statement about the class of implementations... Of course. That's more or less what the conclusion says. Brian > On Mar 12, 2012, at 5:42 PM, Brian E Carpenter wrote: > >> The official handle for this is http://hdl.handle.net/2292/13586 >> >> Brian >> >> On 2012-02-15 09:02, Brian E Carpenter wrote: >>> On the subject of NAT64, I'v just filed a tech report on some work >>> done by Se-young Yu under my supervision. It will get an official >>> library handle soon, but here is an ad hoc URL to be going on with: >>> >>> http://www.cs.auckland.ac.nz/~brian/IPv4-IPv6coexistenceTechnique-TR.pdf >>> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > > From brian.e.carpenter@gmail.com Mon Mar 12 19:02:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F1111E8085 for ; Mon, 12 Mar 2012 19:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.439 X-Spam-Level: X-Spam-Status: No, score=-103.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 eY5vRIdcpJgU for ; Mon, 12 Mar 2012 19:02:29 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 710CA11E8083 for ; Mon, 12 Mar 2012 19:02:29 -0700 (PDT) Received: by ggmi1 with SMTP id i1so39832ggm.31 for ; Mon, 12 Mar 2012 19:02:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=C64cqO07yNvIK99nlBIb02GAVXTXlECgkXzNqcLL2Cw=; b=bqoIElSLSxwqXWetxR+G8Dlis7ljGa9vL5HUgG60XEa35tKAx/AAEx0KqwBH6zBu6I 44UbzCUJnM8FBAQMP0y6Wsu0tuiJQZ3Vhfp3wuUAG8QfkZaN6QHsBl/SkXITa/+J0+um twf3WgP4hZ90U9vWFQHyhkcffb0uRvA2mlgxM3diXWNw1AnY7J1NFr9O3kUPhG6HbrDi OxKqV6CFwxP0EvRvnygxsdJwIMesqYhSkp63ZjIuS24SmiXow9NOYTo4B3c2OLM6Xaix mUxZuN96T3C4epHlDCRJ40W8gdrfToPCHSgEC7+W9Xfa3X2Hgj6sIwf7YltLxOrD7n3o 2irw== Received: by 10.182.147.106 with SMTP id tj10mr9889065obb.71.1331604148951; Mon, 12 Mar 2012 19:02:28 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id n1sm23529620obm.11.2012.03.12.19.02.27 (version=SSLv3 cipher=OTHER); Mon, 12 Mar 2012 19:02:28 -0700 (PDT) Message-ID: <4F5EAAB1.9040900@gmail.com> Date: Tue, 13 Mar 2012 15:02:25 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [v6ops] FYI [Fwd: RFC 6563 on Moving A6 to Historic Status] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 02:02:30 -0000 -------- Original Message -------- Subject: RFC 6563 on Moving A6 to Historic Status Date: Mon, 12 Mar 2012 15:55:06 -0700 (PDT) From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org CC: rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 6563 Title: Moving A6 to Historic Status Author: S. Jiang, D. Conrad, B. Carpenter Status: Informational Stream: IETF Date: March 2012 Mailbox: jiangsheng@huawei.com, drc@cloudflare.com, brian.e.carpenter@gmail.com Pages: 8 Characters: 16654 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-jiang-a6-to-historic-00.txt URL: http://www.rfc-editor.org/rfc/rfc6563.txt This document provides a summary of issues related to the use of A6 records, discusses the current status, and moves RFC 2874 to Historic status, providing clarity to implementers and operators. This document is not an Internet Standards Track specification; it is published for informational purposes. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From phdgang@gmail.com Mon Mar 12 19:59:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6D921F87BE for ; Mon, 12 Mar 2012 19:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 vkot-3y28nWZ for ; Mon, 12 Mar 2012 19:59:09 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4A66A21F87B1 for ; Mon, 12 Mar 2012 19:59:09 -0700 (PDT) Received: by werb10 with SMTP id b10so67868wer.31 for ; Mon, 12 Mar 2012 19:59:08 -0700 (PDT) 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 :content-type:content-transfer-encoding; bh=TRwb+wxamTWuG/hnVHSGt4hVctccs0bGtNQ7/7eg4iw=; b=zy6v/jQ+dLdqIBtHtfABEn4ZsC942p+sILbYMo+itL9eZmK599CT0rliPZf4Rvgm6Z jR0zGxKXWZZwyH40Ci4AYQ4TE/zO5xuxX6kL9RYltDH5krHXwiTBuarKuALJFp0ityTh Iuanq4hCFwz9mcLjH6z6m+tSCxf6+vjKD6plMulQARA9E62QzMic+a+ZNnXcXWl4IrQE Ci+bJ8o/FkKnqBP7mWGOf1oWlYpJ2Z59zGr+FpTDDWuWL4Aa7ZqCcNe7wMYMcrFhshiO 3NZnRGQNjzBfxWsfEBnX26p2Pqb/GB9RypXIEURB/e1hSH24/hh4HrHznUeXeqogiMzV AKww== MIME-Version: 1.0 Received: by 10.180.85.69 with SMTP id f5mr3151446wiz.18.1331607548445; Mon, 12 Mar 2012 19:59:08 -0700 (PDT) Received: by 10.180.7.105 with HTTP; Mon, 12 Mar 2012 19:59:08 -0700 (PDT) In-Reply-To: References: <11ECC355-6FAC-4D69-A615-AB43F2180CEE@laposte.net> Date: Tue, 13 Mar 2012 10:59:08 +0800 Message-ID: From: GangChen To: v6ops@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [v6ops] I-D Action: draft-chen-v6ops-nat64-experience-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 02:59:10 -0000 Hello all, Replying the comments received on the list, we updated the draft and published -01 for NAT64 experiences. Please check the side-by-side diff as below http://tools.ietf.org/rfcdiff?url1=3Ddraft-chen-v6ops-nat64-experience-00&d= ifftype=3D--html&submit=3DGo%21&url2=3Ddraft-chen-v6ops-nat64-experience-01 Your further comments are appreciated A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : NAT64 Operational Experiences Author(s) : Gang Chen Zhen Cao Cameron Byrne QiBo Niu Filename : draft-chen-v6ops-nat64-experience-01.txt Pages : 11 Date : 2012-03-12 This document summarizes some stateful NAT64 deployment scenarios and operational experiences for NAT64-CGN and NAT64-CE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-experience-01.tx= t BRs Gang 2012/3/10, GangChen : > Hello Remi, > > >> 1. >> This kind of draft is IMHO useful because it discusses the global >> picture. > > Thanks for the supports. > > >> Maybe calling it NAT64 operational "issues" or "scenarios", would better >> describe its contents than just "experiences" which, IMHO suggests a >> report >> on already observed behaviors. > > Your interpretation is correct. The word of "experiences" came from > last meeting discussions. People expected the draft provides NAT64 > operational views and document experiences. It would like to draft > what we have observed more than what we recommended to let IETF do > some protocol enhancements. Therefore, I guess "experiences" is good > to express the intention. > >> 2. >> One point of substance: sec. 3.6 says "One approach avoiding this issue >> is >> to configure IPv4 MTU>=3D1260, which would forbid the occurence of >> PTB<1280". >> It should be possible for the IPv6 Internet to IPv4 network scenario of >> sec. >> 3, but not for the IPv6 network to IPv4 Internet scenario of sec 2. Thi= s >> should IMHO be clarified. > > Agree. It should be clarified. I will do in next version. > >> >> 3. >> Couldn' understand this sentence of sec. 1: >> "Since the scenario of "The IPv6 Internet to the IPv4 Internet" seems th= e >> ideal case for in-network translation technology, this document has >> focused >> on the three cases and categorized different NAT64 usages as NAT64-CGN >> and >> NAT64-CE." > > Considering potential audiences, who want to get the information for > their possible deployment of NAT64 in near future, we are focusing > three common cases of NAT64. "The IPv6 Internet to the IPv4 Internet" > may be too early to state some experiences. > >> 4. >> Minor noted typos: >> - 3.3 >> "might a good choice" =3D> "might be a good choice" >> - 3.1 >> "is to distributed" =3D> "is to distribute" >> - 3.5 >> " a synthetic AAAA records" =3D> "a synthetic AAAA record" >> - 3.6 >> "occurence" =3D> "occurrence" > > Many thanks. I would fix that in next version. > >> 5. >> For a further version, I would suggest to include more referenced >> documents >> (in particular about Lawful traceability, IAP, ALGs other than FTP, SYN >> Proxy-cookie). > > Will do in next version. > > BRs > > Gang > >> Regards, >> RD >> >> >> >> Le 2012-02-14 =E0 05:11, GangChen a =E9crit : >> >>> Hello all, >>> >>> We have published draft-chen-v6ops-nat64-experience-00, which >>> described NAT64 operational expriences and updated with all the >>> information from the presentation of draft-chen-v6ops-nat64-cpe at >>> last meeting. Considering the new changes, authors would like to >>> retire the old draft (i.e. draft-chen-v6ops-nat64-cpe) and continue >>> the discussion on nat64 experiences. >>> >>> All comments are welcome. >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> >>> Title : NAT64 Operational Experiences >>> Author(s) : Gang Chen >>> Zhen Cao >>> Cameron Byrne >>> QiBo Niu >>> Filename : draft-chen-v6ops-nat64-experience-00.txt >>> Pages : 11 >>> Date : 2012-02-13 >>> >>> This document summarizes some stateful NAT64 deployment scenarios and >>> operational experiences for NAT64-CGN and NAT64-CE. >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-experience-0= 0.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-chen-v6ops-nat64-experience-00= .txt >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> >> > From leo.liubing@huawei.com Mon Mar 12 20:02:19 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E69D621F8882 for ; Mon, 12 Mar 2012 20:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.848 X-Spam-Level: X-Spam-Status: No, score=-5.848 tagged_above=-999 required=5 tests=[AWL=-0.451, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_33=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 YoM3YNjjcvxL for ; Mon, 12 Mar 2012 20:02:17 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 5946C21F87D6 for ; Mon, 12 Mar 2012 20:02:17 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0S00G4YZ3ADJ@szxga05-in.huawei.com> for v6ops@ietf.org; Tue, 13 Mar 2012 11:01:58 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0S00IK0Z02Z1@szxga05-in.huawei.com> for v6ops@ietf.org; Tue, 13 Mar 2012 11:01:58 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHU17969; Tue, 13 Mar 2012 11:01:57 +0800 Received: from SZXEML437-HUB.china.huawei.com (10.72.61.72) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 13 Mar 2012 11:01:53 +0800 Received: from SZXEML509-MBX.china.huawei.com ([169.254.1.93]) by szxeml437-hub.china.huawei.com ([10.72.61.72]) with mapi id 14.01.0323.003; Tue, 13 Mar 2012 11:01:51 +0800 Date: Tue, 13 Mar 2012 03:01:50 +0000 From: "Leo Liu(bing)" X-Originating-IP: [10.108.4.84] To: "v6ops@ietf.org" Message-id: <8AE0F17B87264D4CAC7DE0AA6C406F4524A1261F@szxeml509-mbx.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_aLzLMTMU+4MIHaKWF0z7lg)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: ULA discussion again Thread-index: Ac0AxaEY5g7S92fFQRu/8R2lB0pWww== X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AJrA A6kO A6us BxTw BziC B9QG CEuY DGio FriU F7In GJ1d GSBe H4gH Iu/v J0AA Kne6; 1; dgA2AG8AcABzAEAAaQBlAHQAZgAuAG8AcgBnAA==; Sosha1_v1; 7; {44F3F04B-AFFF-4CCF-B095-03498E4A0EEF}; bABlAG8ALgBsAGkAdQBiAGkAbgBnAEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Tue, 13 Mar 2012 03:01:47 GMT;VQBMAEEAIABkAGkAcwBjAHUAcwBzAGkAbwBuACAAYQBnAGEAaQBuAA== x-cr-puzzleid: {44F3F04B-AFFF-4CCF-B095-03498E4A0EEF} X-CFilter-Loop: Reflected Subject: [v6ops] ULA discussion again X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 03:02:20 -0000 --Boundary_(ID_aLzLMTMU+4MIHaKWF0z7lg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi, all We've submitted a new version of draft-liu-v6ops-ula-usage-analysis, please check it at: http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis-02 There're a number of changes according to the discussion in last meeting. For your convenience, I'd like to summarize them as the following: The use cases were simplified as 4: - ULA only. ULA is good solution for isolated networks. For ULA can be used for internal communications without having any permanent or only intermittent Internet connectivity. It is on-demand and supports internal routing. For connected networks, ULA+NAT is also meaningful in some scenarios where nodes have very constrained resource to support ND/DHCP. However, this draft doesn't consider ULA+NAT a recommendation for normal IPv6 deployment. - ULA+PA the main purpose of using ULA along with PA is to provide a logically local routing plane separated from the globally routing plane. The benefit is to ensure stable and specific local communication regardless of the ISP uplink failure. This benefit is especially meaningful for the home network or private OAM function in an enterprise. And we consider the separated local routing plane is also beneficial for renumbering, for when renumbering, it is not easy to keep the local communication immune of global routing plane change. - Special routing/prefix If you have a special routing scenario, of which [draft-baker-v6ops-b2b-private-routing] is an example, for various reasons you might want to have routing that you control and is separate from other routing. Since the NAT64 pref64 is just a group of local fake addresses for the DNS64 to point traffic to a NAT64, the pref64 is a very good use of ULA. (It is now been used in the some real network deployment.) - As identifier As in RFC6281, ULA can be used as upper-layer identifiers for it is easy to be grabbed in an IPv6 enabled node. It is a good use of ULA. And we have some conclusions: O ULAs have been successfully deployed in a diverse set of circumstances including large private machine-to-machine type networks, enterprise networks with private systems, and within service providers to limit Internet communication with non-public services such as caching DNS servers and NAT64 translation resources. o ULAs do not provide any intrinsic security benefit, but the characteristic that they cannot be routed on the internet may be leveraged as part of a multilayer security policy to limit the communication with the internet. o ULAs are self-assigned and unique. Self-assigned allows for network deployments independent of RIR policy or documentation requirements. The fact that ULA require randomization within the prefix ensures that ULA is an improvement over RFC1918 deployments which were likely to collide when internal networks merged. Your comments are expected. Thanks. --Boundary_(ID_aLzLMTMU+4MIHaKWF0z7lg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi, all

 

We’ve submitted a new version of draft-liu-v6ops-ula-usage-analysis, please check it at:

http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis-02

 

There’re a number of changes according to the discussion in last meeting. For your convenience, I’d like to summarize them as the following:

 

The use cases were simplified as 4:

-  ULA only.

ULA is good solution for isolated networks. For ULA can be used for internal communications without having any permanent or only intermittent Internet connectivity. It is on-demand and supports internal routing.

For connected networks, ULA+NAT is also meaningful in some scenarios where nodes have very constrained resource to support ND/DHCP. However, this draft doesn’t consider ULA+NAT a recommendation for normal IPv6 deployment.  

 

-  ULA+PA

the main purpose of using ULA along with PA is to provide a logically local routing plane separated from the globally routing plane. The benefit is to ensure stable and specific local communication regardless of the ISP uplink failure. This benefit is especially meaningful for the home network or private OAM function in an enterprise.

And we consider the separated local routing plane is also beneficial for renumbering, for when renumbering, it is not easy to keep the local communication immune of global routing plane change.

 

-  Special routing/prefix

If you have a special routing scenario, of which [draft-baker-v6ops-b2b-private-routing] is an example, for various reasons you might want to have routing that you control and is separate from other routing.

Since the NAT64 pref64 is just a group of local fake addresses for the DNS64 to point traffic to a NAT64, the pref64 is a very good use of ULA. (It is now been used in the some real network deployment.)

 

- As identifier

As in RFC6281, ULA can be used as upper-layer identifiers for it is easy to be grabbed in an IPv6 enabled node. It is a good use of ULA.

 

And we have some conclusions:

O  ULAs have been successfully deployed in a diverse set of

      circumstances including large private machine-to-machine type

      networks, enterprise networks with private systems, and within

      service providers to limit Internet communication with non-public

      services such as caching DNS servers and NAT64 translation

      resources.

 

   o  ULAs do not provide any intrinsic security benefit, but the

      characteristic that they cannot be routed on the internet may be

      leveraged as part of a multilayer security policy to limit the

      communication with the internet.

 

   o  ULAs are self-assigned and unique. Self-assigned allows for

      network deployments independent of RIR policy or documentation

      requirements. The fact that ULA require randomization within the

      prefix ensures that ULA is an improvement over RFC1918 deployments

      which were likely to collide when internal networks merged.

 

Your comments are expected.

Thanks.

 

--Boundary_(ID_aLzLMTMU+4MIHaKWF0z7lg)-- From denghui02@gmail.com Mon Mar 12 21:23:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20FD711E8083 for ; Mon, 12 Mar 2012 21:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.332 X-Spam-Level: X-Spam-Status: No, score=-103.332 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 d+4LUW2aNeO8 for ; Mon, 12 Mar 2012 21:23:00 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id BF12E11E807F for ; Mon, 12 Mar 2012 21:23:00 -0700 (PDT) Received: by ghbg16 with SMTP id g16so138595ghb.31 for ; Mon, 12 Mar 2012 21:22:59 -0700 (PDT) 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=rxN7gUeL38bN0mfxbwT2bsxHnakO9ViQsW+9YHkb+0w=; b=g5zfHQHR2b7fwQL733FkMLnqjFoVlSkIqBWDI0LEg1v4fuIEFWgUeAOWJfG98TtD6H EGU7RB++0mJiJyczaNXDGisvDnDg+zfdzWx+eSmUyxoB//nsdEF7NDyXNZAMdqYL+wNG 2jTZevU2dsrPtt1g3gXgG1PqZ4gwIiuWe8bdelfUduPfDKU3zExMOo1RBODqFbFQvxAb sD0rYbu5RhAFIEc2V1C58+nsW3iVEZym3nzm5sguC+fEplNeBq7rDnI8SSpzVRHVn3ES BBbvtxT97D97eJih7tD+UzIII+zr25K4HhF0dI9JkDoTzAorQGy6Ln4owMoX0xpCrog+ DMRQ== MIME-Version: 1.0 Received: by 10.236.197.74 with SMTP id s50mr15495349yhn.127.1331612579792; Mon, 12 Mar 2012 21:22:59 -0700 (PDT) Received: by 10.147.123.12 with HTTP; Mon, 12 Mar 2012 21:22:59 -0700 (PDT) In-Reply-To: <4F5E5922.4050501@gmail.com> References: <4F45B554.2060103@gmail.com> <4F5CF9B2.5070702@gmail.com> <4F5E5922.4050501@gmail.com> Date: Tue, 13 Mar 2012 12:22:59 +0800 Message-ID: From: Hui Deng To: Brian E Carpenter Content-Type: multipart/alternative; boundary=20cf3040e37acc059504bb1836a3 Cc: IPv6 Operations Subject: Re: [v6ops] [Fwd: I-D Action: draft-carpenter-v6ops-icp-guidance-03.txt] X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 04:23:02 -0000 --20cf3040e37acc059504bb1836a3 Content-Type: text/plain; charset=ISO-8859-1 Hi Brian I am fine to keep it a seperate topic, maybe write an guidance document for Prevention from DDOS in IPv6 sounds reasonable -Hui 2012/3/13 Brian E Carpenter > Hi, > > On 2012-03-12 17:00, Hui Deng wrote: > ... > >>> 4) ICP need to fully understand how to avoid DDOS when they launch the > >>> IPv6, otherwise they will always need NAT solution > >> Can you explain that please? > >> > > this expecting that this document could explain how to avoid DDOS in > > detail, otherwise, they have to deploy special NAT to handle this by > > configure some policy over there. > > I am very confused about how a NAT algorithm can be configured to detect > a DDOS attack. I can certainly understand that a box that contains a NAT > algorithm might also contain a DDOS detection algorithm, but that is > a separate question. > > Maybe what we need is a specific document on detecting and defeating DDOS > attacks in IPv6? That sounds like a major topic in itself, and it isn't > only for ICPs. > > Brian > --20cf3040e37acc059504bb1836a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi=A0Brian
=A0
I am fine to keep it a seperate topic, maybe write an guidance documen= t for Prevention from DDOS in IPv6=A0sounds reasonable
=A0
-Hui

2012/3/13 Brian E Carpenter &l= t;brian.e.= carpenter@gmail.com>
Hi,

On 2012-03-12 17:00, Hui D= eng wrote:
...
>>> 4) ICP need to fully understand how to avoid DDOS when th= ey launch the
>>> IPv6, otherwise they will always need NAT sol= ution
>> Can you explain that please?
>>
> this exp= ecting that this document could explain how to avoid DDOS in
> detail, otherwise, they have to deploy special NAT to handle this by> configure some policy over there.

I am very confused ab= out how a NAT algorithm can be configured to detect
a DDOS attack. I can= certainly understand that a box that contains a NAT
algorithm might also contain a DDOS detection algorithm, but that is
a s= eparate question.

Maybe what we need is a specific document on detec= ting and defeating DDOS
attacks in IPv6? That sounds like a major topic = in itself, and it isn't
only for ICPs.

=A0 Brian

--20cf3040e37acc059504bb1836a3-- From fred@cisco.com Mon Mar 12 23:19:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1285E21F88A5 for ; Mon, 12 Mar 2012 23:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.134 X-Spam-Level: X-Spam-Status: No, score=-109.134 tagged_above=-999 required=5 tests=[AWL=1.464, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 HAPHkLPL+kA8 for ; Mon, 12 Mar 2012 23:19:53 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA6721F88A3 for ; Mon, 12 Mar 2012 23:19:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=7572; q=dns/txt; s=iport; t=1331619593; x=1332829193; h=from:subject:date:message-id:cc:to:mime-version; bh=CMmp7a1joRaPmsdy5gdx6UuFzcq/4DvUobX77iTO4BY=; b=DGSXjEn3EqJyM+qCkRWmwiDBl/ALXakIk/rECrrWP/pdUuRqbKQqWkJD k/umAtYcGspVDWOevFH0XFVBqp2JaFC/35crHG5fyXvv+DLaIs1wOEAe+ gO8fOUCAcwTXFUfplyrhoUN5gJ8WCzgIE2+C8QQJwPDioA2Qjse5kCvCU U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFABnmXk+rRDoJ/2dsb2JhbABDgkWqIAGIe4EHgh4EARo4FIE+Jw6HZwydVQGfE5ACYwSIVYx6hWmKOoMF X-IronPort-AV: E=Sophos;i="4.73,575,1325462400"; d="scan'208,217";a="33277551" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 13 Mar 2012 06:19:53 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2D6JqKY001069; Tue, 13 Mar 2012 06:19:52 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Mon, 12 Mar 2012 23:19:52 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Mon, 12 Mar 2012 23:19:52 -0700 From: Fred Baker Date: Mon, 12 Mar 2012 23:19:26 -0700 Message-Id: <4E37330E-D9F7-4596-B2BC-6B8FCBA80FE1@cisco.com> To: IPv6 Operations Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: multipart/alternative; boundary=Apple-Mail-59--1022435278 Cc: Ron Bonica Subject: [v6ops] IPv6 Operations - IETF 83 - Preliminary Agenda X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 06:19:54 -0000 --Apple-Mail-59--1022435278 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I'm having some difficulty uploading to the meeting manager. This is the = agenda as we have it right now. That gives 24 minutes per slot, and we = need slides no later than afternoon 25 March in order to have them = uploaded. In each case, what I would like to see is a presentation that = takes less than half that amount of time and covers the issues raised, = leaving the rest for discussion. Ideally, we come out of each of these = discussions with a decision and/or a game plan to achieve one. There are at least three drafts that people wish were on this agenda; = they're not because I haven't seen operator interest. If you folks are = interested in them, please say so. IPv6 Operations - IETF 83 Monday March 26, 9:00 Agenda bashing =20 Experiences from IPv6-Only Networks with Transition Technologies in the = WIDE Camp Spring 2012 12-Mar-12 , NAT64 Operational Experiences 12-Mar-12 , 464XLAT: Combination of Stateful and Stateless Translation 12-Mar-12 , Stateless Source Address Mapping for ICMPv6 Packets 24-Feb-12 , Basic Requirements for IPv6 Customer Edge Routers 8-Mar-12 , Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) 8-Mar-12 , Thursday March 29, 15:20 Wireline Incremental IPv6 1-Feb-12 , IPv6 Guidance for Internet Content and Application Service Providers 22-Feb-12 , Using the IPv6 Flow Label for Server Load Balancing 6-Mar-12 , Service Provider Wi-Fi Services Over Residential Architectures 11-Mar-12 , Using Only Link-Local Address in Network Core 5-Mar-12 , --Apple-Mail-59--1022435278 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii IPv6 Operations - IETF 83
I'm having some = difficulty uploading to the meeting manager. This is the agenda as we = have it right now. That gives 24 minutes per slot, and we need slides no = later than  afternoon 25 March in order to have them uploaded. In = each case, what I would like to see is a presentation that takes less = than half that amount of time and covers the issues raised, leaving the = rest for discussion. Ideally, we come out of each of these discussions = with a decision and/or a game plan to achieve one.

There are at least = three drafts that people wish were on this agenda; they're not because I = haven't seen operator interest. If you folks are interested in them, = please say so.

IPv6 Operations - IETF 83

Monday March 26, 9:00

Agenda bashing
 
Experiences from IPv6-Only Networks with Transition Technologies in the WIDE Camp Spring 2012
12-Mar-12 , <draft-hazeyama-widecamp-ipv6-only-experience>
NAT64 Operational Experiences
12-Mar-12 , <draft-chen-v6ops-nat64-experience>
464XLAT: Combination of Stateful and Stateless Translation
12-Mar-12 , <draft-ietf-v6ops-464xlat>
Stateless Source Address Mapping for ICMPv6 = Packets
24-Feb-12 , <draft-ietf-v6ops-ivi-icmp-address>
Basic Requirements for IPv6 Customer Edge = Routers
8-Mar-12 , <draft-ietf-v6ops-6204bis>
Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)
8-Mar-12 , = <draft-ietf-v6ops-ra-guard-implementation>

Thursday March 29, 15:20

Wireline Incremental IPv6
1-Feb-12 , <draft-ietf-v6ops-wireline-incremental-ipv6>
IPv6 Guidance for Internet Content and Application Service Providers
22-Feb-12 , <draft-carpenter-v6ops-icp-guidance>
Using the IPv6 Flow Label for Server Load = Balancing
6-Mar-12 , <draft-carpenter-v6ops-label-balance>
Service Provider Wi-Fi Services Over Residential Architectures
11-Mar-12 , <draft-gundavelli-v6ops-community-wifi-svcs>
Using Only Link-Local Address in Network = Core
5-Mar-12 , <draft-behringer-lla-only>
=20

= --Apple-Mail-59--1022435278-- From phdgang@gmail.com Tue Mar 13 01:16:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C13821F8873 for ; Tue, 13 Mar 2012 01:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 4Cb0mStCwitz for ; Tue, 13 Mar 2012 01:16:29 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE1021F885A for ; Tue, 13 Mar 2012 01:16:25 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so278328wib.13 for ; Tue, 13 Mar 2012 01:16:24 -0700 (PDT) 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=5vFhvIIX+1iuvooSnowcspgHN8Uttq299Et827TpJG0=; b=aApTS7cbGkwOcZ6ALcUGEc2GgzQkt4UJqTCOvpkmP916Z7RBDNxCvAIduoijgpPVNW /ozCWC9+PgfCJcHfTtXkSqJ2pwjcOOD8aQN/zuBf5815nWdcezvMuIWSjgeZ+RhUO5vO Wxm+PR4HBya56wOYMZaz9OGdtXq7p693a9olJLJLRKmwOiub42L5E39KAV5fn7MOC4+P gFgtXHpeyKBwRsN80fqWdXN6FWZgCY0m4SX7RDVTO2FsIlaCNlLsBMzh4xC4d4s8eJcg LoI/uRD1JTayF/4HMNUwYChMqqnwjCE0510QpvAoo4avphCYja6qyLJtNhA6dDNU0Ziu oj1Q== MIME-Version: 1.0 Received: by 10.216.133.9 with SMTP id p9mr9292692wei.9.1331626584328; Tue, 13 Mar 2012 01:16:24 -0700 (PDT) Received: by 10.180.7.105 with HTTP; Tue, 13 Mar 2012 01:16:24 -0700 (PDT) In-Reply-To: <4F5E9807.9030403@gmail.com> References: <4F3ABDCB.80004@gmail.com> <4F5E9807.9030403@gmail.com> Date: Tue, 13 Mar 2012 16:16:24 +0800 Message-ID: From: GangChen To: Brian E Carpenter Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Operations Subject: Re: [v6ops] NAT64 performance comparisons X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 08:16:31 -0000 Hello Brian, 1/ Regarding "we expected both NAT mechanisms to be more efficient than the HTTP proxy, since it has to rebuild every packet it receives from each node, executing full TCP processing as well as some application layer copying." just wondering this statement also could apply to "NAT64 vs 6-to-4 load balancer" according to your expectation? 2/ Does the testing involve some fragmentation consideration? 3/I assume all testing context is based on software coding. I guess it could show different behavious if the code is integrated in chip sets. Many thanks Gang 2012/3/13, Brian E Carpenter : > The official handle for this is http://hdl.handle.net/2292/13586 > > Brian > > On 2012-02-15 09:02, Brian E Carpenter wrote: >> On the subject of NAT64, I'v just filed a tech report on some work >> done by Se-young Yu under my supervision. It will get an official >> library handle soon, but here is an ad hoc URL to be going on with: >> >> http://www.cs.auckland.ac.nz/~brian/IPv4-IPv6coexistenceTechnique-TR.pdf >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From despres.remi@laposte.net Tue Mar 13 08:40:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C675821F876D for ; Tue, 13 Mar 2012 08:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] 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 CCkjWbA-3+dX for ; Tue, 13 Mar 2012 08:40:26 -0700 (PDT) Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id B1D6D21F8650 for ; Tue, 13 Mar 2012 08:40:24 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8508-out with ME id l3gN1i00n37Y3f4033gN9q; Tue, 13 Mar 2012 16:40:23 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <25E067CE-65BF-462E-9A45-2D09451256F9@cisco.com> Date: Tue, 13 Mar 2012 16:40:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <23B5B3FA-A0A1-4671-97A9-D8964706344B@laposte.net> References: <25E067CE-65BF-462E-9A45-2D09451256F9@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1084) Cc: v6ops v6ops WG Subject: Re: [v6ops] Agenda discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 15:40:26 -0000 Hi Fred, There has been discussion on the list about the relationship between = 464XLAT and 4rd (24 v6ops e-mails with these 2 acronyms) The latest version of draft-despres-softwire-4rd-U (posted on March 12) = introduces a NAT64 variant called NAT64+. Its purpose is 464XLAT-like scenarios with improved IPv4 transparency. I would appreciate a slot (10 minutes or more) to present what is at = stake, operationally speaking.=20 There is no v6ops-specific draft: time has been too short to make one = despite relevance to v6ops of the subject matter to v6ops. (There is of course no plan to present protocol contents in v6ops, = Softwire being the place for this.) Thanks, RD =20 Le 2012-03-06 =E0 05:46, Fred Baker a =E9crit : > Stated in no particular order, we have the following documents that = meet these criteria: > - not in the IESG process somewhere > - posted or updated since IETF 82 > - have had list discussion since IETF 82 or responds to discussion at = IETF 82 >=20 > At this point, I take them as our agenda at IETF 83. If I am missing a = document (if you have posted it since Sunday, I may well be missing it), = please remind me. >=20 >=20 > http://tools.ietf.org/html/draft-carpenter-v6ops-icp-guidance > "IPv6 Guidance for Internet Content and Application Service = Providers", > Brian Carpenter, Sheng Jiang, 22-Feb-12 >=20 > No presentation expected, but the authors would like working group = adoption. We need to decide whether we want to do that. >=20 > http://tools.ietf.org/html/draft-carpenter-v6ops-label-balance > "Using the IPv6 Flow Label for Server Load Balancing", Brian = Carpenter, > Sheng Jiang, Willy Tarreau, 17-Jan-12 >=20 > http://tools.ietf.org/html/draft-ietf-v6ops-464xlat > "464XLAT: Combination of Stateful and Stateless Translation", = Masataka > Mawatari, Masanobu Kawashima, Cameron Byrne, 14-Feb-12 >=20 > http://tools.ietf.org/html/draft-ietf-v6ops-6204bis > "Basic Requirements for IPv6 Customer Edge Routers", Barbara Stark, > Chris Donley, Hemant Singh, Ole Troan, Wes Beebee, 22-Dec-11 >=20 > http://tools.ietf.org/html/draft-ietf-v6ops-ivi-icmp-address > "Stateless Source Address Mapping for ICMPv6 Packets", Xing Li, = Congxiao > Bao, Dan Wing, Ramji Vaithianathan, Geoff Huston, 24-Feb-12 >=20 > http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation > "Implementation Advice for IPv6 Router Advertisement Guard = (RA-Guard)", > Fernando Gont, 3-Mar-12 >=20 > http://tools.ietf.org/html/draft-ietf-v6ops-wireline-incremental-ipv6 > "Wireline Incremental IPv6", Victor Kuarsingh, Lee Howard, 1-Feb-12 >=20 > In the coming week, I am told to expect one additional -00 draft, and = I could imagine other drafts being updated. I will be looking for those = drafts to meet the criteria above as well, but please drop the chairs a = note. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From brian.e.carpenter@gmail.com Tue Mar 13 13:59:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1E221F85D3 for ; Tue, 13 Mar 2012 13:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.139 X-Spam-Level: X-Spam-Status: No, score=-103.139 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, 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 MaLH95E8HpVr for ; Tue, 13 Mar 2012 13:59:07 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1FE21F8597 for ; Tue, 13 Mar 2012 13:59:07 -0700 (PDT) Received: by yhpp34 with SMTP id p34so1186738yhp.31 for ; Tue, 13 Mar 2012 13:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=PZxkiuAac2aLsjw4vSuNJ8QWL8O4nHg/ySYdr+HgqSo=; b=vaLyKJo7nx6lGwPTaLhhcXpArqBb6khO+miRsLyV4+25+maAHPJOWRVcMJAJ9u+f8G rJKCvZ+PydVev96GQCM1yXt/Jl+Qb60QT9hFZaPrQk50oOEX76JS73RqSsvJQY6df8U2 VCT5H+VUyQu+y+300V/0+yWWNnGGQoXWt0WqEuVNXaxXo/Tj9AUptTlGmDI43QIDMt2O VB+uWHqaAov70tXN/o1lDGxRx2R8iMneRgB4vHsLp+SU6AKRx0BfsLbxH4H1X1wnvLx2 w/22evL8Nf2hQURxskTqPmzH54t//6wvMeCpApuidnPy488EvrNA+hiHwPCLE3SwLPTf 2F7Q== Received: by 10.236.181.5 with SMTP id k5mr18716388yhm.61.1331672347212; Tue, 13 Mar 2012 13:59:07 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz. [130.216.38.124]) by mx.google.com with ESMTPS id i4sm2450346anm.5.2012.03.13.13.59.04 (version=SSLv3 cipher=OTHER); Tue, 13 Mar 2012 13:59:05 -0700 (PDT) Message-ID: <4F5FB516.4020204@gmail.com> Date: Wed, 14 Mar 2012 09:59:02 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: GangChen References: <4F3ABDCB.80004@gmail.com> <4F5E9807.9030403@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IPv6 Operations Subject: Re: [v6ops] NAT64 performance comparisons X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 20:59:09 -0000 Hi Gang, On 2012-03-13 21:16, GangChen wrote: > Hello Brian, > > 1/ Regarding > > "we expected both NAT mechanisms to be more efficient > than the HTTP proxy, since it has to rebuild every packet it > receives from each node, executing full TCP processing as well as > some application layer copying." > > just wondering this statement also could apply to "NAT64 vs 6-to-4 > load balancer" according to your expectation? I'm not sure what method of load balancing you mean, but clearly any method that involves layer 7 processing is at least as slow as an HTTP proxy. > > 2/ Does the testing involve some fragmentation consideration? No. Fragmentation destroys performance anyway, and should clearly be avoided if possible. > > 3/I assume all testing context is based on software coding. I guess it > could show different behavious if the code is integrated in chip sets. Absolutely. Please read the remarks in the Conclusion about this. Brian > > Many thanks > > Gang > > > 2012/3/13, Brian E Carpenter : >> The official handle for this is http://hdl.handle.net/2292/13586 >> >> Brian >> >> On 2012-02-15 09:02, Brian E Carpenter wrote: >>> On the subject of NAT64, I'v just filed a tech report on some work >>> done by Se-young Yu under my supervision. It will get an official >>> library handle soon, but here is an ad hoc URL to be going on with: >>> >>> http://www.cs.auckland.ac.nz/~brian/IPv4-IPv6coexistenceTechnique-TR.pdf >>> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > From phdgang@gmail.com Wed Mar 14 02:04:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA3921F86E1 for ; Wed, 14 Mar 2012 02:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.209 X-Spam-Level: X-Spam-Status: No, score=-3.209 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, J_CHICKENPOX_35=0.6, 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 2HhX7oxc2XcB for ; Wed, 14 Mar 2012 02:04:28 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 695B221F8602 for ; Wed, 14 Mar 2012 02:04:28 -0700 (PDT) Received: by werb10 with SMTP id b10so1742317wer.31 for ; Wed, 14 Mar 2012 02:04:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=xDq7owiUK4VJnLXd3b/RyC3sAYjee8ECnf/7nhZaQro=; b=rK00+gtxI0rHoYxPsS8mjQsyNI//GYzz5Cfu+hM5xwzybxxLYxRCU0xwP+97qaOGeH kxF6gAPcfe3Xt8Pixe78tH1gH/ldb9cpvOP7avIWetLzgr2TYjzrOLt6PHetUseZAkLV 2gUhbeIvlrSoLKO5PbYlgM2mrzOu6ixJm8WUpZnpFPFxsKwJkbsBYM5VsMbZ/KVms8Km orNjlQfoy9HrfkgoAkYxjPdvwGwjsjksC1dwQCsKbMlf0wU/310cZN2cOo8hgq2mlJoc zqpBCRQFfQPe/Os/jc6CFXf2VdRFc0cvr/boEArlM8vP5+G5HZklwVWrwrfBRZEMbyLu 5OkQ== MIME-Version: 1.0 Received: by 10.216.137.97 with SMTP id x75mr1151363wei.25.1331715867309; Wed, 14 Mar 2012 02:04:27 -0700 (PDT) Received: by 10.180.7.105 with HTTP; Wed, 14 Mar 2012 02:04:27 -0700 (PDT) Date: Wed, 14 Mar 2012 17:04:27 +0800 Message-ID: From: GangChen To: v6ops Content-Type: text/plain; charset=ISO-8859-1 Subject: [v6ops] Comments on draft-hazeyama-widecamp-ipv6-only-experience-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 09:04:29 -0000 Hello authors, Generally, the draft provided informative testing data and pointed the failures cases. I guess some failures are related to implementations; some are due to protocol inconsistency. It's better to make categories so it's beneficial for the group identifying the workaround. More detailed: 1. Some testing results have been shown in tables of section 4.2. Wondering to known what reasons cause the data transmission failures in the case of Frag. C => S on table 7. 2. I guess some statements on "dependency between IPv4 and IPv6 address" should be clarified further. 3. In table10, why is the hairpinning not supported? 4rd could do that in hub&spoke mode between CE-CE communications. And 464XLAT adpoted RFC 6146, which could support hairpinning as well. BRs Gang From fred@cisco.com Wed Mar 14 03:38:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DBA821F8725 for ; Wed, 14 Mar 2012 03:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.879 X-Spam-Level: X-Spam-Status: No, score=-109.879 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, 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 1fMCLb3moYq6 for ; Wed, 14 Mar 2012 03:38:33 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8B32F21F8617 for ; Wed, 14 Mar 2012 03:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=4256; q=dns/txt; s=iport; t=1331721513; x=1332931113; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=AoSJVhNYihSSe36weQYM7cPEUcrEbCDhka7cRMAjblM=; b=VRmmg+WLByBeDloEpVrANf8OFm77nFZGK1MEY4/ckpGXhmj6IoWX1+xB 8C4eaEp7RY8SRO7Oz+5fonKT63QkZQgNDaS9ikJrdC+fIPDpZDcJdxmlQ qMUN+ot1Ev4zEWihZ+PQHWv7xwZ5+d9y7fVBU06k2YAZv8rV3EgFVAfJP A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAPlzYE+tJXHB/2dsb2JhbABDthmBB4IJAQEBAwEBAQELBAFSCQQHBQsLRicwBhMih2MFC50EAZ8WkBVjBIhXjH+Fa4o7gwY X-IronPort-AV: E=Sophos;i="4.73,583,1325462400"; d="scan'208";a="66308296" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 14 Mar 2012 10:38:33 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q2EAbNxS012415; Wed, 14 Mar 2012 10:38:32 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Wed, 14 Mar 2012 03:38:32 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Wed, 14 Mar 2012 03:38:32 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <23B5B3FA-A0A1-4671-97A9-D8964706344B@laposte.net> Date: Wed, 14 Mar 2012 03:38:32 -0700 Message-Id: <8AD0DC9E-29C6-4E9D-AB30-4DE1DD37A62B@cisco.com> References: <25E067CE-65BF-462E-9A45-2D09451256F9@cisco.com> <23B5B3FA-A0A1-4671-97A9-D8964706344B@laposte.net> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops v6ops WG Subject: Re: [v6ops] Agenda discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 10:38:34 -0000 On Mar 13, 2012, at 8:40 AM, R=E9mi Despr=E9s wrote: > Hi Fred, >=20 > There has been discussion on the list about the relationship between = 464XLAT and 4rd (24 v6ops e-mails with these 2 acronyms) > The latest version of draft-despres-softwire-4rd-U (posted on March = 12) introduces a NAT64 variant called NAT64+. > Its purpose is 464XLAT-like scenarios with improved IPv4 transparency. >=20 > I would appreciate a slot (10 minutes or more) to present what is at = stake, operationally speaking.=20 > There is no v6ops-specific draft: time has been too short to make one = despite relevance to v6ops of the subject matter to v6ops. > (There is of course no plan to present protocol contents in v6ops, = Softwire being the place for this.) >=20 > Thanks, > RD 4rd and dIVI are two legs of MAP, as I understand it. I was expecting = that discussion during the 464xlat discussion, from the floor, but I'm = willing to give someone ten minutes to present the MAP effort http://datatracker.ietf.org/doc/draft-despres-softwire-4rd-u http://datatracker.ietf.org/doc/draft-fu-softwire-4rd-mib = http://datatracker.ietf.org/doc/draft-mdt-softwire-map-deployment = http://datatracker.ietf.org/doc/draft-mdt-softwire-map-dhcp-option = http://datatracker.ietf.org/doc/draft-mdt-softwire-map-encapsulation = http://datatracker.ietf.org/doc/draft-mdt-softwire-map-translation = http://datatracker.ietf.org/doc/draft-mdt-softwire-mapping-address-and-por= t http://datatracker.ietf.org/doc/draft-murakami-softwire-4rd = http://datatracker.ietf.org/doc/draft-sarikaya-softwire-4rdmulticast and discuss its implications vis-a-vis 464clat. In ten minutes, this is = obviously at a very high level. Do you think you can talk with your = fellow contributors to the MAP effort and find one person who can fairly = the describe all of that? > Le 2012-03-06 =E0 05:46, Fred Baker a =E9crit : >=20 >> Stated in no particular order, we have the following documents that = meet these criteria: >> - not in the IESG process somewhere >> - posted or updated since IETF 82 >> - have had list discussion since IETF 82 or responds to discussion at = IETF 82 >>=20 >> At this point, I take them as our agenda at IETF 83. If I am missing = a document (if you have posted it since Sunday, I may well be missing = it), please remind me. >>=20 >>=20 >> http://tools.ietf.org/html/draft-carpenter-v6ops-icp-guidance >> "IPv6 Guidance for Internet Content and Application Service = Providers", >> Brian Carpenter, Sheng Jiang, 22-Feb-12 >>=20 >> No presentation expected, but the authors would like working group = adoption. We need to decide whether we want to do that. >>=20 >> http://tools.ietf.org/html/draft-carpenter-v6ops-label-balance >> "Using the IPv6 Flow Label for Server Load Balancing", Brian = Carpenter, >> Sheng Jiang, Willy Tarreau, 17-Jan-12 >>=20 >> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat >> "464XLAT: Combination of Stateful and Stateless Translation", = Masataka >> Mawatari, Masanobu Kawashima, Cameron Byrne, 14-Feb-12 >>=20 >> http://tools.ietf.org/html/draft-ietf-v6ops-6204bis >> "Basic Requirements for IPv6 Customer Edge Routers", Barbara Stark, >> Chris Donley, Hemant Singh, Ole Troan, Wes Beebee, 22-Dec-11 >>=20 >> http://tools.ietf.org/html/draft-ietf-v6ops-ivi-icmp-address >> "Stateless Source Address Mapping for ICMPv6 Packets", Xing Li, = Congxiao >> Bao, Dan Wing, Ramji Vaithianathan, Geoff Huston, 24-Feb-12 >>=20 >> http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation >> "Implementation Advice for IPv6 Router Advertisement Guard = (RA-Guard)", >> Fernando Gont, 3-Mar-12 >>=20 >> http://tools.ietf.org/html/draft-ietf-v6ops-wireline-incremental-ipv6 >> "Wireline Incremental IPv6", Victor Kuarsingh, Lee Howard, 1-Feb-12 >>=20 >> In the coming week, I am told to expect one additional -00 draft, and = I could imagine other drafts being updated. I will be looking for those = drafts to meet the criteria above as well, but please drop the chairs a = note. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 From ales.vizdal@t-mobile.cz Wed Mar 14 03:46:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D1EB21F8732 for ; Wed, 14 Mar 2012 03:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] 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 odh+Pz5PVfzY for ; Wed, 14 Mar 2012 03:46:29 -0700 (PDT) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id B0D6621F8720 for ; Wed, 14 Mar 2012 03:46:29 -0700 (PDT) Received: from srvhk504.rdm.cz (unknown [10.246.143.96]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 709FC285812; Wed, 14 Mar 2012 11:46:28 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk504.rdm.cz ([fe80::506:b9a6:d353:9494%12]) with mapi; Wed, 14 Mar 2012 11:46:28 +0100 From: =?iso-8859-2?Q?V=EDzdal_Ale=B9?= To: "Rajiv Asati (rajiva)" Date: Wed, 14 Mar 2012 11:46:54 +0100 Thread-Topic: [v6ops] New Draft: Using Only Link-Local Address in Network Core Thread-Index: Acz9YhoQ+GW7xSELR5CiRs4yt5tddQAB79/AARlYmAA= Message-ID: <1808340F7EC362469DDFFB112B37E2FCC67EDAA619@SRVHKE02.rdm.cz> References: <51865E1A72F61D48A247348DCCBA5CFB05B9154C@XMB-AMS-105.cisco.com> <20120308173038.GI84425@Space.Net> <20120308173712.GT22535@angus.ind.WPI.EDU><20120308175526.GK84425@Space.Net> <4F59090D.8000901@gmail.com> <067E6CE33034954AAC05C9EC85E2577C0795D56A@XMB-RCD-111.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577C0795D56A@XMB-RCD-111.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 10:46:30 -0000 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= Rajiv > Asati (rajiva) > Sent: Thursday, March 08, 2012 9:29 PM > To: Brian E Carpenter; Gert Doering > Cc: v6ops@ietf.org > Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network = Core =20 > Sure, it could be informational. > But why would we not want it to be a BCP? Because it does not seem to be widely adopted as the BCP, an informational = track would suit it better. > Cheers > Rajiv Cheers, Ales From despres.remi@laposte.net Wed Mar 14 04:23:48 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7ABB21F8532 for ; Wed, 14 Mar 2012 04:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[AWL=-0.237, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] 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 E+7GCIjMldqy for ; Wed, 14 Mar 2012 04:23:48 -0700 (PDT) Received: from smtpout.laposte.net (smtpout3.laposte.net [193.253.67.228]) by ietfa.amsl.com (Postfix) with ESMTP id B4AA821F8539 for ; Wed, 14 Mar 2012 04:23:47 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8506-out with ME id lPPk1i00737Y3f403PPkJq; Wed, 14 Mar 2012 12:23:45 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <8AD0DC9E-29C6-4E9D-AB30-4DE1DD37A62B@cisco.com> Date: Wed, 14 Mar 2012 12:23:43 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <25E067CE-65BF-462E-9A45-2D09451256F9@cisco.com> <23B5B3FA-A0A1-4671-97A9-D8964706344B@laposte.net> <8AD0DC9E-29C6-4E9D-AB30-4DE1DD37A62B@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1084) Cc: v6ops v6ops WG Subject: Re: [v6ops] Agenda discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 11:23:48 -0000 Fred, 2012-03-14 11:38, Fred Baker: >=20 > On Mar 13, 2012, at 8:40 AM, R=E9mi Despr=E9s wrote: >=20 >> Hi Fred, >>=20 >> There has been discussion on the list about the relationship between = 464XLAT and 4rd (24 v6ops e-mails with these 2 acronyms) >> The latest version of draft-despres-softwire-4rd-U (posted on March = 12) introduces a NAT64 variant called NAT64+. >> Its purpose is 464XLAT-like scenarios with improved IPv4 = transparency. >>=20 >> I would appreciate a slot (10 minutes or more) to present what is at = stake, operationally speaking.=20 >> There is no v6ops-specific draft: time has been too short to make one = despite relevance to v6ops of the subject matter to v6ops. >> (There is of course no plan to present protocol contents in v6ops, = Softwire being the place for this.) This is only based on a small part of the latest 4rd-u draft. There is definitely no need to present all other documents you listed = below. I do believe that, in 10 min, I can usefully inform the v6ops WG about = the relationship between 464XLAT and 4rd. Regards, RD >>=20 >> Thanks, >> RD >=20 > 4rd and dIVI are two legs of MAP, as I understand it. I was expecting = that discussion during the 464xlat discussion, from the floor, but I'm = willing to give someone ten minutes to present the MAP effort >=20 > http://datatracker.ietf.org/doc/draft-despres-softwire-4rd-u > http://datatracker.ietf.org/doc/draft-fu-softwire-4rd-mib > = http://datatracker.ietf.org/doc/draft-mdt-softwire-map-deployment > = http://datatracker.ietf.org/doc/draft-mdt-softwire-map-dhcp-option > = http://datatracker.ietf.org/doc/draft-mdt-softwire-map-encapsulation > = http://datatracker.ietf.org/doc/draft-mdt-softwire-map-translation > = http://datatracker.ietf.org/doc/draft-mdt-softwire-mapping-address-and-por= t > http://datatracker.ietf.org/doc/draft-murakami-softwire-4rd > = http://datatracker.ietf.org/doc/draft-sarikaya-softwire-4rdmulticast >=20 > and discuss its implications vis-a-vis 464clat. In ten minutes, this = is obviously at a very high level. Do you think you can talk with your = fellow contributors to the MAP effort and find one person who can fairly = the describe all of that? >=20 >> Le 2012-03-06 =E0 05:46, Fred Baker a =E9crit : >>=20 >>> Stated in no particular order, we have the following documents that = meet these criteria: >>> - not in the IESG process somewhere >>> - posted or updated since IETF 82 >>> - have had list discussion since IETF 82 or responds to discussion = at IETF 82 >>>=20 >>> At this point, I take them as our agenda at IETF 83. If I am missing = a document (if you have posted it since Sunday, I may well be missing = it), please remind me. >>>=20 >>>=20 >>> http://tools.ietf.org/html/draft-carpenter-v6ops-icp-guidance >>> "IPv6 Guidance for Internet Content and Application Service = Providers", >>> Brian Carpenter, Sheng Jiang, 22-Feb-12 >>>=20 >>> No presentation expected, but the authors would like working group = adoption. We need to decide whether we want to do that. >>>=20 >>> http://tools.ietf.org/html/draft-carpenter-v6ops-label-balance >>> "Using the IPv6 Flow Label for Server Load Balancing", Brian = Carpenter, >>> Sheng Jiang, Willy Tarreau, 17-Jan-12 >>>=20 >>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat >>> "464XLAT: Combination of Stateful and Stateless Translation", = Masataka >>> Mawatari, Masanobu Kawashima, Cameron Byrne, 14-Feb-12 >>>=20 >>> http://tools.ietf.org/html/draft-ietf-v6ops-6204bis >>> "Basic Requirements for IPv6 Customer Edge Routers", Barbara Stark, >>> Chris Donley, Hemant Singh, Ole Troan, Wes Beebee, 22-Dec-11 >>>=20 >>> http://tools.ietf.org/html/draft-ietf-v6ops-ivi-icmp-address >>> "Stateless Source Address Mapping for ICMPv6 Packets", Xing Li, = Congxiao >>> Bao, Dan Wing, Ramji Vaithianathan, Geoff Huston, 24-Feb-12 >>>=20 >>> http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation >>> "Implementation Advice for IPv6 Router Advertisement Guard = (RA-Guard)", >>> Fernando Gont, 3-Mar-12 >>>=20 >>> = http://tools.ietf.org/html/draft-ietf-v6ops-wireline-incremental-ipv6 >>> "Wireline Incremental IPv6", Victor Kuarsingh, Lee Howard, 1-Feb-12 >>>=20 >>> In the coming week, I am told to expect one additional -00 draft, = and I could imagine other drafts being updated. I will be looking for = those drafts to meet the criteria above as well, but please drop the = chairs a note. >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 >=20 From tom.taylor.stds@gmail.com Wed Mar 14 06:22:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1BB21F8750 for ; Wed, 14 Mar 2012 06:22:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.073 X-Spam-Level: X-Spam-Status: No, score=-3.073 tagged_above=-999 required=5 tests=[AWL=-0.374, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, 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 y5ldztcF4JLZ for ; Wed, 14 Mar 2012 06:22:36 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6210021F874A for ; Wed, 14 Mar 2012 06:22:35 -0700 (PDT) Received: by eeke51 with SMTP id e51so931524eek.31 for ; Wed, 14 Mar 2012 06:22:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=th8B6t8VYIibSCGpVb4tR4IXXxBVcayGKld4VIcoft8=; b=iSlI4xy1ebz4vAsbsVlAp7puoXTzllYTsl1KTCGrjk/pfkU030zArpAncao52Pws7o 6Yi6xePFNs5qz2VsYoGr30ZzxCGChD/XXcuxBM0k4f7MTgVZlHUBQXpwGUFVmoFiz9zv V/w8OftzfuaPNZxiGCIBZapVT4n4qFQbpb5GeeEH+yh57z9d2RIHbQbHAJvNhACHN2rp pMF0lHXhTebQWCP84J9Yx4AaNpJJxCWAZUCy1TsS4MgTUDGzk8x2Ta/o6rQe0VdnorCV RiEDTswUPv9ihj5QdDEb5P43Q7zAPJgL9O/9Ek2MPNU29lO89pL1VH4nsOmnFhOYEULq eGcw== Received: by 10.50.190.226 with SMTP id gt2mr11778146igc.32.1331731353989; Wed, 14 Mar 2012 06:22:33 -0700 (PDT) Received: from [127.0.0.1] (dsl-173-206-162-18.tor.primus.ca. [173.206.162.18]) by mx.google.com with ESMTPS id t8sm10542910igw.0.2012.03.14.06.22.31 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 14 Mar 2012 06:22:33 -0700 (PDT) Message-ID: <4F609B96.90409@gmail.com> Date: Wed, 14 Mar 2012 09:22:30 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= , IPv6 Ops WG , Fred Baker References: <25E067CE-65BF-462E-9A45-2D09451256F9@cisco.com> <23B5B3FA-A0A1-4671-97A9-D8964706344B@laposte.net> <8AD0DC9E-29C6-4E9D-AB30-4DE1DD37A62B@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 120314-0, 14/03/2012), Outbound message X-Antivirus-Status: Clean Subject: Re: [v6ops] Agenda discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 13:22:37 -0000 Perhaps it would be useful to know that Rémi's 4rd-U is actually a competitor to MAP. On 14/03/2012 7:23 AM, Rémi Després wrote: > Fred, > > 2012-03-14 11:38, Fred Baker: > >> >> On Mar 13, 2012, at 8:40 AM, Rémi Després wrote: >> >>> Hi Fred, >>> >>> There has been discussion on the list about the relationship between 464XLAT and 4rd (24 v6ops e-mails with these 2 acronyms) >>> The latest version of draft-despres-softwire-4rd-U (posted on March 12) introduces a NAT64 variant called NAT64+. >>> Its purpose is 464XLAT-like scenarios with improved IPv4 transparency. >>> >>> I would appreciate a slot (10 minutes or more) to present what is at stake, operationally speaking. >>> There is no v6ops-specific draft: time has been too short to make one despite relevance to v6ops of the subject matter to v6ops. >>> (There is of course no plan to present protocol contents in v6ops, Softwire being the place for this.) > > This is only based on a small part of the latest 4rd-u draft. > There is definitely no need to present all other documents you listed below. > I do believe that, in 10 min, I can usefully inform the v6ops WG about the relationship between 464XLAT and 4rd. > > Regards, > RD > > > > >>> >>> Thanks, >>> RD >> >> 4rd and dIVI are two legs of MAP, as I understand it. I was expecting that discussion during the 464xlat discussion, from the floor, but I'm willing to give someone ten minutes to present the MAP effort >> >> http://datatracker.ietf.org/doc/draft-despres-softwire-4rd-u >> http://datatracker.ietf.org/doc/draft-fu-softwire-4rd-mib >> http://datatracker.ietf.org/doc/draft-mdt-softwire-map-deployment >> http://datatracker.ietf.org/doc/draft-mdt-softwire-map-dhcp-option >> http://datatracker.ietf.org/doc/draft-mdt-softwire-map-encapsulation >> http://datatracker.ietf.org/doc/draft-mdt-softwire-map-translation >> http://datatracker.ietf.org/doc/draft-mdt-softwire-mapping-address-and-port >> http://datatracker.ietf.org/doc/draft-murakami-softwire-4rd >> http://datatracker.ietf.org/doc/draft-sarikaya-softwire-4rdmulticast >> >> and discuss its implications vis-a-vis 464clat. In ten minutes, this is obviously at a very high level. Do you think you can talk with your fellow contributors to the MAP effort and find one person who can fairly the describe all of that? >> >>> Le 2012-03-06 à 05:46, Fred Baker a écrit : >>> >>>> Stated in no particular order, we have the following documents that meet these criteria: >>>> - not in the IESG process somewhere >>>> - posted or updated since IETF 82 >>>> - have had list discussion since IETF 82 or responds to discussion at IETF 82 >>>> >>>> At this point, I take them as our agenda at IETF 83. If I am missing a document (if you have posted it since Sunday, I may well be missing it), please remind me. >>>> >>>> >>>> http://tools.ietf.org/html/draft-carpenter-v6ops-icp-guidance >>>> "IPv6 Guidance for Internet Content and Application Service Providers", >>>> Brian Carpenter, Sheng Jiang, 22-Feb-12 >>>> >>>> No presentation expected, but the authors would like working group adoption. We need to decide whether we want to do that. >>>> >>>> http://tools.ietf.org/html/draft-carpenter-v6ops-label-balance >>>> "Using the IPv6 Flow Label for Server Load Balancing", Brian Carpenter, >>>> Sheng Jiang, Willy Tarreau, 17-Jan-12 >>>> >>>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat >>>> "464XLAT: Combination of Stateful and Stateless Translation", Masataka >>>> Mawatari, Masanobu Kawashima, Cameron Byrne, 14-Feb-12 >>>> >>>> http://tools.ietf.org/html/draft-ietf-v6ops-6204bis >>>> "Basic Requirements for IPv6 Customer Edge Routers", Barbara Stark, >>>> Chris Donley, Hemant Singh, Ole Troan, Wes Beebee, 22-Dec-11 >>>> >>>> http://tools.ietf.org/html/draft-ietf-v6ops-ivi-icmp-address >>>> "Stateless Source Address Mapping for ICMPv6 Packets", Xing Li, Congxiao >>>> Bao, Dan Wing, Ramji Vaithianathan, Geoff Huston, 24-Feb-12 >>>> >>>> http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation >>>> "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", >>>> Fernando Gont, 3-Mar-12 >>>> >>>> http://tools.ietf.org/html/draft-ietf-v6ops-wireline-incremental-ipv6 >>>> "Wireline Incremental IPv6", Victor Kuarsingh, Lee Howard, 1-Feb-12 >>>> >>>> In the coming week, I am told to expect one additional -00 draft, and I could imagine other drafts being updated. I will be looking for those drafts to meet the criteria above as well, but please drop the chairs a note. >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>> >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From cb.list6@gmail.com Wed Mar 14 06:32:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35C8321F86F3 for ; Wed, 14 Mar 2012 06:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.165 X-Spam-Level: X-Spam-Status: No, score=-3.165 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 BAB2HtibbObo for ; Wed, 14 Mar 2012 06:32:01 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 222F821F86EE for ; Wed, 14 Mar 2012 06:32:01 -0700 (PDT) Received: by dald2 with SMTP id d2so3899226dal.27 for ; Wed, 14 Mar 2012 06:32:00 -0700 (PDT) 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=5PHyMMLxfsuMfNJ2uFq/nE+ehHhM4q2nOIQoLtdQk14=; b=YJfISjrSQAT6D470U3NaYu5KUoZz8MVxH7TLaqWlNrtQdpHrinhsf7teyesIYjKp3w 2GUrTTtjdYfXZiC8kjThqwm1SZPG6sv7NpAxHgN6UmRLqvL71uW0jHuAFZMKxsEkBMx7 ig6fU53ZtGFJBS/BVvMZXVEMYtUSqU9Nvz4ogwQEESL4UR8i8eaq23dHq0te1mt/4VtI WC5w8BakahSiK1xodgTvDsfBfd9EfrrbowUcZ1cKnsxtf7InTM4HHnmUVwJzrrAO/53A afwkVsaV5n3geZ0PVuG2Sf8CtRvtwhh8JrCnZgwT8V5j5Y9KnHb8dcJ8V91WnMGoAzHX QblQ== MIME-Version: 1.0 Received: by 10.68.234.41 with SMTP id ub9mr3117198pbc.106.1331731920830; Wed, 14 Mar 2012 06:32:00 -0700 (PDT) Received: by 10.142.163.16 with HTTP; Wed, 14 Mar 2012 06:32:00 -0700 (PDT) Received: by 10.142.163.16 with HTTP; Wed, 14 Mar 2012 06:32:00 -0700 (PDT) In-Reply-To: <4F609B96.90409@gmail.com> References: <25E067CE-65BF-462E-9A45-2D09451256F9@cisco.com> <23B5B3FA-A0A1-4671-97A9-D8964706344B@laposte.net> <8AD0DC9E-29C6-4E9D-AB30-4DE1DD37A62B@cisco.com> <4F609B96.90409@gmail.com> Date: Wed, 14 Mar 2012 06:32:00 -0700 Message-ID: From: Cameron Byrne To: Tom Taylor Content-Type: multipart/alternative; boundary=047d7b33d95613c05604bb34006c Cc: IPv6 Ops WG Subject: Re: [v6ops] Agenda discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 13:32:02 -0000 --047d7b33d95613c05604bb34006c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mar 14, 2012 6:22 AM, "Tom Taylor" wrote: > > Perhaps it would be useful to know that R=E9mi's 4rd-U is actually a competitor to MAP. > > Yep. And they both see 464xlat as a competitor. I oppose bringing this "mine is better than yours" story to the floor. It has not been productive on the list and it will be less productive in person where it is harder to counter the hand waving arguments (like concerns about a /96 that have been addressed clearly on the list and seems to be only the interest of one person) The stateless solutions have a place in softwires. Once they have operational scenarios and deployment lessons learned, they will fit v6ops. Cb > On 14/03/2012 7:23 AM, R=E9mi Despr=E9s wrote: >> >> Fred, >> >> 2012-03-14 11:38, Fred Baker: >> >>> >>> On Mar 13, 2012, at 8:40 AM, R=E9mi Despr=E9s wrote: >>> >>>> Hi Fred, >>>> >>>> There has been discussion on the list about the relationship between 464XLAT and 4rd (24 v6ops e-mails with these 2 acronyms) >>>> The latest version of draft-despres-softwire-4rd-U (posted on March 12) introduces a NAT64 variant called NAT64+. >>>> Its purpose is 464XLAT-like scenarios with improved IPv4 transparency. >>>> >>>> I would appreciate a slot (10 minutes or more) to present what is at stake, operationally speaking. >>>> There is no v6ops-specific draft: time has been too short to make one despite relevance to v6ops of the subject matter to v6ops. >>>> (There is of course no plan to present protocol contents in v6ops, Softwire being the place for this.) >> >> >> This is only based on a small part of the latest 4rd-u draft. >> There is definitely no need to present all other documents you listed below. >> I do believe that, in 10 min, I can usefully inform the v6ops WG about the relationship between 464XLAT and 4rd. >> >> Regards, >> RD >> >> >> >> >>>> >>>> Thanks, >>>> RD >>> >>> >>> 4rd and dIVI are two legs of MAP, as I understand it. I was expecting that discussion during the 464xlat discussion, from the floor, but I'm willing to give someone ten minutes to present the MAP effort >>> >>> http://datatracker.ietf.org/doc/draft-despres-softwire-4rd-u >>> http://datatracker.ietf.org/doc/draft-fu-softwire-4rd-mib >>> http://datatracker.ietf.org/doc/draft-mdt-softwire-map-deploymen= t >>> http://datatracker.ietf.org/doc/draft-mdt-softwire-map-dhcp-option >>> http://datatracker.ietf.org/doc/draft-mdt-softwire-map-encapsulation >>> http://datatracker.ietf.org/doc/draft-mdt-softwire-map-translation >>> http://datatracker.ietf.org/doc/draft-mdt-softwire-mapping-address-and-port >>> http://datatracker.ietf.org/doc/draft-murakami-softwire-4rd >>> http://datatracker.ietf.org/doc/draft-sarikaya-softwire-4rdmulticast >>> >>> and discuss its implications vis-a-vis 464clat. In ten minutes, this is obviously at a very high level. Do you think you can talk with your fellow contributors to the MAP effort and find one person who can fairly the describe all of that? >>> >>>> Le 2012-03-06 =E0 05:46, Fred Baker a =E9crit : >>>> >>>>> Stated in no particular order, we have the following documents that meet these criteria: >>>>> - not in the IESG process somewhere >>>>> - posted or updated since IETF 82 >>>>> - have had list discussion since IETF 82 or responds to discussion at IETF 82 >>>>> >>>>> At this point, I take them as our agenda at IETF 83. If I am missing a document (if you have posted it since Sunday, I may well be missing it), please remind me. >>>>> >>>>> >>>>> http://tools.ietf.org/html/draft-carpenter-v6ops-icp-guidance >>>>> "IPv6 Guidance for Internet Content and Application Service Providers", >>>>> Brian Carpenter, Sheng Jiang, 22-Feb-12 >>>>> >>>>> No presentation expected, but the authors would like working group adoption. We need to decide whether we want to do that. >>>>> >>>>> http://tools.ietf.org/html/draft-carpenter-v6ops-label-balance >>>>> "Using the IPv6 Flow Label for Server Load Balancing", Brian Carpenter, >>>>> Sheng Jiang, Willy Tarreau, 17-Jan-12 >>>>> >>>>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat >>>>> "464XLAT: Combination of Stateful and Stateless Translation", Masatak= a >>>>> Mawatari, Masanobu Kawashima, Cameron Byrne, 14-Feb-12 >>>>> >>>>> http://tools.ietf.org/html/draft-ietf-v6ops-6204bis >>>>> "Basic Requirements for IPv6 Customer Edge Routers", Barbara Stark, >>>>> Chris Donley, Hemant Singh, Ole Troan, Wes Beebee, 22-Dec-11 >>>>> >>>>> http://tools.ietf.org/html/draft-ietf-v6ops-ivi-icmp-address >>>>> "Stateless Source Address Mapping for ICMPv6 Packets", Xing Li, Congxiao >>>>> Bao, Dan Wing, Ramji Vaithianathan, Geoff Huston, 24-Feb-12 >>>>> >>>>> http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation >>>>> "Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)", >>>>> Fernando Gont, 3-Mar-12 >>>>> >>>>> http://tools.ietf.org/html/draft-ietf-v6ops-wireline-incremental-ipv6 >>>>> "Wireline Incremental IPv6", Victor Kuarsingh, Lee Howard, 1-Feb-12 >>>>> >>>>> In the coming week, I am told to expect one additional -00 draft, and I could imagine other drafts being updated. I will be looking for those drafts to meet the criteria above as well, but please drop the chairs a note. >>>>> _______________________________________________ >>>>> v6ops mailing list >>>>> v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>> >>>> >>> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --047d7b33d95613c05604bb34006c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mar 14, 2012 6:22 AM, "Tom Taylor" <tom.taylor.stds@gmail.com> wrote:
>
> Perhaps it would be useful to know that R=E9mi's 4rd-U is actually= a competitor to MAP.
>
>

Yep. And they both see 464xlat as a competitor.

I oppose bringing this "mine is better than yours" story to th= e floor. It has not been productive on the list and it will be less product= ive in person where it is harder to counter the hand waving arguments (like= concerns about a /96 that have been addressed clearly on the list and seem= s to be only the interest of one person)

The stateless solutions have a place in softwires. Once they have operat= ional scenarios and deployment lessons learned, they will fit v6ops.

Cb
> On 14/03/2012 7:23 AM, R=E9mi Despr=E9s wrote:
>>
>> Fred,
>>
>> 2012-03-14 11:38, Fred Baker:
>>
>>>
>>> On Mar 13, 2012, at 8:40 AM, R=E9mi Despr=E9s wrote:
>>>
>>>> Hi Fred,
>>>>
>>>> There has been discussion on the list about the relationsh= ip between 464XLAT and 4rd (24 v6ops e-mails with these 2 acronyms)
>>>> The latest version of draft-despres-softwire-4rd-U (posted= on March 12) introduces a NAT64 variant called NAT64+.
>>>> Its purpose is 464XLAT-like scenarios with improved IPv4 t= ransparency.
>>>>
>>>> I would appreciate a slot (10 minutes or more) to present = what is at stake, operationally speaking.
>>>> There is no v6ops-specific draft: time has been too short = to make one despite relevance to v6ops of the subject matter to v6ops.
>>>> (There is of course no plan to present protocol contents i= n v6ops, Softwire being the place for this.)
>>
>>
>> This is only based on a small part of the latest 4rd-u draft.
>> There is definitely no need to present all other documents you lis= ted below.
>> I do believe that, in 10 min, I can usefully inform the v6ops WG a= bout the relationship between 464XLAT and 4rd.
>>
>> Regards,
>> RD
>>
>>
>>
>>
>>>>
>>>> Thanks,
>>>> RD
>>>
>>>
>>> 4rd and dIVI are two legs of MAP, as I understand it. I was ex= pecting that discussion during the 464xlat discussion, from the floor, but = I'm willing to give someone ten minutes to present the MAP effort
>>>
>>> =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-despres-sof= twire-4rd-u
>>> =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-fu-softwire-4r= d-mib
>>> =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-mdt-so= ftwire-map-deployment
>>> =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-mdt-s= oftwire-map-dhcp-option
>>> =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-mdt= -softwire-map-encapsulation
>>> =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-mdt-s= oftwire-map-translation
>>> =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/dr= aft-mdt-softwire-mapping-address-and-port
>>> =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-murakami-sof= twire-4rd
>>> =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-sar= ikaya-softwire-4rdmulticast
>>>
>>> and discuss its implications vis-a-vis 464clat. In ten minutes= , this is obviously at a very high level. Do you think you can talk with yo= ur fellow contributors to the MAP effort and find one person who can fairly= the describe all of that?
>>>
>>>> Le 2012-03-06 =E0 05:46, Fred Baker a =E9crit :
>>>>
>>>>> Stated in no particular order, we have the following d= ocuments that meet these criteria:
>>>>> - not in the IESG process somewhere
>>>>> - posted or updated since IETF 82
>>>>> - have had list discussion since IETF 82 or responds t= o discussion at IETF 82
>>>>>
>>>>> At this point, I take them as our agenda at IETF 83. I= f I am missing a document (if you have posted it since Sunday, I may well b= e missing it), please remind me.
>>>>>
>>>>>
>>>>> http://tools.ietf.org/html/draft-carpenter-v6ops-icp-gu= idance
>>>>> "IPv6 Guidance for Internet Content and Applicati= on Service Providers",
>>>>> Brian Carpenter, Sheng Jiang, 22-Feb-12
>>>>>
>>>>> No presentation expected, but the authors would like w= orking group adoption. We need to decide whether we want to do that.
>>>>>
>>>>> http://tools.ietf.org/html/draft-carpenter-v6ops-label= -balance
>>>>> "Using the IPv6 Flow Label for Server Load Balanc= ing", Brian Carpenter,
>>>>> Sheng Jiang, Willy Tarreau, 17-Jan-12
>>>>>
>>>>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat
>>>>> "464XLAT: Combination of Stateful and Stateless T= ranslation", Masataka
>>>>> Mawatari, Masanobu Kawashima, Cameron Byrne, 14-Feb-12=
>>>>>
>>>>> http://tools.ietf.org/html/draft-ietf-v6ops-6204bis
>>>>> "Basic Requirements for IPv6 Customer Edge Router= s", Barbara Stark,
>>>>> Chris Donley, Hemant Singh, Ole Troan, Wes Beebee, 22-= Dec-11
>>>>>
>>>>> http://tools.ietf.org/html/draft-ietf-v6ops-ivi-icmp-add= ress
>>>>> "Stateless Source Address Mapping for ICMPv6 Pack= ets", Xing Li, Congxiao
>>>>> Bao, Dan Wing, Ramji Vaithianathan, Geoff Huston, 24-F= eb-12
>>>>>
>>>>> http://tools.ietf.org/html/draft-ietf-v6ops-ra-gu= ard-implementation
>>>>> "Implementation Advice for IPv6 Router Advertisem= ent Guard (RA-Guard)",
>>>>> Fernando Gont, 3-Mar-12
>>>>>
>>>>> http://tools.ietf.org/html/draft-ietf-v6ops-wir= eline-incremental-ipv6
>>>>> "Wireline Incremental IPv6", Victor Kuarsing= h, Lee Howard, 1-Feb-12
>>>>>
>>>>> In the coming week, I am told to expect one additional= -00 draft, and I could imagine other drafts being updated. I will be looki= ng for those drafts to meet the criteria above as well, but please drop the= chairs a note.
>>>>> _______________________________________________
>>>>> v6ops mailing list
>>>>> v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://ww= w.ietf.org/mailman/listinfo/v6ops
>>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops

--047d7b33d95613c05604bb34006c-- From despres.remi@laposte.net Wed Mar 14 06:33:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0650021F86F8 for ; Wed, 14 Mar 2012 06:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.931 X-Spam-Level: X-Spam-Status: No, score=-1.931 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] 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 iaFuHCk+5LXf for ; Wed, 14 Mar 2012 06:33:34 -0700 (PDT) Received: from smtpout.laposte.net (smtpout5.laposte.net [193.253.67.230]) by ietfa.amsl.com (Postfix) with ESMTP id 61DD221F86F3 for ; Wed, 14 Mar 2012 06:33:34 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8509-out with ME id lRZZ1i00837Y3f403RZZq8; Wed, 14 Mar 2012 14:33:33 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4F609B96.90409@gmail.com> Date: Wed, 14 Mar 2012 14:33:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <25E067CE-65BF-462E-9A45-2D09451256F9@cisco.com> <23B5B3FA-A0A1-4671-97A9-D8964706344B@laposte.net> <8AD0DC9E-29C6-4E9D-AB30-4DE1DD37A62B@cisco.com> <4F609B96.90409@gmail.com> To: Tom Taylor X-Mailer: Apple Mail (2.1084) Cc: IPv6 Ops WG Subject: Re: [v6ops] Agenda discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 13:33:37 -0000 Le 2012-03-14 =E0 14:22, Tom Taylor a =E9crit : > Perhaps it would be useful to know that R=E9mi's 4rd-U is actually a = competitor to MAP. Yes, indeed. 4rd is proposed as a unified standard, expected to replace the two = standards of the MAP proposal, but the two designs have otherwise a lot = in common. That said, the point to be presented in v6ops is the relationship = between 4rd and 464XLAT, while such a relationship hasn't been = considered so far for MAP. Regards, RD >=20 > On 14/03/2012 7:23 AM, R=E9mi Despr=E9s wrote: >> Fred, >>=20 >> 2012-03-14 11:38, Fred Baker: >>=20 >>>=20 >>> On Mar 13, 2012, at 8:40 AM, R=E9mi Despr=E9s wrote: >>>=20 >>>> Hi Fred, >>>>=20 >>>> There has been discussion on the list about the relationship = between 464XLAT and 4rd (24 v6ops e-mails with these 2 acronyms) >>>> The latest version of draft-despres-softwire-4rd-U (posted on March = 12) introduces a NAT64 variant called NAT64+. >>>> Its purpose is 464XLAT-like scenarios with improved IPv4 = transparency. >>>>=20 >>>> I would appreciate a slot (10 minutes or more) to present what is = at stake, operationally speaking. >>>> There is no v6ops-specific draft: time has been too short to make = one despite relevance to v6ops of the subject matter to v6ops. >>>> (There is of course no plan to present protocol contents in v6ops, = Softwire being the place for this.) >>=20 >> This is only based on a small part of the latest 4rd-u draft. >> There is definitely no need to present all other documents you listed = below. >> I do believe that, in 10 min, I can usefully inform the v6ops WG = about the relationship between 464XLAT and 4rd. >>=20 >> Regards, >> RD >>=20 >>=20 >>=20 >>=20 >>>>=20 >>>> Thanks, >>>> RD >>>=20 >>> 4rd and dIVI are two legs of MAP, as I understand it. I was = expecting that discussion during the 464xlat discussion, from the floor, = but I'm willing to give someone ten minutes to present the MAP effort >>>=20 >>> http://datatracker.ietf.org/doc/draft-despres-softwire-4rd-u >>> http://datatracker.ietf.org/doc/draft-fu-softwire-4rd-mib >>> = http://datatracker.ietf.org/doc/draft-mdt-softwire-map-deployment >>> = http://datatracker.ietf.org/doc/draft-mdt-softwire-map-dhcp-option >>> = http://datatracker.ietf.org/doc/draft-mdt-softwire-map-encapsulation >>> = http://datatracker.ietf.org/doc/draft-mdt-softwire-map-translation >>> = http://datatracker.ietf.org/doc/draft-mdt-softwire-mapping-address-and-por= t >>> http://datatracker.ietf.org/doc/draft-murakami-softwire-4rd >>> = http://datatracker.ietf.org/doc/draft-sarikaya-softwire-4rdmulticast >>>=20 >>> and discuss its implications vis-a-vis 464clat. In ten minutes, this = is obviously at a very high level. Do you think you can talk with your = fellow contributors to the MAP effort and find one person who can fairly = the describe all of that? >>>=20 >>>> Le 2012-03-06 =E0 05:46, Fred Baker a =E9crit : >>>>=20 >>>>> Stated in no particular order, we have the following documents = that meet these criteria: >>>>> - not in the IESG process somewhere >>>>> - posted or updated since IETF 82 >>>>> - have had list discussion since IETF 82 or responds to discussion = at IETF 82 >>>>>=20 >>>>> At this point, I take them as our agenda at IETF 83. If I am = missing a document (if you have posted it since Sunday, I may well be = missing it), please remind me. >>>>>=20 >>>>>=20 >>>>> http://tools.ietf.org/html/draft-carpenter-v6ops-icp-guidance >>>>> "IPv6 Guidance for Internet Content and Application Service = Providers", >>>>> Brian Carpenter, Sheng Jiang, 22-Feb-12 >>>>>=20 >>>>> No presentation expected, but the authors would like working group = adoption. We need to decide whether we want to do that. >>>>>=20 >>>>> http://tools.ietf.org/html/draft-carpenter-v6ops-label-balance >>>>> "Using the IPv6 Flow Label for Server Load Balancing", Brian = Carpenter, >>>>> Sheng Jiang, Willy Tarreau, 17-Jan-12 >>>>>=20 >>>>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat >>>>> "464XLAT: Combination of Stateful and Stateless Translation", = Masataka >>>>> Mawatari, Masanobu Kawashima, Cameron Byrne, 14-Feb-12 >>>>>=20 >>>>> http://tools.ietf.org/html/draft-ietf-v6ops-6204bis >>>>> "Basic Requirements for IPv6 Customer Edge Routers", Barbara = Stark, >>>>> Chris Donley, Hemant Singh, Ole Troan, Wes Beebee, 22-Dec-11 >>>>>=20 >>>>> http://tools.ietf.org/html/draft-ietf-v6ops-ivi-icmp-address >>>>> "Stateless Source Address Mapping for ICMPv6 Packets", Xing Li, = Congxiao >>>>> Bao, Dan Wing, Ramji Vaithianathan, Geoff Huston, 24-Feb-12 >>>>>=20 >>>>> = http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation >>>>> "Implementation Advice for IPv6 Router Advertisement Guard = (RA-Guard)", >>>>> Fernando Gont, 3-Mar-12 >>>>>=20 >>>>> = http://tools.ietf.org/html/draft-ietf-v6ops-wireline-incremental-ipv6 >>>>> "Wireline Incremental IPv6", Victor Kuarsingh, Lee Howard, = 1-Feb-12 >>>>>=20 >>>>> In the coming week, I am told to expect one additional -00 draft, = and I could imagine other drafts being updated. I will be looking for = those drafts to meet the criteria above as well, but please drop the = chairs a note. >>>>> _______________________________________________ >>>>> v6ops mailing list >>>>> v6ops@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/v6ops >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >>=20 From despres.remi@laposte.net Wed Mar 14 06:41:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973EC21F8760 for ; Wed, 14 Mar 2012 06:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] 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 olrWacmkXyZl for ; Wed, 14 Mar 2012 06:41:34 -0700 (PDT) Received: from smtpout.laposte.net (smtpout4.laposte.net [193.253.67.229]) by ietfa.amsl.com (Postfix) with ESMTP id F121821F8782 for ; Wed, 14 Mar 2012 06:41:33 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8508-out with ME id lRhW1i00F37Y3f403RhXdr; Wed, 14 Mar 2012 14:41:32 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-120--909510929 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Wed, 14 Mar 2012 14:41:30 +0100 Message-Id: References: <25E067CE-65BF-462E-9A45-2D09451256F9@cisco.com> <23B5B3FA-A0A1-4671-97A9-D8964706344B@laposte.net> <8AD0DC9E-29C6-4E9D-AB30-4DE1DD37A62B@cisco.com> <4F609B96.90409@gmail.com> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: IPv6 Ops WG Subject: Re: [v6ops] Agenda discussion X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 13:41:35 -0000 --Apple-Mail-120--909510929 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Cameron, I see more the NAT64+ proposed in the latest 4rd draft as a complement = to the 464XLAT approach that you promoted. The goal is some commonality in customer nodes between a stateful = solution (DS hosts using NAT64s) and a stateless solution (4rd in this = instance). Of course, it's difficult to have it understood if there is no = opportunity to explain it. Regards, RD =20 Le 2012-03-14 =E0 14:32, Cameron Byrne a =E9crit : >=20 > On Mar 14, 2012 6:22 AM, "Tom Taylor" = wrote: > > > > Perhaps it would be useful to know that R=E9mi's 4rd-U is actually a = competitor to MAP. > > > > >=20 > Yep. And they both see 464xlat as a competitor. >=20 > I oppose bringing this "mine is better than yours" story to the floor. = It has not been productive on the list and it will be less productive in = person where it is harder to counter the hand waving arguments (like = concerns about a /96 that have been addressed clearly on the list and = seems to be only the interest of one person) >=20 > The stateless solutions have a place in softwires. Once they have = operational scenarios and deployment lessons learned, they will fit = v6ops. >=20 > Cb > > On 14/03/2012 7:23 AM, R=E9mi Despr=E9s wrote: > >> > >> Fred, > >> > >> 2012-03-14 11:38, Fred Baker: > >> > >>> > >>> On Mar 13, 2012, at 8:40 AM, R=E9mi Despr=E9s wrote: > >>> > >>>> Hi Fred, > >>>> > >>>> There has been discussion on the list about the relationship = between 464XLAT and 4rd (24 v6ops e-mails with these 2 acronyms) > >>>> The latest version of draft-despres-softwire-4rd-U (posted on = March 12) introduces a NAT64 variant called NAT64+. > >>>> Its purpose is 464XLAT-like scenarios with improved IPv4 = transparency. > >>>> > >>>> I would appreciate a slot (10 minutes or more) to present what is = at stake, operationally speaking. > >>>> There is no v6ops-specific draft: time has been too short to make = one despite relevance to v6ops of the subject matter to v6ops. > >>>> (There is of course no plan to present protocol contents in = v6ops, Softwire being the place for this.) > >> > >> > >> This is only based on a small part of the latest 4rd-u draft. > >> There is definitely no need to present all other documents you = listed below. > >> I do believe that, in 10 min, I can usefully inform the v6ops WG = about the relationship between 464XLAT and 4rd. > >> > >> Regards, > >> RD > >> > >> > >> > >> > >>>> > >>>> Thanks, > >>>> RD > >>> > >>> > >>> 4rd and dIVI are two legs of MAP, as I understand it. I was = expecting that discussion during the 464xlat discussion, from the floor, = but I'm willing to give someone ten minutes to present the MAP effort > >>> > >>> = http://datatracker.ietf.org/doc/draft-despres-softwire-4rd-u > >>> http://datatracker.ietf.org/doc/draft-fu-softwire-4rd-mib > >>> = http://datatracker.ietf.org/doc/draft-mdt-softwire-map-deployment > >>> = http://datatracker.ietf.org/doc/draft-mdt-softwire-map-dhcp-option > >>> = http://datatracker.ietf.org/doc/draft-mdt-softwire-map-encapsulation > >>> = http://datatracker.ietf.org/doc/draft-mdt-softwire-map-translation > >>> = http://datatracker.ietf.org/doc/draft-mdt-softwire-mapping-address-and-por= t > >>> http://datatracker.ietf.org/doc/draft-murakami-softwire-4rd > >>> = http://datatracker.ietf.org/doc/draft-sarikaya-softwire-4rdmulticast > >>> > >>> and discuss its implications vis-a-vis 464clat. In ten minutes, = this is obviously at a very high level. Do you think you can talk with = your fellow contributors to the MAP effort and find one person who can = fairly the describe all of that? > >>> > >>>> Le 2012-03-06 =E0 05:46, Fred Baker a =E9crit : > >>>> > >>>>> Stated in no particular order, we have the following documents = that meet these criteria: > >>>>> - not in the IESG process somewhere > >>>>> - posted or updated since IETF 82 > >>>>> - have had list discussion since IETF 82 or responds to = discussion at IETF 82 > >>>>> > >>>>> At this point, I take them as our agenda at IETF 83. If I am = missing a document (if you have posted it since Sunday, I may well be = missing it), please remind me. > >>>>> > >>>>> > >>>>> http://tools.ietf.org/html/draft-carpenter-v6ops-icp-guidance > >>>>> "IPv6 Guidance for Internet Content and Application Service = Providers", > >>>>> Brian Carpenter, Sheng Jiang, 22-Feb-12 > >>>>> > >>>>> No presentation expected, but the authors would like working = group adoption. We need to decide whether we want to do that. > >>>>> > >>>>> http://tools.ietf.org/html/draft-carpenter-v6ops-label-balance > >>>>> "Using the IPv6 Flow Label for Server Load Balancing", Brian = Carpenter, > >>>>> Sheng Jiang, Willy Tarreau, 17-Jan-12 > >>>>> > >>>>> http://tools.ietf.org/html/draft-ietf-v6ops-464xlat > >>>>> "464XLAT: Combination of Stateful and Stateless Translation", = Masataka > >>>>> Mawatari, Masanobu Kawashima, Cameron Byrne, 14-Feb-12 > >>>>> > >>>>> http://tools.ietf.org/html/draft-ietf-v6ops-6204bis > >>>>> "Basic Requirements for IPv6 Customer Edge Routers", Barbara = Stark, > >>>>> Chris Donley, Hemant Singh, Ole Troan, Wes Beebee, 22-Dec-11 > >>>>> > >>>>> http://tools.ietf.org/html/draft-ietf-v6ops-ivi-icmp-address > >>>>> "Stateless Source Address Mapping for ICMPv6 Packets", Xing Li, = Congxiao > >>>>> Bao, Dan Wing, Ramji Vaithianathan, Geoff Huston, 24-Feb-12 > >>>>> > >>>>> = http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation > >>>>> "Implementation Advice for IPv6 Router Advertisement Guard = (RA-Guard)", > >>>>> Fernando Gont, 3-Mar-12 > >>>>> > >>>>> = http://tools.ietf.org/html/draft-ietf-v6ops-wireline-incremental-ipv6 > >>>>> "Wireline Incremental IPv6", Victor Kuarsingh, Lee Howard, = 1-Feb-12 > >>>>> > >>>>> In the coming week, I am told to expect one additional -00 = draft, and I could imagine other drafts being updated. I will be looking = for those drafts to meet the criteria above as well, but please drop the = chairs a note. > >>>>> _______________________________________________ > >>>>> v6ops mailing list > >>>>> v6ops@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/v6ops > >>>> > >>>> > >>> > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >> > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-120--909510929 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Cameron,

I see more the NAT64+ proposed in the latest = 4rd draft as a complement to the 464XLAT approach that you = promoted.

The goal is some commonality in = customer nodes between a stateful solution (DS hosts using NAT64s) = and a stateless  solution (4rd in this = instance).

Of course, it's difficult to = have it understood if there is no opportunity to explain = it.

Regards,
RD

 

Le 2012-03-14 =E0 14:32, Cameron Byrne = a =E9crit :


On Mar 14, 2012 6:22 AM, "Tom Taylor" <tom.taylor.stds@gmail.com>= ; wrote:
>
> Perhaps it would be useful to know that R=E9mi's 4rd-U is actually = a competitor to MAP.
>
>

Yep. And they both see 464xlat as a competitor.

I = oppose bringing this "mine is better than yours" story to the floor. It = has not been productive on the list and it will be less productive in = person where it is harder to counter the hand waving arguments (like = concerns about a /96 that have been addressed clearly on the list and = seems to be only the interest of one person)

The stateless = solutions have a place in softwires. Once they have operational = scenarios and deployment lessons learned, they will fit v6ops. =




Cb
> On 14/03/2012 7:23 AM, R=E9mi Despr=E9s wrote:
>>
>> Fred,
>>
>> 2012-03-14 11:38, Fred Baker:
>>
>>>
>>> On Mar 13, 2012, at 8:40 AM, R=E9mi Despr=E9s wrote:
>>>
>>>> Hi Fred,
>>>>
>>>> There has been discussion on the list about the = relationship between 464XLAT and 4rd (24 v6ops e-mails with these 2 = acronyms)
>>>> The latest version of draft-despres-softwire-4rd-U = (posted on March 12) introduces a NAT64 variant called NAT64+.
>>>> Its purpose is 464XLAT-like scenarios with improved = IPv4 transparency.
>>>>
>>>> I would appreciate a slot (10 minutes or more) to = present what is at stake, operationally speaking.
>>>> There is no v6ops-specific draft: time has been too = short to make one despite relevance to v6ops of the subject matter to = v6ops.
>>>> (There is of course no plan to present protocol = contents in v6ops, Softwire being the place for this.)
>>
>>
>> This is only based on a small part of the latest 4rd-u = draft.
>> There is definitely no need to present all other documents you = listed below.
>> I do believe that, in 10 min, I can usefully inform the v6ops = WG about the relationship between 464XLAT and 4rd.
>>
>> Regards,
>> RD
>>
>>
>>
>>
>>>>
>>>> Thanks,
>>>> RD
>>>
>>>
>>> 4rd and dIVI are two legs of MAP, as I understand it. I was = expecting that discussion during the 464xlat discussion, from the floor, = but I'm willing to give someone ten minutes to present the MAP = effort
>>>
>>>        http= ://datatracker.ietf.org/doc/draft-despres-softwire-4rd-u
>>>        http://= datatracker.ietf.org/doc/draft-fu-softwire-4rd-mib
>>>        http://datatracker.ietf.org/doc/draft-mdt-softwire-map-deployment
= >>>        http://datatracker.ietf.org/doc/draft-mdt-softwire-map-dhcp-option >>>        http://datatracker.ietf.org/doc/draft-mdt-softwire-map-encapsulation
>>>        http://datatracker.ietf.org/doc/draft-mdt-softwire-map-translation >>>        http://datatracker.ietf.org/doc/draft-mdt-softwire-mapping-addr= ess-and-port
>>>        http:= //datatracker.ietf.org/doc/draft-murakami-softwire-4rd
>>>        http://datatracker.ietf.org/doc/draft-sarikaya-softwire-4rdmulticast
>>>
>>> and discuss its implications vis-a-vis 464clat. In ten = minutes, this is obviously at a very high level. Do you think you can = talk with your fellow contributors to the MAP effort and find one person = who can fairly the describe all of that?
>>>
>>>> Le 2012-03-06 =E0 05:46, Fred Baker a =E9crit :
>>>>
>>>>> Stated in no particular order, we have the = following documents that meet these criteria:
>>>>> - not in the IESG process somewhere
>>>>> - posted or updated since IETF 82
>>>>> - have had list discussion since IETF 82 or = responds to discussion at IETF 82
>>>>>
>>>>> At this point, I take them as our agenda at IETF = 83. If I am missing a document (if you have posted it since Sunday, I = may well be missing it), please remind me.
>>>>>
>>>>>
>>>>> htt= p://tools.ietf.org/html/draft-carpenter-v6ops-icp-guidance
>>>>> "IPv6 Guidance for Internet Content and Application = Service Providers",
>>>>> Brian Carpenter, Sheng Jiang, 22-Feb-12
>>>>>
>>>>> No presentation expected, but the authors would = like working group adoption. We need to decide whether we want to do = that.
>>>>>
>>>>> ht= tp://tools.ietf.org/html/draft-carpenter-v6ops-label-balance
>>>>> "Using the IPv6 Flow Label for Server Load = Balancing", Brian Carpenter,
>>>>> Sheng Jiang, Willy Tarreau, 17-Jan-12
>>>>>
>>>>> http://tools.= ietf.org/html/draft-ietf-v6ops-464xlat
>>>>> "464XLAT: Combination of Stateful and Stateless = Translation", Masataka
>>>>> Mawatari, Masanobu Kawashima, Cameron Byrne, = 14-Feb-12
>>>>>
>>>>> http://tools.= ietf.org/html/draft-ietf-v6ops-6204bis
>>>>> "Basic Requirements for IPv6 Customer Edge = Routers", Barbara Stark,
>>>>> Chris Donley, Hemant Singh, Ole Troan, Wes Beebee, = 22-Dec-11
>>>>>
>>>>> http= ://tools.ietf.org/html/draft-ietf-v6ops-ivi-icmp-address
>>>>> "Stateless Source Address Mapping for ICMPv6 = Packets", Xing Li, Congxiao
>>>>> Bao, Dan Wing, Ramji Vaithianathan, Geoff Huston, = 24-Feb-12
>>>>>
>>>>> http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation=
>>>>> "Implementation Advice for IPv6 Router = Advertisement Guard (RA-Guard)",
>>>>> Fernando Gont, 3-Mar-12
>>>>>
>>>>> http://tools.ietf.org/html/draft-ietf-v6ops-wireline-incremental-ipv6=
>>>>> "Wireline Incremental IPv6", Victor Kuarsingh, Lee = Howard, 1-Feb-12
>>>>>
>>>>> In the coming week, I am told to expect one = additional -00 draft, and I could imagine other drafts being updated. I = will be looking for those drafts to meet the criteria above as well, but = please drop the chairs a note.
>>>>> _______________________________________________
>>>>> v6ops mailing list
>>>>> v6ops@ietf.org
>>>>> https://www.ietf.org/= mailman/listinfo/v6ops
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/= mailman/listinfo/v6ops
>>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/= mailman/listinfo/v6ops


= --Apple-Mail-120--909510929-- From wdec.ietf@gmail.com Wed Mar 14 11:53:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0252D21F8822 for ; Wed, 14 Mar 2012 11:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.957 X-Spam-Level: X-Spam-Status: No, score=-2.957 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 qN5oPsNpxJH0 for ; Wed, 14 Mar 2012 11:52:57 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE4F21F8820 for ; Wed, 14 Mar 2012 11:52:50 -0700 (PDT) Received: by eaaq11 with SMTP id q11so1318653eaa.31 for ; Wed, 14 Mar 2012 11:52:49 -0700 (PDT) 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=oozCuAF3Sr37jmMXaW0UI4eBJaBX5cGjGWKJqqm5KCI=; b=nffzpb70b95InePwiJBBLMtHwZmqzprsedb60/4qcWyaoFv40tI9WFl/SFtMWYyFjA ofDqCXpA+6Xiq2Yls0W8+uM07rVZimcmQfH4l76bFywG4fvyGV4oZL3JDdh80vmDo6mn C3eVq8MrZ2P+0qlR7AnX6/+KBpr2BvZ4a47sNy3hyTg0jQYJio6onrEcB13FuojYCQPI LOOAPWZ9/YYQhxdGKbSGWBIgGi1EfqIQfDQszB/NOpVNjrsg+yYLzh5v26vRXSET4KvE uf1mzUqKgm6RTwjy3MTk4nBSR7U2G5CW56qw3cdxzUl3hqRkVqAtImbtx3coArlx7eg0 eIbQ== MIME-Version: 1.0 Received: by 10.224.197.198 with SMTP id el6mr4546786qab.7.1331751169033; Wed, 14 Mar 2012 11:52:49 -0700 (PDT) Received: by 10.229.218.4 with HTTP; Wed, 14 Mar 2012 11:52:48 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Mar 2012 19:52:48 +0100 Message-ID: From: Wojciech Dec To: Cameron Byrne Content-Type: multipart/alternative; boundary=20cf300fb1535c050104bb387b0e Cc: v6ops@ietf.org Subject: Re: [v6ops] Nomative language in draft-ietf-v6ops-464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 18:53:02 -0000 --20cf300fb1535c050104bb387b0e Content-Type: text/plain; charset=ISO-8859-1 On 8 March 2012 15:09, Cameron Byrne wrote: > > On Mar 8, 2012 5:26 AM, "Wojciech Dec" wrote: > > > > > > > > On 8 March 2012 09:03, Cameron Byrne wrote: > >> > >> ---------- Forwarded message ---------- > >> From: "Cameron Byrne" > >> Date: Mar 7, 2012 4:34 PM > >> Subject: Re: [v6ops] Nomative language in draft-ietf-v6ops-464xlat-00 > >> To: "Wojciech Dec" > >> > >> we seem to be off list, in line > >> > >> On Wed, Mar 7, 2012 at 9:03 AM, Wojciech Dec > wrote: > >> > > >> > > >> > On 7 March 2012 16:31, Cameron Byrne wrote: > >> >> > >> >> Woj, > >> >> > >> >> On Wed, Mar 7, 2012 at 5:49 AM, Wojciech Dec > wrote: > >> >> > The draft contains text like > >> >> > > >> >> > "In the 464XLAT environment, the PLAT and CLAT SHOULD include an > IPv6 > >> >> > Fragment Header, since IPv4 host does not set the DF bit. " > >> >> > > >> >> > >> >> This will be changed in future revisions, RFC 2119 key words will be > >> >> removed. > >> >> > >> >> > What more it contains specific text in Section 6.1 like > >> >> > > >> >> > " > >> >> > > >> >> > IPv6 address format in 464XLAT is presented in the following > format. > >> >> > > >> >> > > +-----------------------------------------------+---------------+ > >> >> > | XLAT prefix(96) | > IPv4(32) | > >> >> > > +-----------------------------------------------+---------------+ > >> >> > > >> >> > Source address and destination address have IPv4 address embedded > in the > >> >> > low-order 32 bits of the IPv6 address. " > >> >> > > >> >> > NAT64 RFCs does not make such requirements or place such a prefix > >> >> > restriction, and IMO these effectively become normative for an > >> >> > implementation. If they're not needed then they shouldn't be there. > >> >> > > >> >> > >> >> This is not a NAT64 RFC. This an informational draft that states how > >> >> a scenario defined in a NAT64 RFC may be used. The above IPv6 > address > >> >> format is defined as one of many possible in RFC 6052. The above > >> >> format for convenience of implementation is recommended in 464XLAT. > I > >> >> hope this recommendation of how a deployment scenario in an > >> >> informational document is not a problem for you. The point of a > >> >> deployment scenario / architecture is that it constrains all possible > >> >> options into a reasonable set that work together in a particular way. > >> > > >> > > >> > Building architectures conforming only to very narrow deployment > scenarios > >> > means that they will likely break when taken outside of that > environment. In > >> > >> if they are taken outside of their environment, they are not the > >> specified architecture. > > > > > > Yes, that's why architectures should be broad usage based. > > > > Disagree. You may have a successful architecture for an air plane, but if > you change the use case such that it must act as a boat ... that is an > implementation failure. It does not make the airplane architecture a > failure as soon as somebody puts it in the water > Nobody defines airplanes to be fixed size 96 seaters, etc. > >> > >> > >> > the xlat464 case this very narrow deployment scenario appears to be > the > >> > >> narrow or not, it patches the 15% app breakage that we see when > >> nat64/dns64 is deployed alone. > >> > >> > >> That alone is the utility of the service. > > > > > > Case in hand appears that if one takes a CLAT and connects it to say any > other network, say your enterprise network where NAT64 may even be present > but configured outside of the narrow xlat464 constraints, the CLAT won't > work, ie the app breakage will be there, even though it they could be > avoided. > > > > Out of scope. > > >> > >> > combined set of; a stateful core NAT46 device; use of only /96 prefix > for > >> > address mapping; only private IPv4 addresses for end hosts/apps. > >> > > >> > I for one have no problem with someone choosing to set up their > network to > >> > operate like that, and documenting publicly their setup/experiences. > Also no > >> > problem with the use NAT64 stateless/stateful to solve the overall > problem > >> > of "connect v4 to and across v6". Where I do start having problems is > in > >> > seeking broad WG recommendations for effectively creating > >> > devices/implementations that *only* work within this specific set of > >> > constraints. > >> > >> this is an informational doc and not a device spec. > >> > >> > > >> >> > >> >> In general, /96 speeds up discover and helps create uniformity in the > >> >> 464XLAT deployment model. We do not see any specific utility in > >> >> support anything beyond a /96 for the purposes for which 464XLAT is > >> >> scoped. > >> > > >> > > >> > Can you substantiate how a /96 helps speed up discovery, and not other > >> > prefix lengths, or operator assigned lengths? Why restrict the > operator to > >> > this specific prefix length for both source and destination address > mapping? > >> > The NAT64 authors, operators amongst them, didn't think that such a > >> > restriction was useful or necessary. > >> > > >> > >> I got the impression that /96 is faster here > >> http://www.ietf.org/mail-archive/web/behave/current/msg08893.html > >> > >> the fact that it is simpler is intuitive. > >> > >> i see know reason why to introduce the additional complexity of having > >> other side prefixes. > >> > >> Is there a benefit? > > > > > > For a start, NAT64 authors saw a benefit, so unless we're redefining > that we should follow, or be very precise why not. To me, the impression > that /96 is faster not entirely justified. > > Besides this, the length of the prefix is relevant to operators who care > about route summarization and optimization, besides actual subnetting. It's > similar to why we don't have rules for a "simple and intuitive" fixed host > subnet length in IPv6. > > > > Saying the nat64 authors saw a benefit is not demonstrating value for the > 464xlat scenario. > Basic question: Why are you asking the WG to adopt your document and define your architecture CLAT and all? If you're seeking the blessing for operating a standard based NAT64 network set-up in a specific way that you call xlat464, then IMO you don't need a specific WG blessing. Indicators are that this draftl is intended to drive a specific device specification which it calls CLAT xlat464. This is a "sub class" of NAT64 effectively that is not suitable for use as a vanilla NAT64, beyond the narrow & specific assumptions and constraints you found convenient in your setup. Anything else is marked as "out of scope" and I think that this specificity is a problem. There is no problem with having your setup documented, but there is with having your setup be the only subject of a device spec. > Quantify how it is not faster, if that is your claim. > LOL. You made a design decision that claims benefit in curtailing valid use of an existing RFC specification. If anything, the burden of proving the case of how a /96 is faster/whatever vs a /64 or a /32 rests on you, otherwise just follow the existing spec, and loose the specificity. > Route summaries? As the draft says clearly, /64 is the best and likely > case is that is with dhcp pd. The /96 is a case of nd proxy or similar. > Neither have any impact on route summaries. > DHCP-PD's will be shorter than /64. The /64 is another assumption that is highly limiting. > In both cases above you made unsupported claims which makes me go back and > justify why your unsubstantiated claim is wrong with facts and use cases. > > Please clearly substantiate your claims with examples in the future. ... > for example, if you are going to claim this makes more routes, clearly > articulate why you believe that. Otherwise you will be dismissed as > creating FUD. > Given your previous posts something tells me that any use-case will be dismissed as "out of scope" for your specific deployment. FWIW a couple of cases are: Case 1: Operator wants to assign a specific IPv4 address (public) for a CLAT user. Under the existing spec, the operator would need to also install an extra /96+ route Case 2: Two CLATs on a shared link segment network (eg a WiFi). How do we route to each CLAT? etc.. > >> > >> > >> >> > >> >> > >> >> > Way of resolving the issue(s) would be to: > >> >> > - Document the experiment, the set-up and the results. > >> >> > >> >> draft-ietf-v6ops-464xlat-00 is not an experiment report, it is an > >> >> informational architecture which happens to be supported by running > >> >> code and informal network deployment reports > >> >> > >> >> > - Separately document any/all specific requirements, assumptions or > >> >> > operations that are not covered by existing RFCs (eg the > requirement for > >> >> > XLAT to use a /96 prefix) > >> >> > > >> >> > >> >> draft-ietf-v6ops-464xlat-00 does not create any new technology or > >> >> standards. I don't believe an information document that does not use > >> >> RFC 2119 language and recommends a /96 prefix (which is one of many > >> >> defined in RFC 6052) should be an issue. If it is, please let me > know > >> >> why. > >> > > >> > > >> > If this is a recommendation and not a spec, how would a regular > stateless > >> > NAT64 device, like the CLAT claims to be, know that it should use a > /96 as > >> > its source prefix for mapping v4? > >> > > >> > >> The fact that is knows means that it is CLAT subset of any CPE that > does 6145 > > > > > > This seems to contradict the previous statement about this draft not > being a device spec. > > If the CLAT is fully RFC6145 compliant, it should be clearly stated, and > text about /96, etc removed. If you're assuming that the CLAT is a subset > of RFC6145, then it would be best if you put the specifics of those > assumptions + anything else that is needed for the spec in a separate draft. > > > > Disagree. > You disagree with what? If you're claiming that the CLAT is fully in line with RFC6145 compliant then why do you object to removing specificity or assumptions (ie hard coded configuration) that is NOT present in RFC6145? Having it both ways looks untenable. Suggestion of a way forward: Just replace the text in Section 6.1, besides other normative terms, with text like "The CLAT is a device conforming to stateless NAT46 as per RFCxxxx. In the xlat464 set-up it was configured to use /X (whatever prefix you found convenient. This was due to ... (whatever reasons you thought of", etc. -Woj. > Cb > > > -Woj. > >> > >> > >> CB > >> > > >> > -Woj. > >> > > >> >> CB > >> >> > >> >> > -Woj. > >> >> > > >> >> > > >> > > >> > > >> > >> _______________________________________________ > >> v6ops mailing list > >> v6ops@ietf.org > >> https://www.ietf.org/mailman/listinfo/v6ops > >> > > > > --20cf300fb1535c050104bb387b0e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 8 March 2012 15:09, Cameron Byrne <= cb.list6@gmail.com> wrote:


On Mar 8, 2012 5:26 AM, "Wojciech Dec" <wdec.ietf@gmail.com> wrote:
>
>
>
> On 8 March 2012 09:03, Cameron Byrne <cb.list6@gmail.com> wrote:
>>
>> ---------- Forwarded message ----------
>> From: "Cameron Byrne" <cb.list6@gmail.com>
>> Date: Mar 7, 2012 4:34 PM
>> Subject: Re: [v6ops] Nomative language in draft-ietf-v6ops-464xlat= -00
>> To: "Wojciech Dec" <wdec.ietf@gmail.com>
>>
>> we seem to be off list, in line
>>
>> On Wed, Mar 7, 2012 at 9:03 AM, Wojciech Dec <wdec.ietf@gmail.com> wrote:<= br> >> >
>> >
>> > On 7 March 2012 16:31, Cameron Byrne <cb.list6@gmail.com> wrote:
>> >>
>> >> Woj,
>> >>
>> >> On Wed, Mar 7, 2012 at 5:49 AM, Wojciech Dec <wdec.ietf@gmail.com&g= t; wrote:
>> >> > The draft contains text like
>> >> >
>> >> > =A0"In the 464XLAT environment, the PLAT and CL= AT SHOULD include an IPv6
>> >> > =A0 =A0Fragment Header, since IPv4 host does not set= the DF bit. "
>> >> >
>> >>
>> >> This will be changed in future revisions, RFC 2119 key wo= rds will be
>> >> removed.
>> >>
>> >> > What more it contains specific text in Section 6.1 l= ike
>> >> >
>> >> > "
>> >> >
>> >> > IPv6 address format in 464XLAT is presented in the f= ollowing format.
>> >> >
>> >> > =A0 =A0 =A0 =A0+------------------------------------= -----------+---------------+
>> >> > =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0XLAT pre= fix(96) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0IPv4(32) =A0 |
>> >> > =A0 =A0 =A0 =A0+------------------------------------= -----------+---------------+
>> >> >
>> >> > Source address and destination address have IPv4 add= ress embedded in the
>> >> > low-order 32 bits of the IPv6 address. "
>> >> >
>> >> > NAT64 RFCs does not make such requirements or place = such a prefix
>> >> > restriction, and IMO these effectively become normat= ive for an
>> >> > implementation. If they're not needed then they = shouldn't be there.
>> >> >
>> >>
>> >> This is not a NAT64 RFC. =A0This an informational draft t= hat states how
>> >> a scenario defined in a NAT64 RFC may be used. =A0The abo= ve IPv6 address
>> >> format is defined as one of many possible in RFC 6052. = =A0The above
>> >> format for convenience of implementation is recommended i= n 464XLAT. =A0I
>> >> hope this recommendation of how a deployment scenario in = an
>> >> informational document is not a problem for you. =A0The p= oint of a
>> >> deployment scenario / architecture is that it constrains = all possible
>> >> options into a reasonable set that work together in a par= ticular way.
>> >
>> >
>> > Building architectures conforming only to very narrow deploym= ent scenarios
>> > means that they will likely break when taken outside of that = environment. In
>>
>> if they are taken outside of their environment, they are not the >> specified architecture.
>
>
> Yes, that's why architectures should be broad usage based.
> =A0

Disagree. You may have a successful architecture for an air = plane, but if you change the use case such that it must act as a boat ... t= hat is an implementation failure. It does not make the airplane architectur= e a failure as soon as somebody puts it in the water


Nobody defines airplanes to be fixed size 96 seaters,= etc.

>>
>>
>> > the xlat464 case this very narrow deployment scenario appears= to be the
>>
>> narrow or not, it patches the 15% app breakage that we see when >> nat64/dns64 is deployed alone.
>>
>>
>> That alone is the utility of the service.
>
>
> Case in hand appears that if one takes a CLAT and connects it to say a= ny other network, say your enterprise network where NAT64 may even be prese= nt but configured outside of the narrow xlat464 constraints, the CLAT won&#= 39;t work, ie the app breakage will be there, even though it they could be = avoided.
>

Out of scope.

>>
>> > combined set of; a stateful core NAT46 device; use of only /9= 6 prefix for
>> > address mapping; only private IPv4 addresses for end hosts/ap= ps.
>> >
>> > I for one have no problem with someone choosing to set up the= ir network to
>> > operate like that, and documenting publicly their setup/exper= iences. Also no
>> > problem with the use NAT64 stateless/stateful to solve the ov= erall problem
>> > of "connect v4 to and across v6". Where I do start = having problems is in
>> > seeking broad WG recommendations for effectively creating
>> > devices/implementations that *only* work within this specific= set of
>> > constraints.
>>
>> this is an informational doc and not a device spec.
>>
>> >
>> >>
>> >> In general, /96 speeds up discover and helps create unifo= rmity in the
>> >> 464XLAT deployment model. =A0We do not see any specific u= tility in
>> >> support anything beyond a /96 for the purposes for which = 464XLAT is
>> >> scoped.
>> >
>> >
>> > Can you substantiate how a /96 helps speed up discovery, and = not other
>> > prefix lengths, or operator assigned lengths? Why restrict th= e operator to
>> > this specific prefix length for both source and destination a= ddress mapping?
>> > The NAT64 authors, operators amongst them, didn't think t= hat such a
>> > restriction was useful or necessary.
>> >
>>
>> I got the impression that /96 is faster here
>> http://www.ietf.org/mail-archive/web/behave/c= urrent/msg08893.html
>>
>> the fact that it is simpler is intuitive.
>>
>> i see know reason why to introduce the additional complexity of ha= ving
>> other side prefixes.
>>
>> Is there a benefit?
>
>
> For a start, NAT64 authors saw a benefit, so unless we're redefini= ng that we should follow, or be very precise why not. To me, the impression= that /96 is faster not entirely justified.
> Besides this, the length of the prefix is relevant to operators who ca= re about route summarization and optimization, besides actual subnetting. I= t's similar to why we don't have rules for a "simple and intui= tive" fixed host subnet length in IPv6.
> =A0

Saying the nat64 authors saw a benefit is not demonstrating = value for the 464xlat scenario.

Basic question: Why a= re you asking the WG to adopt your document and define your architecture CL= AT and all? If you're seeking the blessing for operating a standard bas= ed NAT64 network set-up in a specific way that you call xlat464, then IMO y= ou don't need a specific WG blessing. Indicators are that this draftl i= s intended to drive a specific device specification which it calls CLAT xla= t464. This is a "sub class" of NAT64 effectively that is not suit= able for use as a vanilla NAT64, beyond the narrow & specific assumptio= ns and constraints you found convenient in your setup. Anything else is mar= ked as "out of scope" and I think that this specificity is a prob= lem. There is no problem with having your setup documented, but there is wi= th having your setup be the only subject of a device spec.
=A0

Quantify how it is not faster, if that is your claim.

<= div>LOL. You made a design decision that claims benefit in curtailing valid= use of an existing RFC specification. If anything, the burden of proving t= he case of how a /96 is faster/whatever vs a /64 or a /32=A0 rests on you, = otherwise just follow the existing spec, and loose the specificity.

Route summaries? As the draft says clearly, /64 is the best and likely c= ase is that is with dhcp pd. The /96 is a case of nd proxy or similar. Neit= her have any impact on route summaries.

DHCP-PD's= will be shorter than /64. The /64 is another assumption that is highly lim= iting.

In both cases above you made unsupported claims which makes me go back a= nd justify why your unsubstantiated claim is wrong with facts and use cases= .

Please clearly substantiate your claims with examples in the future. ...= for example, if you are going to claim this makes more routes, clearly art= iculate why you believe that. Otherwise you will be dismissed as creating F= UD.



Given your previous posts something tells me that= any use-case will be dismissed as "out of scope" for your specif= ic deployment.
FWIW a couple of cases are:

Case 1: Operator wants to assign a speci= fic IPv4 address (public) for a=20 CLAT user. Under the existing spec, the operator would need to also=20 install an extra /96+ route
Case 2: Two CLATs on a shared link segment network (eg a WiFi). How do we r= oute to each CLAT?
etc..

>>
>>
>> >>
>> >>
>> >> > Way of resolving the issue(s) would be to:
>> >> > - Document the experiment, the set-up=A0 and the res= ults.
>> >>
>> >> draft-ietf-v6ops-464xlat-00 is not an experiment report, = it is an
>> >> informational architecture which happens to be supported = by running
>> >> code and informal network deployment reports
>> >>
>> >> > - Separately document any/all specific requirements,= assumptions or
>> >> > operations that are not covered by existing RFCs (eg= the requirement for
>> >> > XLAT to use a /96 prefix)
>> >> >
>> >>
>> >> draft-ietf-v6ops-464xlat-00 does not create any new techn= ology or
>> >> standards. =A0I don't believe an information document= that does not use
>> >> RFC 2119 language and recommends a /96 prefix (which is o= ne of many
>> >> defined in RFC 6052) should be an issue. =A0If it is, ple= ase let me know
>> >> why.
>> >
>> >
>> > If this is a recommendation and not a spec, how would a regul= ar stateless
>> > NAT64 device, like the CLAT claims to be, know that it should= use a /96 as
>> > its source prefix for mapping v4?
>> >
>>
>> The fact that is knows means that it is CLAT subset of any CPE tha= t does 6145
>
>
> This seems to contradict the previous statement about this draft not b= eing a device spec.
> If the CLAT is fully RFC6145 compliant, it should be clearly stated, a= nd text about /96, etc removed. If you're assuming that the CLAT is a s= ubset of RFC6145, then it would be best if you put the specifics of those a= ssumptions + anything else that is needed for the spec in a separate draft.=
>

Disagree.


You disagree with what? If you= 're claiming that the CLAT is fully in line with RFC6145 compliant then= why do you object to removing specificity or assumptions (ie hard coded co= nfiguration) that is NOT present in RFC6145? Having it both ways looks unte= nable.

Suggestion of a way forward: Just replace the text in Section 6.1, besi= des other normative terms, with text like "The CLAT is a device confor= ming to stateless NAT46 as per RFCxxxx. In the xlat464 set-up it was config= ured to use /X (whatever prefix you found convenient. This was due to ... (= whatever reasons you thought of", etc.

-Woj.

Cb

> -Woj.
>>
>>
>> CB
>> >
>> > -Woj.
>> >
>> >> CB
>> >>
>> >> > -Woj.
>> >> >
>> >> >
>> >
>> >
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org=
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>


--20cf300fb1535c050104bb387b0e-- From cb.list6@gmail.com Wed Mar 14 12:32:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D588921F8513 for ; Wed, 14 Mar 2012 12:32:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.163 X-Spam-Level: X-Spam-Status: No, score=-3.163 tagged_above=-999 required=5 tests=[AWL=-0.164, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 xhMFJODCRAnw for ; Wed, 14 Mar 2012 12:32:44 -0700 (PDT) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8A421F84FE for ; Wed, 14 Mar 2012 12:32:44 -0700 (PDT) Received: by yhgm50 with SMTP id m50so3301305yhg.27 for ; Wed, 14 Mar 2012 12:32:44 -0700 (PDT) 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:content-transfer-encoding; bh=T9QM4Vf+QbaWpgvO/6cF7iW5dWFQyEss4vvGPaQ90LU=; b=oA1GIdWtsffqprBZLHUin/dEm1weryXr2Up6vMpUkUuAnO7xFusLCqsbsdBN2IOjZJ 2LsPRGiqLMJeMiA65I2/4TujoO1mrq515ozlY/zzDwEsYeTCsbiLx6nrbJzlNoafWG20 //MgJJxkcKfEVp7keGS2qURE+7SLArMzTAOQbH7uKSlr/alLQla4UziEf+otoa7eIVQ5 DwE0DCyWKgiMSwUyhjPF43ToehWlqJ/9HYebTMK8JKGGXB/b1o9+ZIWnWtJxH8kkbD16 Q0ViCo5bJ2ODVkjUOPab4kJpJi/6wXcGmJCr+FwPFHHYlbI4khc5N4L4SNLfeDx0x6/S EqDw== MIME-Version: 1.0 Received: by 10.68.242.166 with SMTP id wr6mr4362573pbc.99.1331753563512; Wed, 14 Mar 2012 12:32:43 -0700 (PDT) Received: by 10.142.163.16 with HTTP; Wed, 14 Mar 2012 12:32:43 -0700 (PDT) In-Reply-To: References: Date: Wed, 14 Mar 2012 12:32:43 -0700 Message-ID: From: Cameron Byrne To: Wojciech Dec Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] Nomative language in draft-ietf-v6ops-464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 19:32:46 -0000 On Wed, Mar 14, 2012 at 11:52 AM, Wojciech Dec wrote: > > > On 8 March 2012 15:09, Cameron Byrne wrote: >> >> >> On Mar 8, 2012 5:26 AM, "Wojciech Dec" wrote: >> > >> > >> > >> > On 8 March 2012 09:03, Cameron Byrne wrote: >> >> >> >> ---------- Forwarded message ---------- >> >> From: "Cameron Byrne" >> >> Date: Mar 7, 2012 4:34 PM >> >> Subject: Re: [v6ops] Nomative language in draft-ietf-v6ops-464xlat-00 >> >> To: "Wojciech Dec" >> >> >> >> we seem to be off list, in line >> >> >> >> On Wed, Mar 7, 2012 at 9:03 AM, Wojciech Dec >> >> wrote: >> >> > >> >> > >> >> > On 7 March 2012 16:31, Cameron Byrne wrote: >> >> >> >> >> >> Woj, >> >> >> >> >> >> On Wed, Mar 7, 2012 at 5:49 AM, Wojciech Dec >> >> >> wrote: >> >> >> > The draft contains text like >> >> >> > >> >> >> > =A0"In the 464XLAT environment, the PLAT and CLAT SHOULD include= an >> >> >> > IPv6 >> >> >> > =A0 =A0Fragment Header, since IPv4 host does not set the DF bit.= " >> >> >> > >> >> >> >> >> >> This will be changed in future revisions, RFC 2119 key words will = be >> >> >> removed. >> >> >> >> >> >> > What more it contains specific text in Section 6.1 like >> >> >> > >> >> >> > " >> >> >> > >> >> >> > IPv6 address format in 464XLAT is presented in the following >> >> >> > format. >> >> >> > >> >> >> > >> >> >> > =A0+-----------------------------------------------+------------= ---+ >> >> >> > =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0XLAT prefix(96) =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >> >> >> > =A0IPv4(32) =A0 | >> >> >> > >> >> >> > =A0+-----------------------------------------------+------------= ---+ >> >> >> > >> >> >> > Source address and destination address have IPv4 address embedde= d >> >> >> > in the >> >> >> > low-order 32 bits of the IPv6 address. " >> >> >> > >> >> >> > NAT64 RFCs does not make such requirements or place such a prefi= x >> >> >> > restriction, and IMO these effectively become normative for an >> >> >> > implementation. If they're not needed then they shouldn't be >> >> >> > there. >> >> >> > >> >> >> >> >> >> This is not a NAT64 RFC. =A0This an informational draft that state= s >> >> >> how >> >> >> a scenario defined in a NAT64 RFC may be used. =A0The above IPv6 >> >> >> address >> >> >> format is defined as one of many possible in RFC 6052. =A0The abov= e >> >> >> format for convenience of implementation is recommended in 464XLAT= . >> >> >> =A0I >> >> >> hope this recommendation of how a deployment scenario in an >> >> >> informational document is not a problem for you. =A0The point of a >> >> >> deployment scenario / architecture is that it constrains all >> >> >> possible >> >> >> options into a reasonable set that work together in a particular >> >> >> way. >> >> > >> >> > >> >> > Building architectures conforming only to very narrow deployment >> >> > scenarios >> >> > means that they will likely break when taken outside of that >> >> > environment. In >> >> >> >> if they are taken outside of their environment, they are not the >> >> specified architecture. >> > >> > >> > Yes, that's why architectures should be broad usage based. >> > >> >> Disagree. You may have a successful architecture for an air plane, but i= f >> you change the use case such that it must act as a boat ... that is an >> implementation failure. It does not make the airplane architecture a fai= lure >> as soon as somebody puts it in the water > > > Nobody defines airplanes to be fixed size 96 seaters, etc. >> >> >> >> >> >> >> > the xlat464 case this very narrow deployment scenario appears to be >> >> > the >> >> >> >> narrow or not, it patches the 15% app breakage that we see when >> >> nat64/dns64 is deployed alone. >> >> >> >> >> >> That alone is the utility of the service. >> > >> > >> > Case in hand appears that if one takes a CLAT and connects it to say a= ny >> > other network, say your enterprise network where NAT64 may even be pre= sent >> > but configured outside of the narrow xlat464 constraints, the CLAT won= 't >> > work, ie the app breakage will be there, even though it they could be >> > avoided. >> > >> >> Out of scope. >> >> >> >> >> > combined set of; a stateful core NAT46 device; use of only /96 pref= ix >> >> > for >> >> > address mapping; only private IPv4 addresses for end hosts/apps. >> >> > >> >> > I for one have no problem with someone choosing to set up their >> >> > network to >> >> > operate like that, and documenting publicly their setup/experiences= . >> >> > Also no >> >> > problem with the use NAT64 stateless/stateful to solve the overall >> >> > problem >> >> > of "connect v4 to and across v6". Where I do start having problems = is >> >> > in >> >> > seeking broad WG recommendations for effectively creating >> >> > devices/implementations that *only* work within this specific set o= f >> >> > constraints. >> >> >> >> this is an informational doc and not a device spec. >> >> >> >> > >> >> >> >> >> >> In general, /96 speeds up discover and helps create uniformity in >> >> >> the >> >> >> 464XLAT deployment model. =A0We do not see any specific utility in >> >> >> support anything beyond a /96 for the purposes for which 464XLAT i= s >> >> >> scoped. >> >> > >> >> > >> >> > Can you substantiate how a /96 helps speed up discovery, and not >> >> > other >> >> > prefix lengths, or operator assigned lengths? Why restrict the >> >> > operator to >> >> > this specific prefix length for both source and destination address >> >> > mapping? >> >> > The NAT64 authors, operators amongst them, didn't think that such a >> >> > restriction was useful or necessary. >> >> > >> >> >> >> I got the impression that /96 is faster here >> >> http://www.ietf.org/mail-archive/web/behave/current/msg08893.html >> >> >> >> the fact that it is simpler is intuitive. >> >> >> >> i see know reason why to introduce the additional complexity of havin= g >> >> other side prefixes. >> >> >> >> Is there a benefit? >> > >> > >> > For a start, NAT64 authors saw a benefit, so unless we're redefining >> > that we should follow, or be very precise why not. To me, the impressi= on >> > that /96 is faster not entirely justified. >> > Besides this, the length of the prefix is relevant to operators who ca= re >> > about route summarization and optimization, besides actual subnetting.= It's >> > similar to why we don't have rules for a "simple and intuitive" fixed = host >> > subnet length in IPv6. >> > >> >> Saying the nat64 authors saw a benefit is not demonstrating value for th= e >> 464xlat scenario. > > Basic question: Why are you asking the WG to adopt your document and defi= ne > your architecture CLAT and all? If you're seeking the blessing for operat= ing > a standard based NAT64 network set-up in a specific way that you call It's an informational document, not a standard. > xlat464, then IMO you don't need a specific WG blessing. Indicators are t= hat Actually its called 464XLAT, not xlat464 > this draftl is intended to drive a specific device specification which it > calls CLAT xlat464. This is a "sub class" of NAT64 effectively that is no= t Yes, any unique and specific architecture, such is the case with 464XLAT, can be considered a sub-class of all the possible scenarios for using a standard, such as NAT64 > suitable for use as a vanilla NAT64, beyond the narrow & specific > assumptions and constraints you found convenient in your setup. Anything > else is marked as "out of scope" and I think that this specificity is a > problem. There is no problem with having your setup documented, but there= is Why is it a problem to you specifically? > with having your setup be the only subject of a device spec. > >> >> Quantify how it is not faster, if that is your claim. > > LOL. You made a design decision that claims benefit in curtailing valid u= se > of an existing RFC specification. If anything, the burden of proving the > case of how a /96 is faster/whatever vs a /64 or a /32=A0 rests on you, > otherwise just follow the existing spec, and loose the specificity. >> >> Route summaries? As the draft says clearly, /64 is the best and likely >> case is that is with dhcp pd. The /96 is a case of nd proxy or similar. >> Neither have any impact on route summaries. > > DHCP-PD's will be shorter than /64. The /64 is another assumption that is > highly limiting. I think your definition of "highly limiting" is bizarre. Informational documents do not limit anything. They are simply descriptive. Once again, we are simply documenting something that is known to work, we are not trying to enable *you* or the internet at large with a standard track document. We are documenting a known solution and running code in an informational document. >> >> In both cases above you made unsupported claims which makes me go back a= nd >> justify why your unsubstantiated claim is wrong with facts and use cases= . >> >> Please clearly substantiate your claims with examples in the future. ... >> for example, if you are going to claim this makes more routes, clearly >> articulate why you believe that. Otherwise you will be dismissed as crea= ting >> FUD. > > > > Given your previous posts something tells me that any use-case will be > dismissed as "out of scope" for your specific deployment. > FWIW a couple of cases are: > I am documenting what i know to work. If you want to write another document describing *your scenario* of something *you know to work*, please do so. > Case 1: Operator wants to assign a specific IPv4 address (public) for a C= LAT > user. Under the existing spec, the operator would need to also install an > extra /96+ route That is not 464XLAT, that is MAP-T. You seem to confuse these 2, and i assume that is the root of all your confusion and comments. Trying to do what you suggest, assigning public IPv4 addresses (and i assume ports sets ...which is MAP-T) , would directly preclude the ability of 464XLAT to do port overloading on the PLAT to get beyond 64,000 sessions per IPv4 address. It is also not dynamic. Please stop trying to pound the known implementation of 464XLAT into MAP-T, it is not helpful to the list. > Case 2: Two CLATs on a shared link segment network (eg a WiFi). How do we > route to each CLAT? http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-01#section-6.7 > etc.. >> >> >> >> >> >> >> >> >> >> >> >> >> >> > Way of resolving the issue(s) would be to: >> >> >> > - Document the experiment, the set-up=A0 and the results. >> >> >> >> >> >> draft-ietf-v6ops-464xlat-00 is not an experiment report, it is an >> >> >> informational architecture which happens to be supported by runnin= g >> >> >> code and informal network deployment reports >> >> >> >> >> >> > - Separately document any/all specific requirements, assumptions >> >> >> > or >> >> >> > operations that are not covered by existing RFCs (eg the >> >> >> > requirement for >> >> >> > XLAT to use a /96 prefix) >> >> >> > >> >> >> >> >> >> draft-ietf-v6ops-464xlat-00 does not create any new technology or >> >> >> standards. =A0I don't believe an information document that does no= t >> >> >> use >> >> >> RFC 2119 language and recommends a /96 prefix (which is one of man= y >> >> >> defined in RFC 6052) should be an issue. =A0If it is, please let m= e >> >> >> know >> >> >> why. >> >> > >> >> > >> >> > If this is a recommendation and not a spec, how would a regular >> >> > stateless >> >> > NAT64 device, like the CLAT claims to be, know that it should use a >> >> > /96 as >> >> > its source prefix for mapping v4? >> >> > >> >> >> >> The fact that is knows means that it is CLAT subset of any CPE that >> >> does 6145 >> > >> > >> > This seems to contradict the previous statement about this draft not >> > being a device spec. >> > If the CLAT is fully RFC6145 compliant, it should be clearly stated, a= nd >> > text about /96, etc removed. If you're assuming that the CLAT is a sub= set of >> > RFC6145, then it would be best if you put the specifics of those assum= ptions >> > + anything else that is needed for the spec in a separate draft. >> > >> >> Disagree. > > > You disagree with what? If you're claiming that the CLAT is fully in line > with RFC6145 compliant then why do you object to removing specificity or > assumptions (ie hard coded configuration) that is NOT present in RFC6145? > Having it both ways looks untenable. > Once again, this is an informational document describing and known working architecture that leverages existing standards and running code, both commercial and open source. It is not a new standard, and it simply shows how a specific scenario is known to work today. > Suggestion of a way forward: Just replace the text in Section 6.1, beside= s > other normative terms, with text like "The CLAT is a device conforming to > stateless NAT46 as per RFCxxxx. In the xlat464 set-up it was configured t= o > use /X (whatever prefix you found convenient. This was due to ... (whatev= er > reasons you thought of", etc. > But i do not know that to work and i do not see the benefit in expounding on theoreticals in an informational document that describes a known working scenario. The "running code" does not support the setup you speak of, and adding that does not provide a tangible benefit to the implementors. If you know things to work in a certain way, then you may document them as = such. CB > -Woj. >> >> Cb >> >> >> > -Woj. >> >> >> >> >> >> CB >> >> > >> >> > -Woj. >> >> > >> >> >> CB >> >> >> >> >> >> > -Woj. >> >> >> > >> >> >> > >> >> > >> >> > >> >> >> >> _______________________________________________ >> >> v6ops mailing list >> >> v6ops@ietf.org >> >> https://www.ietf.org/mailman/listinfo/v6ops >> >> >> > > > From shemant@cisco.com Wed Mar 14 12:42:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854F821F8633 for ; Wed, 14 Mar 2012 12:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.576 X-Spam-Level: X-Spam-Status: No, score=-9.576 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 p6QHCj4m2bY9 for ; Wed, 14 Mar 2012 12:42:19 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id CC58521F8636 for ; Wed, 14 Mar 2012 12:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=17062; q=dns/txt; s=iport; t=1331754139; x=1332963739; h=mime-version:subject:date:message-id:from:to:cc; bh=1muuihcA7uyHBlLfQdOx8YOatc9Fz4h6LOFMh5CDnvI=; b=WXzxUHTdtTH+lAAITCfmAFw5aVBKW06pvwOWejnuk/rS1ag5Gj6UHQgS FvMmTmROQNKAgBBxQE+BwCqxoc8PYtGBnr5QpYX1Av+YWyCX998x4lCLw MYPOqayW60wNY8fOxwBhZS1p8KWYXQGsegpYIYlED9xRqsxwGJBE7GSdW E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKXzYE+tJXG8/2dsb2JhbABDgk6zaIEHggkBAQEDARIBCREDSQUHBgEIEQQBAQsGFwEHRQcBAQUEAQQTCBqHYwWhKJdLijmFY2MEiCQzmz+BaIMEgT4 X-IronPort-AV: E=Sophos;i="4.73,586,1325462400"; d="scan'208,217";a="66490056" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 14 Mar 2012 19:42:18 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2EJgIJ0032377; Wed, 14 Mar 2012 19:42:18 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Mar 2012 14:42:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD021A.90D3EAD8" Date: Wed, 14 Mar 2012 14:42:16 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3042FEA7C@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PCP (RE: [v6ops] draft-ietf-v6ops-6204bis WGLC) Thread-Index: Acz96uausHYdQWx3SL2Y2BTBAuqTYQDQGRbgAAQXcoAAHPsXkAAatBrw From: "Hemant Singh (shemant)" To: X-OriginalArrivalTime: 14 Mar 2012 19:42:18.0691 (UTC) FILETIME=[90E47930:01CD021A] Cc: Alain Durand , "Dan Wang \(danwan\)" , Dave Thaler Subject: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Mar 2012 19:42:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD021A.90D3EAD8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks, =20 This is some change that Med has asked to make to the PCP text in = rfc6204bis. Please provide comments. Cc to some PCP and DS-Lite = individuals as well. =20 Thanks, =20 Hemant =20 From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] = Sent: Wednesday, March 14, 2012 3:11 AM To: Hemant Singh (shemant) Cc: JACQUENET Christian OLNC/NAD/TIP Subject: RE: PCP (RE: [v6ops] draft-ietf-v6ops-6204bis WGLC) =20 Re-, =20 Please see inline. =20 Cheers, Med =20 =09 ________________________________ De : Hemant Singh (shemant) [mailto:shemant@cisco.com]=20 Envoy=E9 : mardi 13 mars 2012 18:11 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; Hemant Singh (shemant) Cc : JACQUENET Christian OLNC/NAD/TIP Objet : RE: PCP (RE: [v6ops] draft-ietf-v6ops-6204bis WGLC) Med, =20 =20 -----Original Message----- From: mohamed.boucadair@orange.com = [mailto:mohamed.boucadair@orange.com]=20 Sent: Tuesday, March 13, 2012 11:32 AM To: Hemant Singh (shemant) Cc: JACQUENET Christian OLNC/NAD/TIP Subject: PCP (RE: [v6ops] draft-ietf-v6ops-6204bis WGLC) =20 >Please see below a text proposal to solve the comment from O. Troan. = If you want me to send this e-mail in the v6ops ML, I can do. =20 =20 >NEW: >=20 > The WAN interface of the CE router SHOULD support an IPv4 PCP = client > as specified in [I-D.ietf-pcp-base] for use by applications on the = CE > Router. This document takes no position on whether such > functionality is enabled by default or mechanisms by which users > would configure the functionality. =20 Note above that the text says "IPv4 PCP client". =20 [Med] I kept that text from the draft as I understood it as: "PCP = client to control a NAT44". You can safely replace "IPv4 PCP client" = with "PCP client".=20 =20 Now I am confused by the text below that is referring to "native = IPv6"? We all were expecting IPv4 PCP use case and thus if you can = explain what is the IPv6 PCP use case? =20 [Med] For DS-Lite we have two alternatives for PCP deployment: =20 (1) send PCP messages over the DS-Lite tunnel: PCP over UDP over IPv4 = over IPv6. (2) send PCP messages using native IPv6: PCP over UDP over IPv6. For = this to work: the PCP client must use the same IPv6 address as B4 when = issuing PCP requests.=20 =20 For the plain IPv6 mode, the PCP server discovery method as defined in = the base PCP spec is broken: * base spec says: use any configured pcp server, if none use the = default router. * for the plain IPv6 ds-lite mode: the procedure should be "use any = configured pcp server, if none use the AFTR." =20 Please let me know if it is more clear.=20 =20 The rest of the text below looks good to me. =20 Thanks and cheers back, =20 Hemant =20 > The PCP client SHOULD follow the procedure specified in Section > 8.1 of [I-D.ietf-pcp-base] to discover its PCP server. In = DS-Lite > context, if PCP messages are exchanged using native IPv6 (i.e., > IPv4-in-IPv6 is not used) and no PCP server is configured, the = PCP > client MUST use the address of the AFTR as its PCP server. =20 > Handling PCP requests from PCP clients in the LAN side of the CE > Router is out of scope. =20 ------_=_NextPart_001_01CD021A.90D3EAD8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Folks,

 

This is some change that = Med has asked to make to the PCP text in rfc6204bis.=A0=A0 Please = provide comments.=A0 Cc to some PCP and DS-Lite individuals as = well.

 

Thanks,

 

Hemant

 

From:= = mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] =
Sent: Wednesday, March 14, 2012 3:11 AM
To: Hemant = Singh (shemant)
Cc: JACQUENET Christian = OLNC/NAD/TIP
Subject: RE: PCP (RE: [v6ops] = draft-ietf-v6ops-6204bis WGLC)

 

Re-,

 

Please = see inline.

 

Cheers,

Med

 

De : Hemant = Singh (shemant) [mailto:shemant@cisco.com]
Envoy=E9 : = mardi 13 mars 2012 18:11
=C0 : BOUCADAIR Mohamed = OLNC/NAD/TIP; Hemant Singh (shemant)
Cc : JACQUENET = Christian OLNC/NAD/TIP
Objet : RE: PCP (RE: [v6ops] = draft-ietf-v6ops-6204bis WGLC)

Med,

 

 

-----Original Message-----
From: mohamed.boucadair@orange.com = [mailto:mohamed.boucadair@orange.com]
Sent: Tuesday, March 13, 2012 = 11:32 AM
To: Hemant Singh (shemant)
Cc: JACQUENET Christian = OLNC/NAD/TIP
Subject: PCP (RE: [v6ops] draft-ietf-v6ops-6204bis = WGLC)

 

>Please see below a text proposal to solve the comment from O. = Troan. If you want me to send this e-mail in the v6ops ML, I can = do.

 

 

>NEW:

> 

>   The WAN interface = of the CE router SHOULD support an IPv4 PCP = client

>   as specified in = [I-D.ietf-pcp-base] for use by applications on the = CE

>   Router.  This = document takes no position on whether such

>   functionality is enabled by default or mechanisms = by which users

>   would configure the = functionality.

 

Note above that the text says "IPv4 PCP = client”.  
[Med] I kept that text from the draft as I = understood it as: "PCP client to control a NAT44". You = can safely replace "IPv4 PCP client" with "PCP = client".

 

 Now I am confused = by the text below that is referring to “native IPv6”?  = We all were expecting IPv4 PCP use case and thus if you can explain what = is the IPv6 PCP use case? 
[Med] For DS-Lite we have two alternatives for PCP = deployment:

 

(1) send = PCP messages over the DS-Lite tunnel: PCP over UDP over IPv4 over = IPv6.

(2) send = PCP messages using native IPv6:  PCP over UDP over = IPv6. For this to work: the PCP client must use the same IPv6 = address as B4 when issuing PCP requests. 

 

For the = plain IPv6 mode, the PCP server discovery method as defined in the base = PCP spec is broken:

* base = spec says: use any configured pcp server, if none use = the default router.

* for = the plain IPv6 ds-lite mode: the procedure should be "use any = configured pcp server, if none use = the AFTR."

 

Please = let me know if it is more clear.

 

 The rest of the = text below looks good to me.

 

Thanks and cheers back,

 

Hemant

 

>      The PCP client SHOULD follow = the procedure specified in Section

>      8.1 of [I-D.ietf-pcp-base] to = discover its PCP server.  In DS-Lite

>      context, if PCP messages are = exchanged using native IPv6 (i.e.,

>      IPv4-in-IPv6 is not used) and = no PCP server is configured, the PCP

>      client MUST use the address of = the AFTR as its PCP server.

 

>      = Handling PCP requests from PCP clients in the LAN side of the = CE

>      = Router is out of scope.

 

------_=_NextPart_001_01CD021A.90D3EAD8-- From Carl.Wuyts@technicolor.com Thu Mar 15 00:02:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F5511E808C for ; Thu, 15 Mar 2012 00:02:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[AWL=-2.091, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 q28LCirUirHR for ; Thu, 15 Mar 2012 00:02:27 -0700 (PDT) Received: from psmtp.com (na3sys009aog127.obsmtp.com [74.125.149.107]) by ietfa.amsl.com (Postfix) with ESMTP id 1B81021F862A for ; Thu, 15 Mar 2012 00:02:26 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob127.postini.com ([74.125.148.12]) with SMTP ID DSNKT2GT/PTjHrNPyY8oe7QvOs5GiEEfV4+f@postini.com; Thu, 15 Mar 2012 00:02:27 PDT Received: from MOPESMAILHC01.eu.thmulti.com (141.11.100.25) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Thu, 15 Mar 2012 08:00:07 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Thu, 15 Mar 2012 08:00:22 +0100 From: Wuyts Carl To: "Hemant Singh (shemant)" , "v6ops@ietf.org" Date: Thu, 15 Mar 2012 08:00:21 +0100 Thread-Topic: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) Thread-Index: Acz96uausHYdQWx3SL2Y2BTBAuqTYQDQGRbgAAQXcoAAHPsXkAAatBrwABe3B0A= Message-ID: <867F4B6A1672E541A94676D556793ACD0EB990DB91@MOPESMBX01.eu.thmulti.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C3042FEA7C@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3042FEA7C@XMB-RCD-109.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_867F4B6A1672E541A94676D556793ACD0EB990DB91MOPESMBX01eut_" MIME-Version: 1.0 Cc: Alain Durand , "Dan Wang \(danwan\)" , Dave Thaler Subject: Re: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 07:02:30 -0000 --_000_867F4B6A1672E541A94676D556793ACD0EB990DB91MOPESMBX01eut_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Looks ok to me Regs carl From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of H= emant Singh (shemant) Sent: woensdag 14 maart 2012 20:42 To: v6ops@ietf.org Cc: Alain Durand; Dan Wang (danwan); Dave Thaler Subject: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) Folks, This is some change that Med has asked to make to the PCP text in rfc6204bi= s. Please provide comments. Cc to some PCP and DS-Lite individuals as we= ll. Thanks, Hemant From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Wednesday, March 14, 2012 3:11 AM To: Hemant Singh (shemant) Cc: JACQUENET Christian OLNC/NAD/TIP Subject: RE: PCP (RE: [v6ops] draft-ietf-v6ops-6204bis WGLC) Re-, Please see inline. Cheers, Med ________________________________ De : Hemant Singh (shemant) [mailto:shemant@cisco.com] Envoy=E9 : mardi 13 mars 2012 18:11 =C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; Hemant Singh (shemant) Cc : JACQUENET Christian OLNC/NAD/TIP Objet : RE: PCP (RE: [v6ops] draft-ietf-v6ops-6204bis WGLC) Med, -----Original Message----- From: mohamed.boucadair@orange.com [ma= ilto:mohamed.boucadair@orange.com] Sent: Tuesday, March 13, 2012 11:32 AM To: Hemant Singh (shemant) Cc: JACQUENET Christian OLNC/NAD/TIP Subject: PCP (RE: [v6ops] draft-ietf-v6ops-6204bis WGLC) >Please see below a text proposal to solve the comment from O. Troan. If yo= u want me to send this e-mail in the v6ops ML, I can do. >NEW: > > The WAN interface of the CE router SHOULD support an IPv4 PCP client > as specified in [I-D.ietf-pcp-base] for use by applications on the CE > Router. This document takes no position on whether such > functionality is enabled by default or mechanisms by which users > would configure the functionality. Note above that the text says "IPv4 PCP client". [Med] I kept that text from the draft as I understood it as: "PCP client to= control a NAT44". You can safely replace "IPv4 PCP client" with "PCP clien= t". Now I am confused by the text below that is referring to "native IPv6"? W= e all were expecting IPv4 PCP use case and thus if you can explain what is = the IPv6 PCP use case? [Med] For DS-Lite we have two alternatives for PCP deployment: (1) send PCP messages over the DS-Lite tunnel: PCP over UDP over IPv4 over = IPv6. (2) send PCP messages using native IPv6: PCP over UDP over IPv6. For this = to work: the PCP client must use the same IPv6 address as B4 when issuing P= CP requests. For the plain IPv6 mode, the PCP server discovery method as defined in the = base PCP spec is broken: * base spec says: use any configured pcp server, if none use the default ro= uter. * for the plain IPv6 ds-lite mode: the procedure should be "use any configu= red pcp server, if none use the AFTR." Please let me know if it is more clear. The rest of the text below looks good to me. Thanks and cheers back, Hemant > The PCP client SHOULD follow the procedure specified in Section > 8.1 of [I-D.ietf-pcp-base] to discover its PCP server. In DS-Lite > context, if PCP messages are exchanged using native IPv6 (i.e., > IPv4-in-IPv6 is not used) and no PCP server is configured, the PCP > client MUST use the address of the AFTR as its PCP server. > Handling PCP requests from PCP clients in the LAN side of the CE > Router is out of scope. --_000_867F4B6A1672E541A94676D556793ACD0EB990DB91MOPESMBX01eut_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Looks ok to me

Regs

carl

<= /div>

 

From: v6ops-bounces@ietf.org [mai= lto:v6ops-bounces@ietf.org] On Behalf Of Hemant Singh (shemant)
<= b>Sent: woensdag 14 maart 2012 20:42
To: v6ops@ietf.org
Cc: Alain Durand; Dan Wang (danwan); Dave Thaler
Subject: [v= 6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC)

 

Folks,

=  

This is some change that Med has asked to= make to the PCP text in rfc6204bis.   Please provide comments.&n= bsp; Cc to some PCP and DS-Lite individuals as well.

<= p class=3DMsoNormal> <= /p>

Thanks,

 

Hemant<= /o:p>

&nb= sp;

From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.co= m]
Sent: Wednesday, March 14, 2012 3:11 AM
To: Hem= ant Singh (shemant)
Cc: JACQUENET Christian OLNC/NAD/TIP
Su= bject: RE: PCP (RE: [v6ops] draft-ietf-v6ops-6204bis WGLC)

 

Re-,

 <= /p>

Please see inline.

 

Cheers,

Med

 

De = : Hemant Singh (shemant) [mailto:shemant@cisco.com]
Envoy=E9 : mardi 13 mars 201= 2 18:11
=C0 : BOUCADAIR Mohamed OLNC/NAD/TIP; Hemant Singh (= shemant)
Cc : JACQUENET Christian OLNC/NAD/TIP
Objet&n= bsp;: RE: PCP (RE: [v6ops] draft-ietf-v6ops-6204bis WGLC)<= o:p>

Med,

 

 <= /p>

-----O= riginal Message-----
From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
Sent: Tuesday, March= 13, 2012 11:32 AM
To: Hemant Singh (shemant)
Cc: JACQUENET Christian= OLNC/NAD/TIP
Subject: PCP (RE: [v6ops] draft-ietf-v6ops-6204bis WGLC)

 

>Please see below a text proposal to solv= e the comment from O. Troan. If you want me to send this e-mail in the v6op= s ML, I can do.

 

 

=

>NEW:<= o:p>

> 

>   The WAN interface of th= e CE router SHOULD support an IPv4 PCP client

>   = as specified in [I-D.ietf-pcp-base] for use by applications on the CE<= /o:p>

>   Router.  This document takes no position on wh= ether such

>   functionality is enabled by default= or mechanisms by which users

= >   would configure = the functionality.

 

Note above th= at the text says "IPv4 PCP client”.  
[Med] = I kept that text from the draft as I understood it as: "PCP = client to control a NAT44". You can safely replace "IPv4 PCP clie= nt" with "PCP client".

 

 Now I am confused by the text below = that is referring to “native IPv6”?  We all were expecting= IPv4 PCP use case and thus if you can explain what is the IPv6 PCP use cas= e? 
[Med] For DS-Lite we have two alternatives for PCP depl= oyment:

 

<= p class=3DMsoPlainText>(1) send PCP messages over the DS-Lite tunnel: PCP over U= DP over IPv4 over IPv6.

(2) send PC= P messages using native IPv6:  PCP over UDP over IPv6. For t= his to work: the PCP client must use the same IPv6 address as B4 when issui= ng PCP requests. 

 <= o:p>

For the plain IPv6 mode, the PCP server di= scovery method as defined in the base PCP spec is broken:=

* base spec says: use any configured pcp server= , if none use the default router.

* for the plain IPv6 ds-lite mode: the procedure should be "use an= y configured pcp server, if none use the AFTR."=

 

Please = let me know if it is more clear.

 

 The rest of the text below looks good to = me.

 

Thanks and cheer= s back,

 

Hemant<= /o:p>

 

>      Th= e PCP client SHOULD follow the procedure specified in Section

&= gt;      8.1 of [I-D.ietf-pcp-base] to discover it= s PCP server.  In DS-Lite

>    &nbs= p; context, if PCP messages are exchanged using native IPv6 (i.e.,

>      IPv4-in-IPv6 is not used) and no PCP= server is configured, the PCP

>    &nbs= p; client MUST use the address of the AFTR as its PCP server.

<= o:p> 

>      Handling PCP requests = from PCP clients in the LAN side of the CE

>  &nbs= p;   Router is out of scope.

 =

= --_000_867F4B6A1672E541A94676D556793ACD0EB990DB91MOPESMBX01eut_-- From wdec.ietf@gmail.com Thu Mar 15 02:03:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C58621F86B8 for ; Thu, 15 Mar 2012 02:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.961 X-Spam-Level: X-Spam-Status: No, score=-2.961 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 V1kEXsKd7VMB for ; Thu, 15 Mar 2012 02:03:01 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6554F21F86B3 for ; Thu, 15 Mar 2012 02:03:01 -0700 (PDT) Received: by ghbg16 with SMTP id g16so3170099ghb.31 for ; Thu, 15 Mar 2012 02:03:01 -0700 (PDT) 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=Jgii5n7r2egedplMUFyJdzG+2+afg2Evc44LCLsNDDA=; b=TP3p0hIWrsZL9Fw9uHmZ79WtaQHeJ2WFsa4zZ5ozv4sThLPzwuPkbWXRXfoF7CB9yL RLnPFsU5TQmmo1gFzRq7/Th1tpTYqfhktQM2EHZHtFwOhy4Ye46CKXrWd5/BBFMBZopy /8acbEniYzaMDilsD9rpt0oAPJJZNHSF56isuO3Bbl7tRj2GwozNvydoklRUrEMQUpIy utjKqrJ3IeLTdxVyZdNyd3x/tbfcTOMy3pNPPVul16i8RJAfbFNNiZRXkH7XJeJ93UQq RaLEcdOz8kItT8X5sIVQvOaWgnl+Xm3TAzWRVkNtNzz4s137ZA9dEx93T6oDS32KYSrk wpqg== MIME-Version: 1.0 Received: by 10.224.220.211 with SMTP id hz19mr381565qab.33.1331802180903; Thu, 15 Mar 2012 02:03:00 -0700 (PDT) Received: by 10.229.218.4 with HTTP; Thu, 15 Mar 2012 02:03:00 -0700 (PDT) In-Reply-To: References: Date: Thu, 15 Mar 2012 10:03:00 +0100 Message-ID: From: Wojciech Dec To: Cameron Byrne Content-Type: multipart/alternative; boundary=20cf306f732ae7622e04bb445bdb Cc: v6ops@ietf.org Subject: Re: [v6ops] Nomative language in draft-ietf-v6ops-464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 09:03:02 -0000 --20cf306f732ae7622e04bb445bdb Content-Type: text/plain; charset=ISO-8859-1 > > > > Basic question: Why are you asking the WG to adopt your document and > define > > your architecture CLAT and all? If you're seeking the blessing for > operating > > a standard based NAT64 network set-up in a specific way that you call > > It's an informational document, not a standard. > You haven't answered a major question; what is the purpose/goal of the document? Please also see: http://tools.ietf.org/html/rfc2026#section-4.2.2 regarding Informational specification track. I think your definition of "highly limiting" is bizarre. > Informational documents do not limit anything. They are simply > descriptive. > > Once again, we are simply documenting something that is known to work, > we are not trying to enable *you* or the internet at large with a > standard track document. > You are seeking WG adoption of the document, which to most means that you want contribution and backing of the wider IETF WG community. If you have no interest in this, I would suggest that this work be progressed as an individual contribution. There should be no issue with that if all you seek is to document a setup that works (we do already know that NAT64 works - thanks). If not, then what is it that you're seeking/expecting from the WG adoption of this document? > > Trying to do what you suggest, assigning public IPv4 addresses (and i > assume ports sets ...which is MAP-T) , would directly preclude the > ability of 464XLAT to do port overloading on the PLAT to get beyond > 64,000 sessions per IPv4 address. It is also not dynamic. Please > stop trying to pound the known implementation of 464XLAT into MAP-T, > it is not helpful to the list. > Assigning a public IPv4 v6 embedded address, without sharing, is a legitimate use-case and applicable to the general NAT64 spec - it's not MAP-T. How does xlat handle this use-case would be helpful to understand. You haven't explained that. > > > Suggestion of a way forward: Just replace the text in Section 6.1, > besides > > other normative terms, with text like "The CLAT is a device conforming to > > stateless NAT46 as per RFCxxxx. In the xlat464 set-up it was configured > to > > use /X (whatever prefix you found convenient. This was due to ... > (whatever > > reasons you thought of", etc. > > > > But i do not know that to work and i do not see the benefit in > expounding on theoreticals in an informational document that describes > a known working scenario. The "running code" does not support the > setup you speak of, and adding that does not provide a tangible > benefit to the implementors. > I don't quite see why you object to the proposed alternative text. But, if as you say, the running code, based on you spec, does not support such a setup, then it's not regular NAT64 as you claim it to be. Your statement about "benefit to implementors" again underscores the fact that you're trying to define/recommend (ie specify) implementations, based on some "described" sub-set of NAT64 and some assumptions, rather than simply document a setup that uses regular NAT64 functionality (as I suggested you did). While there may be a valid case for such a "description", the case for it should validated a bit more rather than just saying "I have it running in my network", and effectively "I don't care about it working on other networks where the same problem applies". -Woj. > > If you know things to work in a certain way, then you may document them as > such. > > CB > > > > -Woj. > >> > >> Cb > >> > >> > >> > -Woj. > >> >> > >> >> > >> >> CB > >> >> > > >> >> > -Woj. > >> >> > > >> >> >> CB > >> >> >> > >> >> >> > -Woj. > >> >> >> > > >> >> >> > > >> >> > > >> >> > > >> >> > >> >> _______________________________________________ > >> >> v6ops mailing list > >> >> v6ops@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/v6ops > >> >> > >> > > > > > > --20cf306f732ae7622e04bb445bdb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
>
> Basic question: Why are you asking the WG to adopt your document and d= efine
> your architecture CLAT and all? If you're seeking the blessing for= operating
> a standard based NAT64 network set-up in a specific way that you call<= br>
It's an informational document, not a standard.

You haven't answered a major question; what = is the purpose/goal of the document?
Please also see: http://tools.ietf.org/html/rfc2= 026#section-4.2.2 regarding Informational specification track.

I think your defini= tion of "highly limiting" is bizarre.
Informational documents do not limit anything. =A0They are simply
descriptive.

Once again, we are simply documenting something that is known to work,
we are not trying to enable *you* =A0or the internet at large with a
standard track document.

You are seeking WG adopti= on of the document, which to most means that you want contribution and back= ing of the wider IETF WG community. If you have no interest in this, I woul= d suggest that this work be progressed as an individual contribution. There= should be no issue with that if all you seek is to document a setup that w= orks (we do already know that NAT64 works - thanks). If not, then what is i= t that you're seeking/expecting from the WG adoption of this document?<= br> =A0

Trying to do what you suggest, assigning public IPv4 addresses (and i
assume ports sets ...which is MAP-T) , would directly preclude the
ability of 464XLAT to do port overloading on the PLAT to get beyond
64,000 sessions per IPv4 address. =A0It is also not dynamic. =A0Please
stop trying to pound the known implementation of 464XLAT into MAP-T,
it is not helpful to the list.

Assigning a public = IPv4 v6 embedded address, without sharing, is a legitimate use-case and app= licable to the general NAT64 spec - it's not MAP-T. How does xlat handl= e this use-case would be helpful to understand. You haven't explained t= hat.

> Suggestion of a way forward: Just replace the text in Section 6.1, bes= ides
> other normative terms, with text like "The CLAT is a device confo= rming to
> stateless NAT46 as per RFCxxxx. In the xlat464 set-up it was configure= d to
> use /X (whatever prefix you found convenient. This was due to ... (wha= tever
> reasons you thought of", etc.
>

But i do not know that to work and i do not see the benefit in
expounding on theoreticals in an informational document that describes
a known working scenario. =A0The "running code" does not support = the
setup you speak of, and adding that does not provide a tangible
benefit to the implementors.

I don't quite see= why you object to the proposed alternative text. But, if as you say, the r= unning code, based on you spec, does not support such a setup, then it'= s not regular NAT64 as you claim it to be.
Your statement about "benefit to implementors" again underscores = the fact that you're trying to define/recommend (ie specify) implementa= tions, based on some "described" sub-set of NAT64 and some assump= tions, rather than simply document a setup that uses regular NAT64 function= ality (as I suggested you did). While there may be a valid case for such a = "description", the case for it should validated a bit more rather= than just saying "I have it running in my network", and effectiv= ely "I don't care about it working on other networks where the sam= e problem applies".

-Woj.

If you know things to work in a certain way, then you may document them as = such.

CB


> -Woj.
>>
>> Cb
>>
>>
>> > -Woj.
>> >>
>> >>
>> >> CB
>> >> >
>> >> > -Woj.
>> >> >
>> >> >> CB
>> >> >>
>> >> >> > -Woj.
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >>
>> >> _______________________________________________
>> >> v6ops mailing list
>> >> v6ops@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/v6ops
>> >>
>> >
>
>

--20cf306f732ae7622e04bb445bdb-- From hansliu@gmail.com Thu Mar 15 03:31:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5913B21F86B6 for ; Thu, 15 Mar 2012 03:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 S3TnElnTTT02 for ; Thu, 15 Mar 2012 03:31:37 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0D40F21F86B4 for ; Thu, 15 Mar 2012 03:31:36 -0700 (PDT) Received: by lagj5 with SMTP id j5so2653560lag.31 for ; Thu, 15 Mar 2012 03:31:36 -0700 (PDT) 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:content-transfer-encoding; bh=r4xBg66j+bOys0Wnl3ZPCyqm4H4klKOuSTNO+udwIks=; b=Zp6EwYgmnEmKiSVxjGBl36h+VnqllJrqAayIeyJ2sh2QtzCyWZEe98QeVehlHNK4Nf 9DHTvqXGJIahVL6R4axM3n1QrsHYNN8HUTIBP1KC15yqY91J5RfnS6z7hbjcjJhdtuVh d5yUxnqSfbmdxy157JXXTa+PH/gPq+mLEKMppxltbE5ay6wA8lk6rPEUU2hRldeDpEtG VWYTiiViPZFePoC5wxBHG97FKC7r/PzBJyzkiMaJkz6oNwsIy4o1ejCvANJ/zJRL/Db9 37sWT8CJLJM5S0nHKfFbesHfCM+GEwdyXTEL81ioKt9WIgWxVq2Yvi2BTi6/X5x9NYPC ih1Q== MIME-Version: 1.0 Received: by 10.112.17.163 with SMTP id p3mr2327973lbd.35.1331807495982; Thu, 15 Mar 2012 03:31:35 -0700 (PDT) Received: by 10.112.37.71 with HTTP; Thu, 15 Mar 2012 03:31:35 -0700 (PDT) In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3042FEA7C@XMB-RCD-109.cisco.com> References: <5B6B2B64C9FE2A489045EEEADDAFF2C3042FEA7C@XMB-RCD-109.cisco.com> Date: Thu, 15 Mar 2012 18:31:35 +0800 Message-ID: From: Hans Liu To: "Hemant Singh (shemant)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Hans Liu , v6ops@ietf.org, Alain Durand , "Dan Wang \(danwan\)" , Dave Thaler Subject: Re: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 10:31:38 -0000 I'm ok with it. Thanks, Hans On Thu, Mar 15, 2012 at 3:42 AM, Hemant Singh (shemant) wrote: > Folks, > > > > This is some change that Med has asked to make to the PCP text in > rfc6204bis.=C2=A0=C2=A0 Please provide comments.=C2=A0 Cc to some PCP and= DS-Lite > individuals as well. > > > > Thanks, > > > > Hemant > > > > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: Wednesday, March 14, 2012 3:11 AM > To: Hemant Singh (shemant) > Cc: JACQUENET Christian OLNC/NAD/TIP > Subject: RE: PCP (RE: [v6ops] draft-ietf-v6ops-6204bis WGLC) > > > > Re-, > > > > Please see inline. > > > > Cheers, > > Med > > > > ________________________________ > > De=C2=A0: Hemant Singh (shemant) [mailto:shemant@cisco.com] > Envoy=C3=A9=C2=A0: mardi 13 mars 2012 18:11 > =C3=80=C2=A0: BOUCADAIR Mohamed OLNC/NAD/TIP; Hemant Singh (shemant) > Cc=C2=A0: JACQUENET Christian OLNC/NAD/TIP > Objet=C2=A0: RE: PCP (RE: [v6ops] draft-ietf-v6ops-6204bis WGLC) > > Med, > > > > > > -----Original Message----- > From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com] > Sent: Tuesday, March 13, 2012 11:32 AM > To: Hemant Singh (shemant) > Cc: JACQUENET Christian OLNC/NAD/TIP > Subject: PCP (RE: [v6ops] draft-ietf-v6ops-6204bis WGLC) > > > >>Please see below a text proposal to solve the comment from O. Troan. If y= ou >> want me to send this e-mail in the v6ops ML, I can do. > > > > > >>NEW: > >> > >>=C2=A0=C2=A0 The WAN interface of the CE router SHOULD support an IPv4 PC= P client > >>=C2=A0=C2=A0 as specified in [I-D.ietf-pcp-base] for use by applications = on the CE > >>=C2=A0=C2=A0 Router.=C2=A0 This document takes no position on whether suc= h > >>=C2=A0=C2=A0 functionality is enabled by default or mechanisms by which u= sers > >>=C2=A0=C2=A0 would configure the functionality. > > > > Note above that the text says "IPv4 PCP client=E2=80=9D. > [Med]=C2=A0I kept that text from the draft=C2=A0as I understood it as: "P= CP=C2=A0client to > control a NAT44". You can safely replace "IPv4 PCP client" with "PCP > client". > > > > =C2=A0Now I am confused by the text below that is referring to =E2=80=9Cn= ative IPv6=E2=80=9D?=C2=A0 We > all were expecting IPv4 PCP use case and thus if you can explain what is = the > IPv6 PCP use case? > [Med]=C2=A0For DS-Lite we have two alternatives for PCP deployment: > > > > (1) send PCP messages over the DS-Lite tunnel: PCP over UDP over IPv4 ove= r > IPv6. > > (2) send PCP messages=C2=A0using native IPv6:=C2=A0 PCP over UDP over IPv= 6.=C2=A0For this > to work: the PCP client must use the same IPv6 address as B4 when issuing > PCP requests. > > > > For the plain IPv6 mode, the PCP server discovery method as defined in th= e > base PCP spec is broken: > > * base spec says:=C2=A0use any configured pcp server, if none use the=C2= =A0default > router. > > * for the plain IPv6 ds-lite mode: the procedure should be "use any > configured pcp server, if none use the=C2=A0AFTR." > > > > Please let me know if it is more clear. > > > > =C2=A0The rest of the text below looks good to me. > > > > Thanks and cheers back, > > > > Hemant > > > >>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The PCP client SHOULD follow the procedure= specified in Section > >>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 8.1 of [I-D.ietf-pcp-base] to discover its= PCP server.=C2=A0 In DS-Lite > >>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 context, if PCP messages are exchanged usi= ng native IPv6 (i.e., > >>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 IPv4-in-IPv6 is not used) and no PCP serve= r is configured, the PCP > >>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 client MUST use the address of the AFTR as= its PCP server. > > > >>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Handling PCP requests from PCP clients in = the LAN side of the CE > >>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Router is out of scope. > > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --=20 Instead of following the fashion, we lead it through. From Carl.Wuyts@technicolor.com Thu Mar 15 03:33:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5AC621F8527 for ; Thu, 15 Mar 2012 03:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 XOaMhplEP5rk for ; Thu, 15 Mar 2012 03:33:53 -0700 (PDT) Received: from na3sys009aog112.obsmtp.com (na3sys009aog112.obsmtp.com [74.125.149.207]) by ietfa.amsl.com (Postfix) with ESMTP id D362621F84FC for ; Thu, 15 Mar 2012 03:33:52 -0700 (PDT) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob112.postini.com ([74.125.148.12]) with SMTP ID DSNKT2HFkBFmRThyDqUZ+Y5x0XGLvp46Chek@postini.com; Thu, 15 Mar 2012 03:33:53 PDT 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.192.1; Thu, 15 Mar 2012 11:30:27 +0100 Received: from MOPESMBX01.eu.thmulti.com ([141.11.100.105]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Thu, 15 Mar 2012 11:30:33 +0100 From: Wuyts Carl To: "v6ops@ietf.org" Date: Thu, 15 Mar 2012 11:30:32 +0100 Thread-Topic: RFC6204bis-07 Thread-Index: Ac0ClqZ1Ha71E+m/RA+Ss20G/TTopw== Message-ID: <867F4B6A1672E541A94676D556793ACD0EB995043C@MOPESMBX01.eu.thmulti.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_867F4B6A1672E541A94676D556793ACD0EB995043CMOPESMBX01eut_" MIME-Version: 1.0 Subject: [v6ops] RFC6204bis-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 10:33:55 -0000 --_000_867F4B6A1672E541A94676D556793ACD0EB995043CMOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, One which sort of slipped through my review is the following (although I mi= ght have commented on this one before): "" WPD-3: The IPv6 CE router MUST be prepared to accept a delegated prefix size different from what is given in the hint. If the delegated prefix is too small to address all of its interfaces, the IPv6 CE router SHOULD log a system management error. "" The issue I can see is with "... if the delegated prefix is too small to ad= dress all of its interfaces ...". Too small, what is that exactly ? I don= 't think the CPE should first inspect all of its LAN interfaces (count them= ) and then judge whether or not the PD is "large enough". Someone could ev= en reserve something from the pd for the loop, adding an extra prefix, shou= ld this one be counted too in this case ? What with configuration changes = ? What if the customer expects to have multiple prefixes on each or some L= AN intfs, should the CPE have some multiplier function to calculate ? More= over, it must also check the pd-exclude, if present. Isn't this all going a bit too far ? What about the result when it is too small ? You hand out what you have ? = or you don't hand out anything, so just logging ? but the logging is no MU= ST, hence no-one might notice, apart from the end-user who can or cannot br= owse the web ? Regs Carl --_000_867F4B6A1672E541A94676D556793ACD0EB995043CMOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,<= /p>

 

One which= sort of slipped through my review is the following (although I might have = commented on this one before):

“&#= 8221;

WPD-3:  The IPv6= CE router MUST be prepared to accept a delegated

       &nb= sp;   prefix size different from what is given in the hint. = If the

  =          delegated prefix is too sm= all to address all of its

           interf= aces, the IPv6 CE router SHOULD log a system management

      &nb= sp;    error.

 

“”

The issue I can see is with “…= if the delegated prefix is too small to address all of its interfaces R= 30;”.  Too small, what is that exactly ?  I don’t thi= nk the CPE should first inspect all of its LAN interfaces (count them) and = then judge whether or not the PD is “large enough”.  Someo= ne could even reserve something from the pd for the loop, adding an extra p= refix, should this one be counted too in this case ?  What with config= uration changes ?  What if the customer expects to have multiple prefi= xes on each or some LAN intfs, should the CPE have some multiplier function= to calculate ?  Moreover, it must also check the pd-exclude, if prese= nt.

Isn’t this all going a bit too= far ?

What about the result when it is = too small ?  You hand out what you have ? or you don’t hand out = anything, so just logging ?  but the logging is no MUST, hence no-one = might notice, apart from the end-user who can or cannot browse the web ?

 

= Regs

Carl

= --_000_867F4B6A1672E541A94676D556793ACD0EB995043CMOPESMBX01eut_-- From shemant@cisco.com Thu Mar 15 04:36:51 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659B821F86B5 for ; Thu, 15 Mar 2012 04:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.891 X-Spam-Level: X-Spam-Status: No, score=-9.891 tagged_above=-999 required=5 tests=[AWL=0.707, 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 YKoR6-tG1Zih for ; Thu, 15 Mar 2012 04:36:47 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id C44A921F86B1 for ; Thu, 15 Mar 2012 04:36:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=9869; q=dns/txt; s=iport; t=1331811406; x=1333021006; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=8oZW7mfCzOUZQwCQph1o2rkO/FwAVr+E4R8nikF/tqc=; b=NKKGrcsNyubx0wn0pt4xHWreHXGP7+Hmfu3/C3shURB4D74XuF3D38sh xFT2lvICtxkwmPfQpqkOISsu6RSpOfc/DtzIDK+SbDSSnsTsfV36pyn71 kJ135x6Djdeax4U2OzXD5yzd9CMvDr0i1qFPDIzSnQCk8NXYd4bT12fLU U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAGvTYU+tJXG+/2dsb2JhbABDgkWzYIEHggkBAQEEEgEJEQNZAgEIEQQBAQsGFwEGAUUJCAEBBAESCBqHaJscnzGQJGMEiFebSYFogwQ X-IronPort-AV: E=Sophos;i="4.73,590,1325462400"; d="scan'208,217";a="66681091" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 15 Mar 2012 11:36:46 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2FBaj1x031070; Thu, 15 Mar 2012 11:36:45 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Mar 2012 06:36:45 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD029F.E6BDC758" Date: Thu, 15 Mar 2012 06:36:44 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3042FEBDB@XMB-RCD-109.cisco.com> In-Reply-To: <867F4B6A1672E541A94676D556793ACD0EB995043C@MOPESMBX01.eu.thmulti.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] RFC6204bis-07 Thread-Index: Ac0ClqZ1Ha71E+m/RA+Ss20G/TTopwABrJ9Q References: <867F4B6A1672E541A94676D556793ACD0EB995043C@MOPESMBX01.eu.thmulti.com> From: "Hemant Singh (shemant)" To: "Wuyts Carl" , X-OriginalArrivalTime: 15 Mar 2012 11:36:45.0986 (UTC) FILETIME=[E6DC3820:01CD029F] Subject: Re: [v6ops] RFC6204bis-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 11:36:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD029F.E6BDC758 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable /64 is too small because the SLAAC addressing can't be supported on the CE router LAN. Thereafter, with hierarchical sub-delegation, the CE router splits the PD based on the number of LAN subnets rounded up to the nearest power of two. Further, the specification does not bother with LAN physical ports or virtual network interfaces such as a loopback. The specification uses the term of "interface" that is assigned a subnet. It is ridiculously simple math. For example, if an SP gave the CE a /63 and if the CE needs two subnets, the PD is too small for hierarchical sub-delegation. =20 The MUST on the system management error looks ok to me. If the CE can't sub-delegate the PD in the LAN, the CE is a brick for IPv6 services..=20 =20 Hemant =20 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Wuyts Carl Sent: Thursday, March 15, 2012 6:31 AM To: v6ops@ietf.org Subject: [v6ops] RFC6204bis-07 =20 All, =20 One which sort of slipped through my review is the following (although I might have commented on this one before): "" WPD-3: The IPv6 CE router MUST be prepared to accept a delegated prefix size different from what is given in the hint. If the delegated prefix is too small to address all of its interfaces, the IPv6 CE router SHOULD log a system management error. =20 "" The issue I can see is with "... if the delegated prefix is too small to address all of its interfaces ...". Too small, what is that exactly ? I don't think the CPE should first inspect all of its LAN interfaces (count them) and then judge whether or not the PD is "large enough". Someone could even reserve something from the pd for the loop, adding an extra prefix, should this one be counted too in this case ? What with configuration changes ? What if the customer expects to have multiple prefixes on each or some LAN intfs, should the CPE have some multiplier function to calculate ? Moreover, it must also check the pd-exclude, if present. Isn't this all going a bit too far ? What about the result when it is too small ? You hand out what you have ? or you don't hand out anything, so just logging ? but the logging is no MUST, hence no-one might notice, apart from the end-user who can or cannot browse the web ? =20 Regs Carl ------_=_NextPart_001_01CD029F.E6BDC758 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

/64 is too small because the SLAAC addressing = can’t be supported on the CE router LAN.   Thereafter, =  with hierarchical sub-delegation, the CE router splits the PD = based on the number of LAN subnets  rounded up to the nearest power = of two.   Further, the specification does not bother with LAN = physical ports or virtual network interfaces such as a loopback.  = The specification uses the term of “interface”  that is = assigned a subnet.  It is ridiculously simple math.  For = example,  if an SP gave the CE a /63 and if the CE needs two = subnets, the PD is too small for hierarchical = sub-delegation.

 

The MUST on the system = management error looks ok to me.  If the CE can’t = sub-delegate the PD in the LAN, the CE is a brick for IPv6 services.. =

 

Hemant

 

From:= = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = Wuyts Carl
Sent: Thursday, March 15, 2012 6:31 = AM
To: v6ops@ietf.org
Subject: [v6ops] = RFC6204bis-07

 

All,

 

One which = sort of slipped through my review is the following (although I might = have commented on this one before):

“”

WPD-3:  The = IPv6 CE router MUST be prepared to accept a = delegated

           = prefix size different from what is given in the hint.  If = the

           = delegated prefix is too small to address all of = its

           = interfaces, the IPv6 CE router SHOULD log a system = management

           = error.

 

“”

The = issue I can see is with “… if the delegated prefix is too = small to address all of its interfaces …”.  Too small, = what is that exactly ?  I don’t think the CPE should first = inspect all of its LAN interfaces (count them) and then judge whether or = not the PD is “large enough”.  Someone could even = reserve something from the pd for the loop, adding an extra prefix, = should this one be counted too in this case ?  What with = configuration changes ?  What if the customer expects to have = multiple prefixes on each or some LAN intfs, should the CPE have some = multiplier function to calculate ?  Moreover, it must also check = the pd-exclude, if present.

Isn’t this all going a bit too far = ?

What about the result when it is = too small ?  You hand out what you have ? or you don’t hand = out anything, so just logging ?  but the logging is no MUST, hence = no-one might notice, apart from the end-user who can or cannot browse = the web ?

 

Regs

Carl

------_=_NextPart_001_01CD029F.E6BDC758-- From gert@space.net Thu Mar 15 04:38:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56F621F8650 for ; Thu, 15 Mar 2012 04:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 A5hWQx5Qf2d3 for ; Thu, 15 Mar 2012 04:38:27 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1E38721F85F2 for ; Thu, 15 Mar 2012 04:38:27 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id DF69DF8A41 for ; Thu, 15 Mar 2012 12:38:25 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id CCFE2F8A29 for ; Thu, 15 Mar 2012 12:38:25 +0100 (CET) Received: (qmail 55741 invoked by uid 1007); 15 Mar 2012 12:38:25 +0100 Date: Thu, 15 Mar 2012 12:38:25 +0100 From: Gert Doering To: Wojciech Dec Message-ID: <20120315113825.GA84425@Space.Net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org Subject: Re: [v6ops] Nomative language in draft-ietf-v6ops-464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 11:38:27 -0000 Hi, On Thu, Mar 15, 2012 at 10:03:00AM +0100, Wojciech Dec wrote: > You haven't answered a major question; what is the purpose/goal of the > document? To tell people about a specific solution that solves a specific problem. I, for one, appreciate that. I'm an operator, and I like it if I can look at recipes for "if you have a problem similar to *this*, here's one possible solution that could work for you as well" - and the IETF benefits from producing documents that operators find useful. Now, what is the goal of *your* actions? I find this somewhat confusing, you spend quite some effort in telling Cameron that he's getting it all wrong - so what is your agenda? Gert Doering -- Operator -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From Carl.Wuyts@technicolor.com Thu Mar 15 04:52:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2194821F865A for ; Thu, 15 Mar 2012 04:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[AWL=-1.713, 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 d5tLy4nZX3O0 for ; Thu, 15 Mar 2012 04:52:12 -0700 (PDT) Received: from psmtp.com (na3sys009aog127.obsmtp.com [74.125.149.107]) by ietfa.amsl.com (Postfix) with ESMTP id 00B8A21F8573 for ; Thu, 15 Mar 2012 04:52:09 -0700 (PDT) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob127.postini.com ([74.125.148.12]) with SMTP ID DSNKT2HX6bv3JxeEXKinc/FutS60l1nRcFEj@postini.com; Thu, 15 Mar 2012 04:52:10 PDT Received: from MOPESMAILHC03.eu.thmulti.com (141.11.100.132) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.192.1; Thu, 15 Mar 2012 12:50:16 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.201]) by MOPESMAILHC03.eu.thmulti.com ([141.11.100.132]) with mapi; Thu, 15 Mar 2012 12:50:23 +0100 From: Wuyts Carl To: "Hemant Singh (shemant)" , "v6ops@ietf.org" Date: Thu, 15 Mar 2012 12:50:20 +0100 Thread-Topic: [v6ops] RFC6204bis-07 Thread-Index: Ac0ClqZ1Ha71E+m/RA+Ss20G/TTopwABrJ9QAACvKEA= Message-ID: <867F4B6A1672E541A94676D556793ACD0EB99504C1@MOPESMBX01.eu.thmulti.com> References: <867F4B6A1672E541A94676D556793ACD0EB995043C@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3042FEBDB@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3042FEBDB@XMB-RCD-109.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_867F4B6A1672E541A94676D556793ACD0EB99504C1MOPESMBX01eut_" MIME-Version: 1.0 Subject: Re: [v6ops] RFC6204bis-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 11:52:15 -0000 --_000_867F4B6A1672E541A94676D556793ACD0EB99504C1MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As often, I do not agree, sorry. I agree something better than /64 should be assigned (no doubt about that o= ne), and I also always recommend this to our customers. But... /64 is enou= gh to serve a basic residential scenario, where the end-user just had 1 sub= net in the home, in fact, we have some of our customers deploying it like t= his, so I can confirm: it works. We can cope with any value, so /64, /63, /62, /56, /48 or whatever but we = do not count first how many interfaces must be served. You say "the CE nee= ds 2 subnets". But how does the CPE knows (What part do you inform on this = ? some parameter in the Router Adv daemon ? The DHCPv6 implementation or = ... ? Maybe the end-user (IF he is allowed to configure anything, which is= very often not the case) would like 16 subnets, but only gets an /63, then= what ?? What if a user adds another LAN interface/subnet afterwards (all = of a sudden the pd becomes too "small")? I think (again) the small residential CPE is not considered in this. And a= gain, some binding between things is being done (# of LANs to be counted vs= received pd). FYI, we're selling managed CPEs, so the issue itself will m= ost likely not show up, unless maybe during some lab-testing. Maybe I'm ov= erlooking something, but personally I believe that reqs like this don't ser= ve any real purpose, they don't bring real added value, just increase CPE c= omplexity. So the WPD-3 is ok wrt hinting something and getting something different ba= ck, but the "too small + logging" stuff should be left out or potentially "= degraded" to a MAY. Regs Carl From: Hemant Singh (shemant) [mailto:shemant@cisco.com] Sent: donderdag 15 maart 2012 12:37 To: Wuyts Carl; v6ops@ietf.org Subject: RE: [v6ops] RFC6204bis-07 /64 is too small because the SLAAC addressing can't be supported on the CE = router LAN. Thereafter, with hierarchical sub-delegation, the CE router = splits the PD based on the number of LAN subnets rounded up to the nearest= power of two. Further, the specification does not bother with LAN physic= al ports or virtual network interfaces such as a loopback. The specificati= on uses the term of "interface" that is assigned a subnet. It is ridiculo= usly simple math. For example, if an SP gave the CE a /63 and if the CE n= eeds two subnets, the PD is too small for hierarchical sub-delegation. The MUST on the system management error looks ok to me. If the CE can't su= b-delegate the PD in the LAN, the CE is a brick for IPv6 services.. Hemant From: v6ops-bounces@ietf.org [mailto:v6ops-b= ounces@ietf.org] On Behalf Of Wuyts Carl Sent: Thursday, March 15, 2012 6:31 AM To: v6ops@ietf.org Subject: [v6ops] RFC6204bis-07 All, One which sort of slipped through my review is the following (although I mi= ght have commented on this one before): "" WPD-3: The IPv6 CE router MUST be prepared to accept a delegated prefix size different from what is given in the hint. If the delegated prefix is too small to address all of its interfaces, the IPv6 CE router SHOULD log a system management error. "" The issue I can see is with "... if the delegated prefix is too small to ad= dress all of its interfaces ...". Too small, what is that exactly ? I don= 't think the CPE should first inspect all of its LAN interfaces (count them= ) and then judge whether or not the PD is "large enough". Someone could ev= en reserve something from the pd for the loop, adding an extra prefix, shou= ld this one be counted too in this case ? What with configuration changes = ? What if the customer expects to have multiple prefixes on each or some L= AN intfs, should the CPE have some multiplier function to calculate ? More= over, it must also check the pd-exclude, if present. Isn't this all going a bit too far ? What about the result when it is too small ? You hand out what you have ? = or you don't hand out anything, so just logging ? but the logging is no MU= ST, hence no-one might notice, apart from the end-user who can or cannot br= owse the web ? Regs Carl --_000_867F4B6A1672E541A94676D556793ACD0EB99504C1MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As often, I do not agree, sorry.

 

I agree something better th= an /64 should be assigned (no doubt about that one), and I also always reco= mmend this to our customers.  But… /64 is enough to serve a basi= c residential scenario, where the end-user just had 1 subnet in the home, i= n fact, we have some of our customers deploying it like this, so I can conf= irm: it works.

We can cope with any value, so /64, /63, /62, /56,  /48 or= whatever but we do not count first how many interfaces must be served.&nbs= p; You say “the CE needs 2 subnets”. But how does the CPE knows= (What part do you inform on this ?  some parameter in the Router Adv = daemon ?  The DHCPv6 implementation or … ?  Maybe the end-u= ser (IF he is allowed to configure anything, which is very often not the ca= se) would like 16 subnets, but only gets an /63, then what ??  What if= a user adds another LAN interface/subnet afterwards (all of a sudden the p= d becomes too “small”)?

 

I think (again) the small residential = CPE is not considered in this.  And again, some binding between things= is being done (# of LANs to be counted vs received pd).  FYI, we̵= 7;re selling managed CPEs, so the issue itself will most likely not show up= , unless maybe during some lab-testing.  Maybe I’m overlooking s= omething, but personally I believe that reqs like this don’t serve an= y real purpose, they don’t bring real added value, just increase CPE = complexity.

 

So the WPD-3 is ok wrt hinting something and getting something= different back, but the “too small + logging” stuff should be = left out or potentially “degraded” to a MAY.<= /p>

 

Regs

Carl

 

 

From: Hemant Singh (shemant) [mailto:shemant@= cisco.com]
Sent: donderdag 15 maart 2012 12:37
To: Wuy= ts Carl; v6ops@ietf.org
Subject: RE: [v6ops] RFC6204bis-07

 

/64 is too small because the S= LAAC addressing can’t be supported on the CE router LAN.   = Thereafter,  with hierarchical sub-delegation, the CE router splits th= e PD based on the number of LAN subnets  rounded up to the nearest pow= er of two.   Further, the specification does not bother with LAN = physical ports or virtual network interfaces such as a loopback.  The = specification uses the term of “interface”  that is assign= ed a subnet.  It is ridiculously simple math.  For example,  = ;if an SP gave the CE a /63 and if the CE needs two subnets, the PD is too = small for hierarchical sub-delegation.

 

The MUST on the system management e= rror looks ok to me.  If the CE can’t sub-delegate the PD in the= LAN, the CE is a brick for IPv6 services..

 

Hemant

=

 =

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Wuyts Carl
<= b>Sent: Thursday, March 15, 2012 6:31 AM
To: v6ops@ietf.org
Subject: [v6ops] RFC6204bis-= 07

 <= /p>

All,

 =

One which sort of slipped through my review = is the following (although I might have commented on this one before):=

“”

WPD-3:  The IPv6 CE router MUST be prepared to acce= pt a delegated

 = ;          prefix size differe= nt from what is given in the hint.  If the

        = ;   delegated prefix is too small to address all of its

    &nb= sp;      interfaces, the IPv6 CE router SHOULD log= a system management

           error.

 

“”

Th= e issue I can see is with “… if the delegated prefix is too sma= ll to address all of its interfaces …”.  Too small, what i= s that exactly ?  I don’t think the CPE should first inspect all= of its LAN interfaces (count them) and then judge whether or not the PD is= “large enough”.  Someone could even reserve something fro= m the pd for the loop, adding an extra prefix, should this one be counted t= oo in this case ?  What with configuration changes ?  What if the= customer expects to have multiple prefixes on each or some LAN intfs, shou= ld the CPE have some multiplier function to calculate ?  Moreover, it = must also check the pd-exclude, if present.

Isn’t this all going a bit too far ?

What about the result when it is too small ?  You hand out what= you have ? or you don’t hand out anything, so just logging ?  b= ut the logging is no MUST, hence no-one might notice, apart from the end-us= er who can or cannot browse the web ?

 

Regs

Carl

= --_000_867F4B6A1672E541A94676D556793ACD0EB99504C1MOPESMBX01eut_-- From v6ops@globis.net Thu Mar 15 05:49:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69CF721F849D for ; Thu, 15 Mar 2012 05:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.037, 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 MxguNIj+TqzD for ; Thu, 15 Mar 2012 05:49:08 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id DCAF721F8495 for ; Thu, 15 Mar 2012 05:49:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id E856B8700E6; Thu, 15 Mar 2012 13:49:06 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9FnImuWJwIk0; Thu, 15 Mar 2012 13:49:01 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id ACB4A8700CD; Thu, 15 Mar 2012 13:49:01 +0100 (CET) Message-ID: <4F61E53D.4050904@globis.net> Date: Thu, 15 Mar 2012 13:49:01 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: "Hemant Singh (shemant)" References: <867F4B6A1672E541A94676D556793ACD0EB995043C@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3042FEBDB@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3042FEBDB@XMB-RCD-109.cisco.com> Content-Type: multipart/alternative; boundary="------------090001030709090301070402" Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 12:49:10 -0000 This is a multi-part message in MIME format. --------------090001030709090301070402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hermant, IMHO the root cause of the prefix size "too small" problem is that the operator of the DHCPv6 PD delegating router has not adhered to BCP RFC6177 Section 5 Summary. WPD-3 of RFC6204bis suggests logging a system management error, but I don't see anything in RFC6204bis or RFC3633 or RFC3315 that would allow a CE manufacturer/end user who is operating the requesting router to be able to signal back to the delegating router (where the root cause of the problem lies) that the prefix was too small (either via a DHCPv6 PD status code such as "PREFIX_TOO_SMALL", or any other standard logging mechanism). Local system management logging would not seem to address the root cause, and would seem to potentially leave the end user/ CE manufacturer in no man's land. To address the root cause, I'd like to propose RFC6024bis refer to RFC6177 as a normative reference. Firstly, to attempt to lower the likelihood of this problem ever occurring in production, and secondly if it does occur, to provide a good indication of how to solve it. regards. RayH Hemant Singh (shemant) wrote: > > /64 is too small because the SLAAC addressing can't be supported on > the CE router LAN. Thereafter, with hierarchical sub-delegation, > the CE router splits the PD based on the number of LAN subnets > rounded up to the nearest power of two. Further, the specification > does not bother with LAN physical ports or virtual network interfaces > such as a loopback. The specification uses the term of "interface" > that is assigned a subnet. It is ridiculously simple math. For > example, if an SP gave the CE a /63 and if the CE needs two subnets, > the PD is too small for hierarchical sub-delegation. > > The MUST on the system management error looks ok to me. If the CE > can't sub-delegate the PD in the LAN, the CE is a brick for IPv6 > services.. > > Hemant > > *From:* v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] *On > Behalf Of *Wuyts Carl > *Sent:* Thursday, March 15, 2012 6:31 AM > *To:* v6ops@ietf.org > *Subject:* [v6ops] RFC6204bis-07 > > All, > > One which sort of slipped through my review is the following (although > I might have commented on this one before): > > "" > > WPD-3: The IPv6 CE router MUST be prepared to accept a delegated > > prefix size different from what is given in the hint. If the > > delegated prefix is too small to address all of its > > interfaces, the IPv6 CE router SHOULD log a system management > > error. > > "" > > The issue I can see is with "... if the delegated prefix is too small > to address all of its interfaces ...". Too small, what is that > exactly ? I don't think the CPE should first inspect all of its LAN > interfaces (count them) and then judge whether or not the PD is "large > enough". Someone could even reserve something from the pd for the > loop, adding an extra prefix, should this one be counted too in this > case ? What with configuration changes ? What if the customer > expects to have multiple prefixes on each or some LAN intfs, should > the CPE have some multiplier function to calculate ? Moreover, it > must also check the pd-exclude, if present. > > Isn't this all going a bit too far ? > > What about the result when it is too small ? You hand out what you > have ? or you don't hand out anything, so just logging ? but the > logging is no MUST, hence no-one might notice, apart from the end-user > who can or cannot browse the web ? > > Regs > > Carl > --------------090001030709090301070402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hermant, IMHO the root cause of the prefix size "too small" problem is that the operator of the DHCPv6 PD delegating router has not adhered to BCP RFC6177 Section 5 Summary.

WPD-3 of RFC6204bis suggests logging a system management error, but I don't see anything in RFC6204bis or RFC3633 or RFC3315 that would allow a CE manufacturer/end user who is operating the requesting router to be able to signal back to the delegating router (where the root cause of the problem lies) that the prefix was too small (either via a DHCPv6 PD status code such as "PREFIX_TOO_SMALL", or any other standard logging mechanism).

Local system management logging would not seem to address the root cause, and would seem to potentially leave the end user/ CE manufacturer in no man's land.

To address the root cause, I'd like to propose RFC6024bis refer to RFC6177 as a normative reference.

Firstly, to attempt to lower the likelihood of this problem ever occurring in production, and secondly if it does occur, to provide a good indication of how to solve it.

regards.
RayH

Hemant Singh (shemant) wrote:

/64 is too small because the SLAAC addressing can’t be supported on the CE router LAN.   Thereafter,  with hierarchical sub-delegation, the CE router splits the PD based on the number of LAN subnets  rounded up to the nearest power of two.   Further, the specification does not bother with LAN physical ports or virtual network interfaces such as a loopback.  The specification uses the term of “interface”  that is assigned a subnet.  It is ridiculously simple math.  For example,  if an SP gave the CE a /63 and if the CE needs two subnets, the PD is too small for hierarchical sub-delegation.

 

The MUST on the system management error looks ok to me.  If the CE can’t sub-delegate the PD in the LAN, the CE is a brick for IPv6 services..

 

Hemant

 

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Wuyts Carl
Sent: Thursday, March 15, 2012 6:31 AM
To: v6ops@ietf.org
Subject: [v6ops] RFC6204bis-07

 

All,

 

One which sort of slipped through my review is the following (although I might have commented on this one before):

“”

WPD-3:  The IPv6 CE router MUST be prepared to accept a delegated

           prefix size different from what is given in the hint.  If the

           delegated prefix is too small to address all of its

           interfaces, the IPv6 CE router SHOULD log a system management

           error.

 

“”

The issue I can see is with “… if the delegated prefix is too small to address all of its interfaces …”.  Too small, what is that exactly ?  I don’t think the CPE should first inspect all of its LAN interfaces (count them) and then judge whether or not the PD is “large enough”.  Someone could even reserve something from the pd for the loop, adding an extra prefix, should this one be counted too in this case ?  What with configuration changes ?  What if the customer expects to have multiple prefixes on each or some LAN intfs, should the CPE have some multiplier function to calculate ?  Moreover, it must also check the pd-exclude, if present.

Isn’t this all going a bit too far ?

What about the result when it is too small ?  You hand out what you have ? or you don’t hand out anything, so just logging ?  but the logging is no MUST, hence no-one might notice, apart from the end-user who can or cannot browse the web ?

 

Regs

Carl

--------------090001030709090301070402-- From wdec.ietf@gmail.com Thu Mar 15 06:25:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5452021F864F for ; Thu, 15 Mar 2012 06:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=0.333, 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 HjMFZjRYDjUb for ; Thu, 15 Mar 2012 06:25:54 -0700 (PDT) Received: from mail-fa0-f44.google.com (mail-fa0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3AA21F864B for ; Thu, 15 Mar 2012 06:25:53 -0700 (PDT) Received: by faaa25 with SMTP id a25so551627faa.31 for ; Thu, 15 Mar 2012 06:25:53 -0700 (PDT) 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=hgslVcxBE2sbd+d0vRWtDWlXYhcN1c8gTIZW9l+LVRU=; b=ZmGwE7li2UJHRqNegmWtbXcR/AfcczV2ro3hXBy+vvaIVAu7xe8A1Nxdbdh0/gEKSR hcGs1WPUlTZeJycJQ2fAF7oPoiIE13RPpkOCIJQ+DO7ioVBMXuC07RfX3B2JZsnh0QMi ZtVnbYoz8h0X2afas1Vm3ftXn5V8HMNMUfA8/cw9OsfBaK189xx8B92HNhqsBZNUY3Oz dlxOt7yjsK12YoCavZ3kKtDIPnct8unCxlm/fQvSsiA2VbxkCm3Y5d8GsfjzCc9OPmTg 5sOlM4i3n8O5afHPf148Z8jQr9m10DgKpSrr57VOLOZugFH9Y26jmgCL3R7al0A632DS iXCQ== MIME-Version: 1.0 Received: by 10.224.197.198 with SMTP id el6mr7796314qab.7.1331817952844; Thu, 15 Mar 2012 06:25:52 -0700 (PDT) Received: by 10.229.218.4 with HTTP; Thu, 15 Mar 2012 06:25:52 -0700 (PDT) In-Reply-To: <20120315113825.GA84425@Space.Net> References: <20120315113825.GA84425@Space.Net> Date: Thu, 15 Mar 2012 14:25:52 +0100 Message-ID: From: Wojciech Dec To: Gert Doering Content-Type: multipart/alternative; boundary=20cf300fb153fc1d3404bb48079d Cc: v6ops@ietf.org Subject: Re: [v6ops] Nomative language in draft-ietf-v6ops-464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 13:25:56 -0000 --20cf300fb153fc1d3404bb48079d Content-Type: text/plain; charset=ISO-8859-1 On 15 March 2012 12:38, Gert Doering wrote: > Hi, > > On Thu, Mar 15, 2012 at 10:03:00AM +0100, Wojciech Dec wrote: > > You haven't answered a major question; what is the purpose/goal of the > > document? > > To tell people about a specific solution that solves a specific problem. > > I, for one, appreciate that. I'm an operator, and I like it if I can > look at recipes for "if you have a problem similar to *this*, here's one > possible solution that could work for you as well" - and the IETF benefits > from producing documents that operators find useful. > Cool, no problem with that, but in doing so would you agree if the solution did not attempt to be a spec for implementers of a "sub-class" NAT64 - which it appears intended on being. I proposed formulating some text that would remove this concern. > > > Now, what is the goal of *your* actions? I find this somewhat confusing, > you spend quite some effort in telling Cameron that he's getting it all > wrong - so what is your agenda? > Perhaps you didn't quite read the thread where I wrote "I think that this work is very useful and am supporting...". In terms of the issue; consider some of the use-cases that this solution apparently does not support, but which a standard NAT64 based solution has no problem with, eg use on non 3G networks, or even on 3G networks where operators have some different ideas on IP subnet design or routing or services. Given that this solution claims to be using regular NAT64, but doesn't support such use-cases, there is something amiss. Seeking clarity on that, the underlying assumptions, is a good thing to have for a document seeking WG acceptance. Furthermore, the core problem that this draft addresses fundamentally (IPv4 over and acrss IPv6) is the subject of various other drafts - knowing how these compare should be understood, unless you're saying that you're happy with potentially operating N different solutions for this core problem due to specific issues with each, that you'll only find out about when specific & not compatible devices are shipping for each? Woj - Individual > > Gert Doering > -- Operator > -- > have you enabled IPv6 on something today...? > > SpaceNet AG Vorstand: Sebastian v. Bomhard > Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann > D-80807 Muenchen HRB: 136055 (AG Muenchen) > Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > --20cf300fb153fc1d3404bb48079d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 15 March 2012 12:38, Gert Doering <gert@space.net>= wrote:
Hi,

On Thu, Mar 15, 2012 at 10:03:00AM +0100, Wojciech Dec wrote:
> You haven't answered a major question; what is the purpose/goal of= the
> document?

To tell people about a specific solution that solves a specific probl= em.

I, for one, appreciate that. =A0I'm an operator, and I like it if I can=
look at recipes for "if you have a problem similar to *this*, here'= ;s one
possible solution that could work for you as well" - and the IETF bene= fits
from producing documents that operators find useful.
<= br>Cool, no problem with that, but in doing so would you agree if the solut= ion did not attempt to be a spec for implementers of a "sub-class"= ; NAT64 - which it appears intended on being. I proposed formulating some t= ext that would remove this concern.
=A0


Now, what is the goal of *your* actions? =A0I find this somewhat confusing,=
you spend quite some effort in telling Cameron that he's getting it all=
wrong - so what is your agenda?

Perhaps you didn&#= 39;t quite read the thread where I wrote "I think that this work is ve= ry useful and am supporting...".
In terms of the issue; consider s= ome of the use-cases that this solution apparently does not support, but wh= ich a standard NAT64 based solution has no problem with, eg use on non 3G n= etworks, or even on 3G networks where operators have some different ideas o= n IP subnet design or routing or services. Given that this solution claims = to be using regular NAT64, but doesn't support such use-cases, there is= something amiss.
Seeking clarity on that, the underlying assumptions, is a good thing to hav= e for a document seeking WG acceptance. Furthermore, the core problem that = this draft addresses fundamentally (IPv4 over and acrss IPv6) is the subjec= t of various other drafts - knowing how these compare should be understood,= unless you're saying that you're happy with potentially operating = N different solutions for this core problem due to specific issues with eac= h, that you'll only find out about when specific & not compatible d= evices are shipping for each?

Woj
- Individual

Gert Doering
=A0 =A0 =A0 =A0-- Operator
--
have you enabled IPv6 on something today...?

SpaceNet AG =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Vorstand: Sebast= ian v. Bomhard
Joseph-Dollinger-Bogen 14 =A0 =A0 =A0 =A0 =A0Aufsichtsratsvors.: A. Grundne= r-Culemann
D-80807 Muenchen =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 HRB: 136055 (AG Muench= en)
Tel: += 49 (89) 32356-444 =A0 =A0 =A0 =A0 =A0 =A0USt-IdNr.: DE813185279

--20cf300fb153fc1d3404bb48079d-- From shemant@cisco.com Thu Mar 15 06:44:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9310A21F8658 for ; Thu, 15 Mar 2012 06:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.915 X-Spam-Level: X-Spam-Status: No, score=-9.915 tagged_above=-999 required=5 tests=[AWL=0.683, 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 EpveHIylPYhu for ; Thu, 15 Mar 2012 06:44:21 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFE821F864E for ; Thu, 15 Mar 2012 06:44:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=10612; q=dns/txt; s=iport; t=1331819061; x=1333028661; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=9P5Okrhp81RJWnRgpXttAYEDTtgMHoDv9VPtjRWCMw4=; b=bP3lyFdyeCvBGE4w2b969wykVXQHgPiDvI3AP02d5lqGTMtp6mjvywHz fS4lR3V4ntn/njkZxrNqbIuPyRKHNQeDtPZ/1cPx1WGnmmpGTnPyUvLcN e+NjIlfOMCr33rSzWftU7ROeB+B4m8ryyBOE9ycgf+wfCIMFJWUUQV1MF 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAIbxYU+tJXHB/2dsb2JhbABDgk6zYIEHggkBAQEEEgEJEQNZAgEIEQQBAQsGFwEGAUUJCAEBBAESCBcDh2idJZdAkCRjBIhXm0mBaIME X-IronPort-AV: E=Sophos;i="4.73,591,1325462400"; d="scan'208,217";a="66723881" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 15 Mar 2012 13:44:20 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q2FDiKSd022620; Thu, 15 Mar 2012 13:44:20 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Mar 2012 08:44:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD02B1.B94C5518" Date: Thu, 15 Mar 2012 08:44:18 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3042FEC3D@XMB-RCD-109.cisco.com> In-Reply-To: <867F4B6A1672E541A94676D556793ACD0EB99504C1@MOPESMBX01.eu.thmulti.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] RFC6204bis-07 Thread-Index: Ac0ClqZ1Ha71E+m/RA+Ss20G/TTopwABrJ9QAACvKEAABB4dQA== References: <867F4B6A1672E541A94676D556793ACD0EB995043C@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3042FEBDB@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0EB99504C1@MOPESMBX01.eu.thmulti.com> From: "Hemant Singh (shemant)" To: "Wuyts Carl" , X-OriginalArrivalTime: 15 Mar 2012 13:44:20.0751 (UTC) FILETIME=[B974A9F0:01CD02B1] Subject: Re: [v6ops] RFC6204bis-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 13:44:23 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD02B1.B94C5518 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Carl, =20 It's up to the CE router software design to do what regarding the error message. You decided to count the physical ports on the CE router LAN but that approach is not very sound because the LAN ports could be routed, switched, or bridged ports. I am working at the subnet configuration of a network interface. Whenever the CE router (automatically or manual configuration) is configured with a subnet for the LAN interface, if the WAN- acquired PD does not allow the LAN subnet to be configured, flag an error on the CE router. For your /64 PD acquired by the WAN to use on one LAN port, your CE router won't raise an error if the WAN is unnumbered. WPD-3 is fine as a requirement because the rfc6204bis is a requirements document, because again, we did not want the CE to be a brick silently.=20 =20 Regards, =20 Hemant =20 From: Wuyts Carl [mailto:Carl.Wuyts@technicolor.com]=20 Sent: Thursday, March 15, 2012 7:50 AM To: Hemant Singh (shemant); v6ops@ietf.org Subject: RE: [v6ops] RFC6204bis-07 =20 As often, I do not agree, sorry. =20 I agree something better than /64 should be assigned (no doubt about that one), and I also always recommend this to our customers. But... /64 is enough to serve a basic residential scenario, where the end-user just had 1 subnet in the home, in fact, we have some of our customers deploying it like this, so I can confirm: it works. We can cope with any value, so /64, /63, /62, /56, /48 or whatever but we do not count first how many interfaces must be served. You say "the CE needs 2 subnets". But how does the CPE knows (What part do you inform on this ? some parameter in the Router Adv daemon ? The DHCPv6 implementation or ... ? Maybe the end-user (IF he is allowed to configure anything, which is very often not the case) would like 16 subnets, but only gets an /63, then what ?? What if a user adds another LAN interface/subnet afterwards (all of a sudden the pd becomes too "small")? =20 I think (again) the small residential CPE is not considered in this. And again, some binding between things is being done (# of LANs to be counted vs received pd). FYI, we're selling managed CPEs, so the issue itself will most likely not show up, unless maybe during some lab-testing. Maybe I'm overlooking something, but personally I believe that reqs like this don't serve any real purpose, they don't bring real added value, just increase CPE complexity. =20 So the WPD-3 is ok wrt hinting something and getting something different back, but the "too small + logging" stuff should be left out or potentially "degraded" to a MAY. =20 Regs Carl =20 ------_=_NextPart_001_01CD02B1.B94C5518 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Carl,

 

It’s up to the CE = router software design to do what regarding the error = message.   You decided to count the physical ports on the CE = router LAN but that approach is not very sound because the LAN ports = could be routed, switched, or bridged ports.    I am = working at the subnet configuration of a network interface. =   Whenever the CE router (automatically or manual = configuration) is configured with a subnet for the LAN interface, if the = WAN- acquired PD does not allow the LAN subnet to be configured, flag an = error on the CE router.   For your /64 PD acquired by the WAN = to use on one LAN port, your CE router won’t raise an error if the = WAN is unnumbered.    WPD-3 is fine as a requirement = because the rfc6204bis is a requirements document, because again, we did = not want the CE to be a brick silently.

 

Regards,

 

Hemant

 

From:= = Wuyts Carl [mailto:Carl.Wuyts@technicolor.com]
Sent: = Thursday, March 15, 2012 7:50 AM
To: Hemant Singh (shemant); = v6ops@ietf.org
Subject: RE: [v6ops] = RFC6204bis-07

 

As often, I do not agree, = sorry.

 

I agree something better = than /64 should be assigned (no doubt about that one), and I also always = recommend this to our customers.  But… /64 is enough to serve = a basic residential scenario, where the end-user just had 1 subnet in = the home, in fact, we have some of our customers deploying it like this, = so I can confirm: it works.

We can cope with any = value, so /64, /63, /62, /56,  /48 or whatever but we do not count = first how many interfaces must be served.  You say “the CE = needs 2 subnets”. But how does the CPE knows (What part do you = inform on this ?  some parameter in the Router Adv daemon ?  = The DHCPv6 implementation or … ?  Maybe the end-user (IF he = is allowed to configure anything, which is very often not the case) = would like 16 subnets, but only gets an /63, then what ??  What if = a user adds another LAN interface/subnet afterwards (all of a sudden the = pd becomes too “small”)?

 

I think (again) the = small residential CPE is not considered in this.  And again, some = binding between things is being done (# of LANs to be counted vs = received pd).  FYI, we’re selling managed CPEs, so the issue = itself will most likely not show up, unless maybe during some = lab-testing.  Maybe I’m overlooking something, but personally = I believe that reqs like this don’t serve any real purpose, they = don’t bring real added value, just increase CPE = complexity.

 

So the WPD-3 is ok wrt = hinting something and getting something different back, but the = “too small + logging” stuff should be left out or = potentially “degraded” to a = MAY.

 

Regs

Carl

 

------_=_NextPart_001_01CD02B1.B94C5518-- From Carl.Wuyts@technicolor.com Thu Mar 15 07:31:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A775F21F8627 for ; Thu, 15 Mar 2012 07:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.242 X-Spam-Level: X-Spam-Status: No, score=-6.242 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 97hZMd2L4+ZM for ; Thu, 15 Mar 2012 07:31:39 -0700 (PDT) Received: from na3sys009aog126.obsmtp.com (na3sys009aog126.obsmtp.com [74.125.149.155]) by ietfa.amsl.com (Postfix) with ESMTP id 0789621F8600 for ; Thu, 15 Mar 2012 07:31:37 -0700 (PDT) Received: from mopesedge02.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob126.postini.com ([74.125.148.12]) with SMTP ID DSNKT2H9SIc/LjFuU5MRtC06f1xcUw7z8hGv@postini.com; Thu, 15 Mar 2012 07:31:38 PDT Received: from MOPESMAILHC02.eu.thmulti.com (141.11.100.29) by mopesedge02.eu.thmulti.com (141.11.253.23) with Microsoft SMTP Server (TLS) id 8.3.192.1; Thu, 15 Mar 2012 15:29:52 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Thu, 15 Mar 2012 15:30:08 +0100 From: Wuyts Carl To: "Hemant Singh (shemant)" , "v6ops@ietf.org" Date: Thu, 15 Mar 2012 15:30:08 +0100 Thread-Topic: [v6ops] RFC6204bis-07 Thread-Index: Ac0ClqZ1Ha71E+m/RA+Ss20G/TTopwABrJ9QAACvKEAABB4dQAABzW4A Message-ID: <867F4B6A1672E541A94676D556793ACD0EB99505CE@MOPESMBX01.eu.thmulti.com> References: <867F4B6A1672E541A94676D556793ACD0EB995043C@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3042FEBDB@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0EB99504C1@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3042FEC3D@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3042FEC3D@XMB-RCD-109.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_867F4B6A1672E541A94676D556793ACD0EB99505CEMOPESMBX01eut_" MIME-Version: 1.0 Subject: Re: [v6ops] RFC6204bis-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 14:31:41 -0000 --_000_867F4B6A1672E541A94676D556793ACD0EB99505CEMOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well, I was not really counting physical ports, but more IP LAN intf, i.e. = subnets, on the LAN. Anyway, I don't think we will hit this one anyway, as we allow flexible con= figuration of /64 sub-netting anyway. The "too small" would only be hit in= case you would start from the first available /64, but this is not mandato= ry, so probably kind of different on our CPEs. Thx for the updates Regs Carl From: Hemant Singh (shemant) [mailto:shemant@cisco.com] Sent: donderdag 15 maart 2012 14:44 To: Wuyts Carl; v6ops@ietf.org Subject: RE: [v6ops] RFC6204bis-07 Carl, It's up to the CE router software design to do what regarding the error mes= sage. You decided to count the physical ports on the CE router LAN but th= at approach is not very sound because the LAN ports could be routed, switch= ed, or bridged ports. I am working at the subnet configuration of a netw= ork interface. Whenever the CE router (automatically or manual configurat= ion) is configured with a subnet for the LAN interface, if the WAN- acquire= d PD does not allow the LAN subnet to be configured, flag an error on the C= E router. For your /64 PD acquired by the WAN to use on one LAN port, you= r CE router won't raise an error if the WAN is unnumbered. WPD-3 is fine= as a requirement because the rfc6204bis is a requirements document, becaus= e again, we did not want the CE to be a brick silently. Regards, Hemant From: Wuyts Carl [mailto:Carl.Wuyts@technicolor.com] Sent: Thursday, March 15, 2012 7:50 AM To: Hemant Singh (shemant); v6ops@ietf.org Subject: RE: [v6ops] RFC6204bis-07 As often, I do not agree, sorry. I agree something better than /64 should be assigned (no doubt about that o= ne), and I also always recommend this to our customers. But... /64 is enou= gh to serve a basic residential scenario, where the end-user just had 1 sub= net in the home, in fact, we have some of our customers deploying it like t= his, so I can confirm: it works. We can cope with any value, so /64, /63, /62, /56, /48 or whatever but we = do not count first how many interfaces must be served. You say "the CE nee= ds 2 subnets". But how does the CPE knows (What part do you inform on this = ? some parameter in the Router Adv daemon ? The DHCPv6 implementation or = ... ? Maybe the end-user (IF he is allowed to configure anything, which is= very often not the case) would like 16 subnets, but only gets an /63, then= what ?? What if a user adds another LAN interface/subnet afterwards (all = of a sudden the pd becomes too "small")? I think (again) the small residential CPE is not considered in this. And a= gain, some binding between things is being done (# of LANs to be counted vs= received pd). FYI, we're selling managed CPEs, so the issue itself will m= ost likely not show up, unless maybe during some lab-testing. Maybe I'm ov= erlooking something, but personally I believe that reqs like this don't ser= ve any real purpose, they don't bring real added value, just increase CPE c= omplexity. So the WPD-3 is ok wrt hinting something and getting something different ba= ck, but the "too small + logging" stuff should be left out or potentially "= degraded" to a MAY. Regs Carl --_000_867F4B6A1672E541A94676D556793ACD0EB99505CEMOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Well, I was not really counting physical ports, but more IP L= AN intf, i.e. subnets, on the LAN.

Anyway, I don’t think we will hit thi= s one anyway, as we allow flexible configuration of /64 sub-netting anyway.=   The “too small” would only be hit in case you would star= t from the first available /64, but this is not mandatory, so probably kind= of different on our CPEs.

Thx for the updates

 

Regs

Carl

=

 

From: Hemant Singh (shemant) [mailto:shemant@cisco.com]
Sent:<= /b> donderdag 15 maart 2012 14:44
To: Wuyts Carl; v6ops@ietf.org<= br>Subject: RE: [v6ops] RFC6204bis-07

 

Carl,

 

It’s up to the CE router software design = to do what regarding the error message.   You decided to count th= e physical ports on the CE router LAN but that approach is not very sound b= ecause the LAN ports could be routed, switched, or bridged ports. &nbs= p;  I am working at the subnet configuration of a network interface. &= nbsp; Whenever the CE router (automatically or manual configuration) i= s configured with a subnet for the LAN interface, if the WAN- acquired PD d= oes not allow the LAN subnet to be configured, flag an error on the CE rout= er.   For your /64 PD acquired by the WAN to use on one LAN port,= your CE router won’t raise an error if the WAN is unnumbered. &= nbsp;  WPD-3 is fine as a requirement because the rfc6204bis is a requ= irements document, because again, we did not want the CE to be a brick sile= ntly.

 

Regards,

 

Hemant

 

From: Wuyts Carl [= mailto:Carl.Wuyts@technicolor.com]
Sent: Thursday, March 15,= 2012 7:50 AM
To: Hemant Singh (shemant); v6ops@ietf.org
Subject: RE: [v6ops] RFC6204bis-07<= o:p>

 

=

As often, I do not agree= , sorry.

 

I agree something better than /64 should be assigned (no doubt ab= out that one), and I also always recommend this to our customers.  But= … /64 is enough to serve a basic residential scenario, where the end-= user just had 1 subnet in the home, in fact, we have some of our customers = deploying it like this, so I can confirm: it works.

We can cope with any value= , so /64, /63, /62, /56,  /48 or whatever but we do not count first ho= w many interfaces must be served.  You say “the CE needs 2 subne= ts”. But how does the CPE knows (What part do you inform on this ? &n= bsp;some parameter in the Router Adv daemon ?  The DHCPv6 implementati= on or … ?  Maybe the end-user (IF he is allowed to configure any= thing, which is very often not the case) would like 16 subnets, but only ge= ts an /63, then what ??  What if a user adds another LAN interface/sub= net afterwards (all of a sudden the pd becomes too “small”)?

=  

I= think (again) the small residential CPE is not considered in this.  A= nd again, some binding between things is being done (# of LANs to be counte= d vs received pd).  FYI, we’re selling managed CPEs, so the issu= e itself will most likely not show up, unless maybe during some lab-testing= .  Maybe I’m overlooking something, but personally I believe tha= t reqs like this don’t serve any real purpose, they don’t bring= real added value, just increase CPE complexity.

 

<= p class=3DMsoNormal>So the WPD-3 is ok wrt hi= nting something and getting something different back, but the “too sm= all + logging” stuff should be left out or potentially “degrade= d” to a MAY.

 

Regs

Carl

 

= --_000_867F4B6A1672E541A94676D556793ACD0EB99505CEMOPESMBX01eut_-- From shemant@cisco.com Thu Mar 15 07:34:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4060C21F8514 for ; Thu, 15 Mar 2012 07:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.96 X-Spam-Level: X-Spam-Status: No, score=-9.96 tagged_above=-999 required=5 tests=[AWL=0.638, 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 Cqb2AVxH043P for ; Thu, 15 Mar 2012 07:34:08 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 36E0121F850D for ; Thu, 15 Mar 2012 07:34:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=10389; q=dns/txt; s=iport; t=1331822048; x=1333031648; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=RyQj5Pohz9ftphfeJMUz6kTNf1/mGdr08sBs43c5eKE=; b=BSscOEBUMnZvYQoqdcqoN4LwBvO0IfTKQHg0MgeakHn8UHZocQxhuS9l X5DG39rx96wlf0HcYMHMYNanZStydenYjQkRFKYPd8hmCNwd+6fc9Dg2/ RXqMou+arQPcdNnBSFD48t79NF4TLgwLLkOorFanDbeasYPGGNQQsyAVY 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALn8YU+tJV2a/2dsb2JhbABDgk6zYYEHggkBAQEEEgEJEQNJEAIBCA4DBAEBCwYXAQYBRQkIAQEEEwgah2idMJc2kCRjBIhXm0mBaIME X-IronPort-AV: E=Sophos;i="4.73,591,1325462400"; d="scan'208,217";a="66739739" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 15 Mar 2012 14:34:07 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2FEY7rf006949; Thu, 15 Mar 2012 14:34:07 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Mar 2012 09:34:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD02B8.ADFD7878" Date: Thu, 15 Mar 2012 09:34:06 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1C75@XMB-RCD-109.cisco.com> In-Reply-To: <4F61E53D.4050904@globis.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [v6ops] RFC6204bis-07 Thread-Index: Ac0CqgRaMfmP4UoMRB2Nc5KMrjxeSAADO/dg References: <867F4B6A1672E541A94676D556793ACD0EB995043C@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3042FEBDB@XMB-RCD-109.cisco.com> <4F61E53D.4050904@globis.net> From: "Hemant Singh (shemant)" To: "Ray Hunter" X-OriginalArrivalTime: 15 Mar 2012 14:34:08.0088 (UTC) FILETIME=[AE0C1D80:01CD02B8] Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 14:34:09 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD02B8.ADFD7878 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Ray, =20 From: Ray Hunter [mailto:v6ops@globis.net]=20 Sent: Thursday, March 15, 2012 8:49 AM To: Hemant Singh (shemant) Cc: Wuyts Carl; v6ops@ietf.org Subject: Re: Re: [v6ops] RFC6204bis-07 =20 >Hermant, IMHO the root cause of the prefix size "too small" problem is that the operator of the DHCPv6 PD delegating router has not adhered to BCP >RFC6177 Section 5 Summary. Not quite. Carl just reported he their CE routers deployed with a /64. RFC 6177 does not recommend a size but does relax the old /48 with a /56 recommendation.=20 >WPD-3 of RFC6204bis suggests logging a system management error, but I don't see anything in RFC6204bis or RFC3633 or RFC3315 that would allow a CE >manufacturer/end user who is operating the requesting router to be able to signal back to the delegating router (where the root cause of the >problem lies) that the prefix was too small (either via a DHCPv6 PD status code such as "PREFIX_TOO_SMALL", or any other standard logging >mechanism). That is why the CE router has to log an error. How the CE does that is out of scope of the document. Some CE router can be a sophisticated SOHO router that supports syslog error messages while another cheap retail router uses an LED to signal the error. Or use a different color with an existing LED. Also if the CE router supports a web UI, the UI also displays the error.=20 >Local system management logging would not seem to address the root cause, and would seem to potentially leave the end user/ CE manufacturer in no >man's land.=20 With the error, the user can at least call the SP to report the issue. Sure, calling the SP is not a good option, but what can the CE do if the protocols do not support reporting such a failure. At this point I am not sure if the protocols can even do anything about the situation because one does not know when the user provisions his/her last subnet that goes one over the PD allocation which could be days after the PD was acquired with DHCPv6. =20 >To address the root cause, I'd like to propose RFC6024bis refer to RFC6177 as a normative reference. But Carl already has a use case of a /64. I am not for or against adding RFC 6177. Others in the WG can comment.=20 Regards, =20 Hemant ------_=_NextPart_001_01CD02B8.ADFD7878 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Ray,

 

From: = Ray Hunter [mailto:v6ops@globis.net]
Sent: Thursday, March = 15, 2012 8:49 AM
To: Hemant Singh (shemant)
Cc: = Wuyts Carl; v6ops@ietf.org
Subject: Re: Re: [v6ops] = RFC6204bis-07

 

>Hermant, IMHO the root cause of the = prefix size "too small" problem is that the operator of the = DHCPv6 PD delegating router has not adhered to BCP >RFC6177 Section 5 = Summary.

Not  quite.  Carl just reported he = their CE routers deployed with a /64.    RFC 6177 does = not recommend a size but does relax the old /48 with a /56 = recommendation.


>WPD-3 of RFC6204bis suggests logging = a system management error, but I don't see anything in RFC6204bis or = RFC3633 or RFC3315 that would allow a CE >manufacturer/end user who is = operating the requesting router to be able to signal back to the = delegating router (where the root cause of the >problem lies) that the prefix was = too small (either via a DHCPv6 PD status code such as = "PREFIX_TOO_SMALL", or any other standard logging >mechanism).

That is why the CE router has to log an = error.  How the CE does that is out of scope of the = document.   Some CE router can be a sophisticated SOHO router = that supports syslog error messages while another cheap retail router = uses an LED to signal the error.  Or use a different color with an = existing LED.   Also if the CE router supports a web UI, the = UI also displays the error.


>Local system management logging would not seem to address the root = cause, and would seem to potentially leave the end user/ CE manufacturer = in no >man's land.

With the error, the user can at least call the = SP to report the issue.   Sure, calling the SP is not a good = option, but what can the CE do if the protocols do not support reporting = such a failure.    At this point I am not sure if the = protocols can even do anything about the situation because one does not = know when the user provisions his/her last subnet that goes one over the = PD allocation which could be days after the PD was acquired with = DHCPv6. 


>To address the root cause, I'd like = to propose RFC6024bis refer to RFC6177 as a normative = reference.

But Carl already has a use case of a /64.  =  I am not for or against adding RFC 6177.   Others in the = WG can comment.


Regards,

 

Hemant

------_=_NextPart_001_01CD02B8.ADFD7878-- From cb.list6@gmail.com Thu Mar 15 08:13:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C82821F8582 for ; Thu, 15 Mar 2012 08:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.465 X-Spam-Level: X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 jkcTo5UkmBpW for ; Thu, 15 Mar 2012 08:13:51 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1743C21F8552 for ; Thu, 15 Mar 2012 08:13:51 -0700 (PDT) Received: by yhkk25 with SMTP id k25so561754yhk.31 for ; Thu, 15 Mar 2012 08:13:48 -0700 (PDT) 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:content-transfer-encoding; bh=NggUZJG43XRRJ+GVP+wA/iFEIHwG75QvoMmv3bCfPAQ=; b=KANNbrygjNAW0UziSRCbmSoJnVcrGq6t9QXtFR3MdbFeZln9kWCn5um9e50XUtedF3 JJunydnZ22Yy5WqHcdXepjtnSwxDSRCy6F82EhCQdZXDNcYkYVlRgQkN/WCs25XGyZ7A 5yLk8F/4jNvo/PoKa3VLg4IqRjJhHBslrJhdXi574Zvz7YSqd4E8NGMIpMhF8TFf2VOf c4O2Cd/2PzPK9fO6AcZP0PEmrnAd7qnjLrF/NSht2BpdHp8ELfG34inrp512iMzWfgG/ Slj+I+o5eFxlwEdBQxNygYNMntV1/HtT4BW0pGMfnzNTgHbNvwiiEn4kh+1D2AMR70JO MaTA== MIME-Version: 1.0 Received: by 10.68.132.102 with SMTP id ot6mr5725008pbb.76.1331824428341; Thu, 15 Mar 2012 08:13:48 -0700 (PDT) Received: by 10.142.163.16 with HTTP; Thu, 15 Mar 2012 08:13:48 -0700 (PDT) In-Reply-To: References: <20120315113825.GA84425@Space.Net> Date: Thu, 15 Mar 2012 08:13:48 -0700 Message-ID: From: Cameron Byrne To: Wojciech Dec Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] Nomative language in draft-ietf-v6ops-464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 15:13:52 -0000 On Thu, Mar 15, 2012 at 6:25 AM, Wojciech Dec wrote: > > > On 15 March 2012 12:38, Gert Doering wrote: >> >> Hi, >> >> On Thu, Mar 15, 2012 at 10:03:00AM +0100, Wojciech Dec wrote: >> > You haven't answered a major question; what is the purpose/goal of the >> > document? >> >> To tell people about a specific solution that solves a specific problem. >> >> I, for one, appreciate that. =A0I'm an operator, and I like it if I can >> look at recipes for "if you have a problem similar to *this*, here's one >> possible solution that could work for you as well" - and the IETF benefi= ts >> from producing documents that operators find useful. > > > Cool, no problem with that, but in doing so would you agree if the soluti= on > did not attempt to be a spec for implementers of a "sub-class" NAT64 - wh= ich > it appears intended on being. I proposed formulating some text that would > remove this concern. > >> >> >> >> Now, what is the goal of *your* actions? =A0I find this somewhat confusi= ng, >> you spend quite some effort in telling Cameron that he's getting it all >> wrong - so what is your agenda? > > > Perhaps you didn't quite read the thread where I wrote "I think that this > work is very useful and am supporting...". > In terms of the issue; consider some of the use-cases that this solution > apparently does not support, but which a standard NAT64 based solution ha= s > no problem with, eg use on non 3G networks, or even on 3G networks where > operators have some different ideas on IP subnet design or routing or You say that it will not work on 3G or non-3G networks when they have 'different ideas' about addressing? "different ideas" is not a technical argument. And, in fact, the case of 3GPP... there is no different ideas about numbering in IPv6, there is only 1 idea, /64 per network attachment, no other way. http://tools.ietf.org/html/rfc6459#section-5.2 > services. Given that this solution claims to be using regular NAT64, but Yes, a regular NAT64 can be configured with Pref64 =3D /96, and in fact, AKAIK, this is best practice for NAT64 operators to use a /96 specifically. I have, in practice, never seen anything other than a /96. > doesn't support such use-cases, there is something amiss. > Seeking clarity on that, the underlying assumptions, is a good thing to h= ave Seeking clarity? You have sent several emails with the same hand wavy requ= est. > for a document seeking WG acceptance. Furthermore, the core problem that Rough consensus and all meaningful technical issues have been addressed, AF= AIK > this draft addresses fundamentally (IPv4 over and acrss IPv6) is the subj= ect > of various other drafts - knowing how these compare should be understood, ^^^^^^ there's the meat. Woj wants to cast 464XLAT as a subcase of MAP-T. But this is not possible since MAP-T is explicitly by Softwire charter a stateless solution. And, 464XLAT is explicitly a stateful solution. > unless you're saying that you're happy with potentially operating N > different solutions for this core problem due to specific issues with eac= h, Some people like IS-IS, others like OSPF, i don't see the problem with having both and letting operators choose. 464XLAT can been seen as simply an operational guide to improving chances of success with the existing transition strategy outlined in RFC6144 > that you'll only find out about when specific & not compatible devices ar= e > shipping for each? > Ah, but be afraid of the unknown. FUD. The purpose of 464XLAT is to explain what works, not define what does not work. > Woj > - Individual ^^^^ Who also works at Cisco and does not run a network and is a co-author of MAP-T in Softwires (since someone asked about "agendas" on the list) CB >> >> >> Gert Doering >> =A0 =A0 =A0 =A0-- Operator >> -- >> have you enabled IPv6 on something today...? >> >> SpaceNet AG =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Vorstand: Seb= astian v. Bomhard >> Joseph-Dollinger-Bogen 14 =A0 =A0 =A0 =A0 =A0Aufsichtsratsvors.: A. >> Grundner-Culemann >> D-80807 Muenchen =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 HRB: 136055 (AG Mue= nchen) >> Tel: +49 (89) 32356-444 =A0 =A0 =A0 =A0 =A0 =A0USt-IdNr.: DE813185279 > > From despres.remi@laposte.net Thu Mar 15 09:02:13 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5552421F8777 for ; Thu, 15 Mar 2012 09:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] 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 U5yNQQPQLuz8 for ; Thu, 15 Mar 2012 09:02:12 -0700 (PDT) Received: from smtpout.laposte.net (smtpout2.laposte.net [193.253.67.227]) by ietfa.amsl.com (Postfix) with ESMTP id EE03821F8773 for ; Thu, 15 Mar 2012 09:02:11 -0700 (PDT) Received: from [192.168.0.21] ([88.166.221.144]) by mwinf8503-out with ME id ls291i00L37Y3f403s29bo; Thu, 15 Mar 2012 17:02:10 +0100 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Thu, 15 Mar 2012 17:02:09 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <38814863-EFB4-481C-A3A4-A7680A282913@laposte.net> References: <20120315113825.GA84425@Space.Net> To: Cameron Byrne X-Mailer: Apple Mail (2.1084) Cc: v6ops@ietf.org Subject: Re: [v6ops] Nomative language in draft-ietf-v6ops-464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 16:02:13 -0000 2012-03-15 16:13, Cameron Byrne: > On Thu, Mar 15, 2012 at 6:25 AM, Wojciech Dec = wrote: >>=20 >=20 >> this draft addresses fundamentally (IPv4 over and acrss IPv6) is the = subject >> of various other drafts - knowing how these compare should be = understood, +1 on the need for conscious study of what is common to stateless and = stateful (quite a bit AFAIK). >=20 > ^^^^^^ there's the meat. Woj wants to cast 464XLAT as a subcase of > MAP-T. But this is not possible since MAP-T is explicitly by Softwire > charter a stateless solution. And, 464XLAT is explicitly a stateful > solution. I proposed to explain, in v6ops, the common ground between 464XLAT-like = scenarios and a feature of the 4rd-u proposal that has been introduced = precisely for such scenarios. This doesn't seem to be welcome so far in v6ops, but I KEEP HOPE that = people like you could become such a presentation (after all, avoiding to = talk about problems isn't the best way to solve them, right?). >> unless you're saying that you're happy with potentially operating N >> different solutions for this core problem due to specific issues with = each, >=20 > Some people like IS-IS, others like OSPF, i don't see the problem with > having both and letting operators choose. >=20 > 464XLAT can been seen as simply an operational guide to improving > chances of success with the existing transition strategy outlined in > RFC6144 There has been an interesting discussion beginning in v6ops on whether = it would be preferable to have NAT44s in UEs, or not.=20 Isn't this, for example, a valid subject to be continued in v6ops (an = with due understanding of what is common to Softwire solutions regarding = NAT44s in customer nodes). Regards, RD PS: To me, 4X4XLAT as a v6ops informational document is less logical = than having it as an individual submission, but can be acceptable = provided discussion on how it relates to Softwire's solutiopns isn't = excluded. From ichiroumakino@gmail.com Thu Mar 15 09:56:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3393A21F87D1 for ; Thu, 15 Mar 2012 09:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.975 X-Spam-Level: X-Spam-Status: No, score=-2.975 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, 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 rikVvSCIM1Pt for ; Thu, 15 Mar 2012 09:56:33 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 764D221F87CA for ; Thu, 15 Mar 2012 09:56:31 -0700 (PDT) Received: by werb10 with SMTP id b10so3744795wer.31 for ; Thu, 15 Mar 2012 09:56:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=cskPtKo/VXwt8lgEL7pfX8sezBwo594lkT6r5YDngTs=; b=dw8pGeHe/PpA7ihSGvjJrK0L8dZ1Q2u/apnH+stET1AFquytUYhJEAJDGack7+KeaZ mfDAldBRhsJQzsOGnm8NAXpz/a9sK7GAyIUmHtoQtfpWB2ixXpOxzWTnoIUTcxZOl4ry 2llG2P2OiWzf+FR8g9ec7Gf3BM+S4CaLcRENHhYtZcQ4k0G6jx/eVzEcefu9fK+/ltuN jfx7KeL9Vi/Hiy0qqa611ZITsxnL18UYgKbgdWsvL7TUHdpUeLTjh0pxzPqgqaqiLf6L A4s02ms3470GgKmLilnS5xyjMiEFf4TG9Ig7hShyPO11Gz5mhz0b/Fl7T+8hV+jfMu8w QQOA== Received: by 10.180.82.136 with SMTP id i8mr17295805wiy.19.1331830589936; Thu, 15 Mar 2012 09:56:29 -0700 (PDT) Received: from dhcp-10-61-99-92.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id e6sm6356761wix.8.2012.03.15.09.56.26 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Mar 2012 09:56:29 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <867F4B6A1672E541A94676D556793ACD0EB995043C@MOPESMBX01.eu.thmulti.com> Date: Thu, 15 Mar 2012 09:56:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <89533DAD-CF07-4950-84FB-A448C6790B3B@employees.org> References: <867F4B6A1672E541A94676D556793ACD0EB995043C@MOPESMBX01.eu.thmulti.com> To: Wuyts Carl X-Mailer: Apple Mail (2.1257) Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 16:56:45 -0000 Carl, WPD-3 does two things. it states that if the CPE uses a hint, then it = must be prepared to accept a different size than what it asked for. = secondly it states that if address block delegated is too small for the = sites needs, you are in undefined territory. can we do better than "undefined" for that latter case? I'm not sure, = given the protocol we have. cheers, Ole On Mar 15, 2012, at 3:30 , Wuyts Carl wrote: > All, > =20 > One which sort of slipped through my review is the following (although = I might have commented on this one before): > =93=94 > WPD-3: The IPv6 CE router MUST be prepared to accept a delegated > prefix size different from what is given in the hint. If = the > delegated prefix is too small to address all of its > interfaces, the IPv6 CE router SHOULD log a system = management > error. > =20 > =93=94 > The issue I can see is with =93=85 if the delegated prefix is too = small to address all of its interfaces =85=94. Too small, what is that = exactly ? I don=92t think the CPE should first inspect all of its LAN = interfaces (count them) and then judge whether or not the PD is =93large = enough=94. Someone could even reserve something from the pd for the = loop, adding an extra prefix, should this one be counted too in this = case ? What with configuration changes ? What if the customer expects = to have multiple prefixes on each or some LAN intfs, should the CPE have = some multiplier function to calculate ? Moreover, it must also check = the pd-exclude, if present. > Isn=92t this all going a bit too far ? > What about the result when it is too small ? You hand out what you = have ? or you don=92t hand out anything, so just logging ? but the = logging is no MUST, hence no-one might notice, apart from the end-user = who can or cannot browse the web ? > =20 > Regs > Carl > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From wdec.ietf@gmail.com Thu Mar 15 11:40:51 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357AB21F8730 for ; Thu, 15 Mar 2012 11:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.993 X-Spam-Level: X-Spam-Status: No, score=-2.993 tagged_above=-999 required=5 tests=[AWL=0.005, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 9-YHj7O4zWgf for ; Thu, 15 Mar 2012 11:40:50 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id C690A21F86BE for ; Thu, 15 Mar 2012 11:40:49 -0700 (PDT) Received: by ggmi1 with SMTP id i1so3851831ggm.31 for ; Thu, 15 Mar 2012 11:40:49 -0700 (PDT) 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=Lw8tn/V1mr7+2gBB1V70e49nCdhtFKiXNK7afFuWtuo=; b=xh/Pfv4D2/Kb8RPQvamy1jJotTJGnYVDbO1oq01+To2mWpAD75/Yt3Yk6lrskKCovz trKtePh93upwbwvr+8rvFCEfvanQYqtH0zUxjbYm4YgiABOpOyPIQyV0Ff/B2VgURpFi qmLElA9rTDij8DpLGMNtNwkqVip7dkLQqT9RPKRn+kIAEtRwrIjkRgVvyJe8y8DJPflb aDFTZA303wKkuerVhRw9pz7wxD9LXYlj1F0jcjth8HHYFhCusjVYyuasrc/p3IQkWVXH Yd/zYYYzZkEfUK5/QUltBnD9M+PvrAga1/zCF6ZkWJuZfOv2w0FvVijxPoN1mJ1H6iRW DOGA== MIME-Version: 1.0 Received: by 10.224.59.194 with SMTP id m2mr304489qah.46.1331836849292; Thu, 15 Mar 2012 11:40:49 -0700 (PDT) Received: by 10.229.218.4 with HTTP; Thu, 15 Mar 2012 11:40:49 -0700 (PDT) In-Reply-To: References: <20120315113825.GA84425@Space.Net> Date: Thu, 15 Mar 2012 19:40:49 +0100 Message-ID: From: Wojciech Dec To: Cameron Byrne Content-Type: multipart/alternative; boundary=20cf306f77b44d043e04bb4c6e30 Cc: v6ops@ietf.org Subject: Re: [v6ops] Nomative language in draft-ietf-v6ops-464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 18:40:51 -0000 --20cf306f77b44d043e04bb4c6e30 Content-Type: text/plain; charset=ISO-8859-1 On 15 March 2012 16:13, Cameron Byrne wrote: > > On Thu, Mar 15, 2012 at 6:25 AM, Wojciech Dec wrote: > > > > > > On 15 March 2012 12:38, Gert Doering wrote: > >> > > Yes, a regular NAT64 can be configured with Pref64 = /96, and in > fact, AKAIK, this is best practice for NAT64 operators to use a /96 > specifically. > The point is that NAT64 allows other configurations while your "document" somehow insist on that /96 hard rule. Modify the text to saying that this is what you used/configured in your deployment, why you found it useful perhaps, and we'd be settled on this point. > > I have, in practice, never seen anything other than a /96. > > > doesn't support such use-cases, there is something amiss. > > Seeking clarity on that, the underlying assumptions, is a good thing to > have > > Seeking clarity? You have sent several emails with the same hand wavy > request. > Let's see. So far we've deduced that you do NOT expect this to work (ie it is out of scope): - beyond your 3G network, eg it's not expected to work when a user connects that same device via WiFi say (unless all networks are made to look like 3G, apparently) - with a different core NAT64 device, ie a stateless core NAT64. - if an operator actually wants to support a fixed/public IPv4 address to the UE (a service model seen in many 3G networks today - not yours, I understand). - Cases where routing on /96s is not viable. - Connecting clients on a shared prefix/subnet - Addressing with a DHCP PD that's different than a /64 - NAT44 on the UE. While you may say that this is hand waving, at least I know your better assumptions now. It would be useful to have these, or rather the inverse "working service" assumptions clarified in the doc IMO. > > > for a document seeking WG acceptance. Furthermore, the core problem that > > Rough consensus and all meaningful technical issues have been addressed, > AFAIK > > > this draft addresses fundamentally (IPv4 over and acrss IPv6) is the > subject > > of various other drafts - knowing how these compare should be understood, > > ^^^^^^ there's the meat. Woj wants to cast 464XLAT as a subcase of > MAP-T. But this is not possible since MAP-T is explicitly by Softwire > charter a stateless solution. And, 464XLAT is explicitly a stateful > solution. > You keep on coming back to MAP-T, not me, nor am I pushing to present that as the "right" solution. I'm focusing on the fact that you claim the CLAT to be regular NAT64, but yet continue to refuse to relax text (section 6.1) that a regular NAT64 does not have. That and understanding the assumptions of your solution. > > > unless you're saying that you're happy with potentially operating N > > different solutions for this core problem due to specific issues with > each, > > Some people like IS-IS, others like OSPF, i don't see the problem with > having both and letting operators choose. > > 464XLAT can been seen as simply an operational guide to improving > chances of success with the existing transition strategy outlined in > RFC6144 > > > that you'll only find out about when specific & not compatible devices > are > > shipping for each? > > > > Ah, but be afraid of the unknown. FUD. The purpose of 464XLAT is to > explain what works, not define what does not work. > There is nothing unknown here, other than perhaps further undocumented assumptions of 464xlat. :-) What is known however is that there are multiple solutions to the same core problem of v4 over & across v6 (dIVI, BIH, MAP-T, 4rd-u, etc), of which 464xlat appears to be one, and which does involve some unique functional specification that you seek to drive, eg the workings of the CLAT. Without some IETF consolidation/rationalization/guidance, and given that this document (and others) are to steer implementers (your words), we're headed for a likely scenario of partially or fully incompatible solutions. Each solution does have its specific nuances, and IMO it would be of interest to the v6ops WG ie the operator & vendor community to actually understand these, when making one or multiple recommendations. Effectively saying "Here's my solution, it works for what I need, don't care about anything else. Please adopt it as is as an IETF recommendation, because I need that to get it in front of my implementers/vendors" without even bothering to look for commonality appears not entirely reasonable, to me at least in terms of an IETF doc. I believe Remi also called for as much. The prospect of N WG's all with work on this "common problem" is not appealing. > > > Woj > > - Individual > ^^^^ > Who also works at Cisco and does not run a network and is a co-author > of MAP-T in Softwires (since someone asked about "agendas" on the > list) > I know that you're perhaps not very familiar with the customs of the ietf, but the general rule is that everyone speaks as an individual. My MAP-T if not other work, allows me some modest insight into this problem space, and as stated previously my agenda is to seek clarity in your specification and an understanding of the differences between xlat and the various other solutions. -Woj. -Individual (working currently for a vendor, and net-ops guy in a former life) > > CB > >> > >> > >> Gert Doering > >> -- Operator > >> -- > >> have you enabled IPv6 on something today...? > >> > >> SpaceNet AG Vorstand: Sebastian v. Bomhard > >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. > >> Grundner-Culemann > >> D-80807 Muenchen HRB: 136055 (AG Muenchen) > >> Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 > > > > > --20cf306f77b44d043e04bb4c6e30 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 15 March 2012 16:13, Cameron Byrne <cb.list6@gmail.com> wrote:

On Thu, Mar 15, 2012 at 6:25 AM, Wojciech Dec <wdec.ietf@gmail.com> wrote:=
>
>
> On 15 March 2012 12:38, Gert Doering <gert@space.net> wrote:
>>

Yes, a regular NAT64 can be configured with Pref64 =3D =A0/96, and in=
fact, AKAIK, this is best practice for NAT64 operators to use a /96
specifically.

The point is that NAT64 allows other= configurations while your "document" somehow insist on that /96 = hard rule. Modify the text to saying that this is what you used/configured = in your deployment, why you found it useful perhaps, and we'd be settle= d on this point.
=A0

I have, in practice, never seen anything other than a /96.

> doesn't support such use-cases, there is something amiss.
> Seeking clarity on that, the underlying assumptions, is a good thing t= o have

Seeking clarity? =A0You have sent several emails with the same hand w= avy request.

Let's see. So far we've deduc= ed that you do NOT expect this to work (ie it is out of scope):
- beyond= your 3G network, eg it's not expected to work when a user connects tha= t same device via WiFi say (unless all networks are made to look like 3G, a= pparently)
-=A0 with a different core NAT64 device, ie a stateless core NAT64.
- if= an operator actually wants to support a fixed/public IPv4 address to the U= E (a service model seen in many 3G networks today - not yours, I understand= ).
- Cases where routing on /96s is not viable.
- Connecting clients on a s= hared prefix/subnet
- Addressing with a DHCP PD that's different tha= n a /64
- NAT44 on the UE.
While you may say that this is hand waving= , at least I know your better assumptions now. It would be useful to have t= hese, or rather the inverse "working service" assumptions clarifi= ed in the doc IMO.
=A0

> for a document seeking WG acceptance. Furthermore, the core problem th= at

Rough consensus and all meaningful technical issues have been address= ed, AFAIK

> this draft addresses fundamentally (IPv4 over and acrss IPv6) is the s= ubject
> of various other drafts - knowing how these compare should be understo= od,

^^^^^^ there's the meat. =A0Woj wants to cast 464XLAT as a subcas= e of
MAP-T. =A0But this is not possible since MAP-T is explicitly by Softwire charter a stateless solution. =A0And, 464XLAT is explicitly a stateful
solution.

You keep on coming back to MAP-T, not me= , nor am I pushing to present that as the "right" solution. I'= ;m focusing on the fact that you claim the CLAT to be regular NAT64, but ye= t continue to refuse to relax text (section 6.1) that a regular NAT64 does = not have. That and understanding the assumptions of your solution.



> unless you're saying that you're happy with potentially operat= ing N
> different solutions for this core problem due to specific issues with = each,

Some people like IS-IS, others like OSPF, i don't see the problem= with
having both and letting operators choose.

464XLAT can been seen as simply an operational guide to improving
chances of success with the existing transition strategy outlined in
RFC6144

> that you'll only find out about when specific & not compatible= devices are
> shipping for each?
>

Ah, but be afraid of the unknown. FUD. =A0The purpose of 464XLAT is t= o
explain what works, not define what does not work.
There is nothing unknown here, other than perhaps further undocumented ass= umptions of 464xlat. :-)
What is known however is that there are multipl= e solutions to the same core problem of v4 over & across v6 (dIVI, BIH,= MAP-T, 4rd-u, etc), of which 464xlat appears to be one, and which does inv= olve some unique functional specification that you seek to drive, eg the wo= rkings of the CLAT.
Without some IETF consolidation/rationalization/guidance, and given that th= is document (and others) are to steer implementers (your words), we're = headed for a likely scenario of partially or fully incompatible solutions. = Each solution does have its specific nuances, and IMO it would be of intere= st to the v6ops WG ie the operator & vendor community to actually under= stand these, when making one or multiple recommendations. Effectively sayin= g "Here's my solution, it works for what I need, don't care ab= out anything else. Please adopt it as is as an IETF recommendation, because= I need that to get it in front of my implementers/vendors" without ev= en bothering to look for commonality appears not entirely reasonable, to me= at least in terms of an IETF doc. I believe Remi also called for as much. = The prospect of N WG's all with work on this "common problem"= is not appealing.

=A0

> Woj
> - Individual
^^^^
Who also works at Cisco and does not run a network and is a co-author
of MAP-T in Softwires (since someone asked about "agendas" on the=
list)

I know that you're perhaps not very fami= liar with the customs of the ietf, but the general rule is that everyone sp= eaks as an individual.
My MAP-T if not other work, allows me some modes= t insight into this problem space, and as stated previously my agenda is to= seek clarity in your specification and an understanding of the differences= between xlat and the various other solutions.

-Woj.
=A0-Individual (working currently for a vendor, and net-ops gu= y in a former life)

CB
>>
>>
>> Gert Doering
>> =A0 =A0 =A0 =A0-- Operator
>> --
>> have you enabled IPv6 on something today...?
>>
>> SpaceNet AG =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Vorstan= d: Sebastian v. Bomhard
>> Joseph-Dollinger-Bogen 14 =A0 =A0 =A0 =A0 =A0Aufsichtsratsvors.: A= .
>> Grundner-Culemann
>> D-80807 Muenchen =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 HRB: 136055 (= AG Muenchen)
>> Tel: +49 (89) 32356-444 =A0 =A0 =A0 =A0 =A0 =A0USt= -IdNr.: DE813185279
>
>

--20cf306f77b44d043e04bb4c6e30-- From ales.vizdal@t-mobile.cz Thu Mar 15 12:02:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C48121E804A for ; Thu, 15 Mar 2012 12:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.83 X-Spam-Level: X-Spam-Status: No, score=-0.83 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3] 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 uyASUaer+ipE for ; Thu, 15 Mar 2012 12:02:04 -0700 (PDT) Received: from mailhub1.t-mobile.cz (mailhub1.t-mobile.cz [62.141.0.149]) by ietfa.amsl.com (Postfix) with ESMTP id 2F76421E8047 for ; Thu, 15 Mar 2012 12:02:03 -0700 (PDT) Received: from srvhk503.rdm.cz (unknown [10.246.143.95]) by mailhub1.t-mobile.cz (Postfix) with ESMTP id 752B5285810; Thu, 15 Mar 2012 20:02:02 +0100 (CET) Received: from SRVHKE02.rdm.cz ([fe80::94ce:8456:f6fa:86a8]) by srvhk503.rdm.cz ([fe80::a0bc:fdcc:adf9:5f66%12]) with mapi; Thu, 15 Mar 2012 20:02:02 +0100 From: =?utf-8?B?VsOtemRhbCBBbGXFoQ==?= To: =?utf-8?B?T2xlIFRyw7hhbg==?= , Wuyts Carl Date: Thu, 15 Mar 2012 20:01:08 +0100 Thread-Topic: [v6ops] RFC6204bis-07 Thread-Index: Ac0CzLBxfubnfXH7RWa96EzbJufbLAAEIrWA Message-ID: <1808340F7EC362469DDFFB112B37E2FCC67EDAAC14@SRVHKE02.rdm.cz> References: <867F4B6A1672E541A94676D556793ACD0EB995043C@MOPESMBX01.eu.thmulti.com> <89533DAD-CF07-4950-84FB-A448C6790B3B@employees.org> In-Reply-To: <89533DAD-CF07-4950-84FB-A448C6790B3B@employees.org> 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: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 19:02:05 -0000 T2xlLA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHY2b3BzLWJvdW5j ZXNAaWV0Zi5vcmcgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg T2xlDQo+IFRyb2FuDQo+IFNlbnQ6IFRodXJzZGF5LCBNYXJjaCAxNSwgMjAxMiA1OjU2IFBNDQo+ IFRvOiBXdXl0cyBDYXJsDQo+IENjOiB2Nm9wc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3Y2 b3BzXSBSRkM2MjA0YmlzLTA3DQo+IA0KPiBDYXJsLA0KPiANCj4gV1BELTMgZG9lcyB0d28gdGhp bmdzLiBpdCBzdGF0ZXMgdGhhdCBpZiB0aGUgQ1BFIHVzZXMgYSBoaW50LCB0aGVuIGl0IG11c3Qg YmUgcHJlcGFyZWQNCj4gdG8gYWNjZXB0IGEgZGlmZmVyZW50IHNpemUgdGhhbiB3aGF0IGl0IGFz a2VkIGZvci4NCg0KRG9lcyBpdCBtYWtlIHNlbnNlIHJlcGVhdCB3aGF0J3MgYWxyZWFkeSB3cml0 dGVuIGluIFNlY3Rpb24gMTEuMiBvZiBSRkMzNjMzPyBHaXZlbiB0aGF0DQo2MjA0YmlzIHJlcXVp cmVzIGNvbXBsaWFuY2UgdG8gUkZDMzYzMy4NCg0KICAgSWYgdGhlIHJlcXVlc3Rpbmcgcm91dGVy IGluY2x1ZGVzIGFuIElBX1BEIFByZWZpeCBvcHRpb24gaW4gdGhlIElBX1BEDQogICBvcHRpb24g aW4gaXRzIFNvbGljaXQgbWVzc2FnZSwgdGhlIGRlbGVnYXRpbmcgcm91dGVyIE1BWSBjaG9vc2Ug dG8NCiAgIHVzZSB0aGUgaW5mb3JtYXRpb24gaW4gdGhhdCBvcHRpb24gdG8gc2VsZWN0IHRoZSBw cmVmaXgoZXMpIG9yIHByZWZpeA0KICAgc2l6ZSB0byBiZSBkZWxlZ2F0ZWQgdG8gdGhlIHJlcXVl c3Rpbmcgcm91dGVyLg0KDQo+IGNoZWVycywNCj4gT2xlDQoNCkNoZWVycywNCkFsZXMNCg== From cb.list6@gmail.com Thu Mar 15 13:26:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7969D21E8020 for ; Thu, 15 Mar 2012 13:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.166 X-Spam-Level: X-Spam-Status: No, score=-3.166 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 1IEmTaAmGbo0 for ; Thu, 15 Mar 2012 13:26:53 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9F89521E801B for ; Thu, 15 Mar 2012 13:26:53 -0700 (PDT) Received: by dakl33 with SMTP id l33so5881610dak.31 for ; Thu, 15 Mar 2012 13:26:53 -0700 (PDT) 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:content-transfer-encoding; bh=LW3BwmgtsL9YjZqKdG70+2j6wWOM253ygcXYAWyhI5g=; b=lt0D/LdyZ1iP0PpnNIhwCIyVG5Ovx7OWOAmzW+pKHtni/PajJ6zKlCvTuElnXCxb9r m59B3sLkcqDk5IRVS8B46RWEjtEZwxi4GN5FVI0zv3+tYANTOEc+ZV56YeH8STww2teW mdhkQ7kIz+fU+/sj4GN1CSusvRAj3XxNCmOzNHhGCbvFkoB01n8kz/u71i6VRLluahub SH4t2Ud8te37DZk8bHMWdF64e/+mWG1BTHdWNheAvZZVJ+lgytDXvfmx2e+VVp656jwf a3UzGfh6EQZlWhv/azZkSxI2G29YXpL4uwGxoRMpVqIbyHB9y/sjH31AMnJA2bee0339 CIJA== MIME-Version: 1.0 Received: by 10.68.230.41 with SMTP id sv9mr7644839pbc.48.1331843213347; Thu, 15 Mar 2012 13:26:53 -0700 (PDT) Received: by 10.143.160.13 with HTTP; Thu, 15 Mar 2012 13:26:53 -0700 (PDT) In-Reply-To: References: <20120315113825.GA84425@Space.Net> Date: Thu, 15 Mar 2012 13:26:53 -0700 Message-ID: From: Cameron Byrne To: Wojciech Dec Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] Nomative language in draft-ietf-v6ops-464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 20:26:54 -0000 On Thu, Mar 15, 2012 at 11:40 AM, Wojciech Dec wrote: > > > On 15 March 2012 16:13, Cameron Byrne wrote: >> >> >> On Thu, Mar 15, 2012 at 6:25 AM, Wojciech Dec wrot= e: >> > >> > >> > On 15 March 2012 12:38, Gert Doering wrote: >> >> >> >> Yes, a regular NAT64 can be configured with Pref64 =3D =A0/96, and in >> fact, AKAIK, this is best practice for NAT64 operators to use a /96 >> specifically. > > > The point is that NAT64 allows other configurations while your "document" > somehow insist on that /96 hard rule. Modify the text to saying that this= is > what you used/configured in your deployment, why you found it useful > perhaps, and we'd be settled on this point. > >> >> >> I have, in practice, never seen anything other than a /96. >> >> > doesn't support such use-cases, there is something amiss. >> > Seeking clarity on that, the underlying assumptions, is a good thing t= o >> > have >> >> Seeking clarity? =A0You have sent several emails with the same hand wavy >> request. > > > Let's see. So far we've deduced that you do NOT expect this to work (ie i= t > is out of scope): > - beyond your 3G network, eg it's not expected to work when a user connec= ts > that same device via WiFi say (unless all networks are made to look like = 3G, > apparently) > -=A0 with a different core NAT64 device, ie a stateless core NAT64. > - if an operator actually wants to support a fixed/public IPv4 address to > the UE (a service model seen in many 3G networks today - not yours, I > understand). > - Cases where routing on /96s is not viable. > - Connecting clients on a shared prefix/subnet > - Addressing with a DHCP PD that's different than a /64 > - NAT44 on the UE. > While you may say that this is hand waving, at least I know your better > assumptions now. It would be useful to have these, or rather the inverse > "working service" assumptions clarified in the doc IMO. > The list above is a bit of a broad brush, but i believe the 464XLAT draft describes accurately the situation that we know to work. 464XLAT is not expected to work in environments that are not 464XLAT. Can we please agree to disagree and end the these emails? If other WG folks have a concern, they may express it. Woj, your perspective is well documented in the archive. >> >> >> > for a document seeking WG acceptance. Furthermore, the core problem th= at >> >> Rough consensus and all meaningful technical issues have been addressed, >> AFAIK >> >> > this draft addresses fundamentally (IPv4 over and acrss IPv6) is the >> > subject >> > of various other drafts - knowing how these compare should be >> > understood, >> >> ^^^^^^ there's the meat. =A0Woj wants to cast 464XLAT as a subcase of >> MAP-T. =A0But this is not possible since MAP-T is explicitly by Softwire >> charter a stateless solution. =A0And, 464XLAT is explicitly a stateful >> solution. > > > You keep on coming back to MAP-T, not me, nor am I pushing to present tha= t > as the "right" solution. I'm focusing on the fact that you claim the CLAT= to > be regular NAT64, but yet continue to refuse to relax text (section 6.1) > that a regular NAT64 does not have. That and understanding the assumption= s > of your solution. > ACK, your position is known. >> >> >> > unless you're saying that you're happy with potentially operating N >> > different solutions for this core problem due to specific issues with >> > each, >> >> Some people like IS-IS, others like OSPF, i don't see the problem with >> having both and letting operators choose. >> >> 464XLAT can been seen as simply an operational guide to improving >> chances of success with the existing transition strategy outlined in >> RFC6144 >> >> > that you'll only find out about when specific & not compatible devices >> > are >> > shipping for each? >> > >> >> Ah, but be afraid of the unknown. FUD. =A0The purpose of 464XLAT is to >> explain what works, not define what does not work. > > > There is nothing unknown here, other than perhaps further undocumented > assumptions of 464xlat. :-) Classy. > What is known however is that there are multiple solutions to the same co= re > problem of v4 over & across v6 (dIVI, BIH, MAP-T, 4rd-u, etc), of which > 464xlat appears to be one, and which does involve some unique functional > specification that you seek to drive, eg the workings of the CLAT. > Without some IETF consolidation/rationalization/guidance, and given that > this document (and others) are to steer implementers (your words), we're > headed for a likely scenario of partially or fully incompatible solutions= . Yes. This is not a new problem, and i would argue that it is not a problem at all. IS-IS is not compatible with OSPF, and i don't see people coming up with extension to make it so. > Each solution does have its specific nuances, and IMO it would be of > interest to the v6ops WG ie the operator & vendor community to actually > understand these, when making one or multiple recommendations. Effectivel= y This is not a recommendation, it is an informational draft. > saying "Here's my solution, it works for what I need, don't care about > anything else. Please adopt it as is as an IETF recommendation, because I > need that to get it in front of my implementers/vendors" without even > bothering to look for commonality appears not entirely reasonable, to me = at > least in terms of an IETF doc. I believe Remi also called for as much. Th= e > prospect of N WG's all with work on this "common problem" is not appealin= g. > ACK. Thanks for the feedback. CB > >> >> >> > Woj >> > - Individual >> ^^^^ >> Who also works at Cisco and does not run a network and is a co-author >> of MAP-T in Softwires (since someone asked about "agendas" on the >> list) > > > I know that you're perhaps not very familiar with the customs of the ietf= , > but the general rule is that everyone speaks as an individual. > My MAP-T if not other work, allows me some modest insight into this probl= em > space, and as stated previously my agenda is to seek clarity in your > specification and an understanding of the differences between xlat and th= e > various other solutions. > > -Woj. > =A0-Individual (working currently for a vendor, and net-ops guy in a form= er > life) >> >> >> CB >> >> >> >> >> >> Gert Doering >> >> =A0 =A0 =A0 =A0-- Operator >> >> -- >> >> have you enabled IPv6 on something today...? >> >> >> >> SpaceNet AG =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Vorstand: = Sebastian v. Bomhard >> >> Joseph-Dollinger-Bogen 14 =A0 =A0 =A0 =A0 =A0Aufsichtsratsvors.: A. >> >> Grundner-Culemann >> >> D-80807 Muenchen =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 HRB: 136055 (AG = Muenchen) >> >> Tel: +49 (89) 32356-444 =A0 =A0 =A0 =A0 =A0 =A0USt-IdNr.: DE813185279 >> > >> > > > From Francis.Dupont@fdupont.fr Thu Mar 15 15:59:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF58121E803F for ; Thu, 15 Mar 2012 15:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 llevj-jXorVw for ; Thu, 15 Mar 2012 15:59:53 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 2A24F21E803A for ; Thu, 15 Mar 2012 15:59:52 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2FMxnLg090123; Thu, 15 Mar 2012 23:59:49 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203152259.q2FMxnLg090123@givry.fdupont.fr> From: Francis Dupont To: "Hemant Singh (shemant)" In-reply-to: Your message of Wed, 14 Mar 2012 14:42:16 EST. <5B6B2B64C9FE2A489045EEEADDAFF2C3042FEA7C@XMB-RCD-109.cisco.com> Date: Thu, 15 Mar 2012 23:59:49 +0100 Sender: Francis.Dupont@fdupont.fr Cc: v6ops@ietf.org, Alain Durand , "Dan Wang \(danwan\)" , Dave Thaler Subject: Re: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 22:59:54 -0000 In your previous mail you wrote: > This is some change that Med has asked to make to the PCP text in > rfc6204bis. Please provide comments. Cc to some PCP and DS-Lite > individuals as well. => I have still a concern about a recommendation for PCP when we need only the functionality, PCP is only one of the protocols which can provide it. > From: mohamed.boucadair@orange.com > > >NEW: > > > The WAN interface of the CE router SHOULD support an IPv4 > > PCP client as specified in [I-D.ietf-pcp-base] for use by > > applications on the CE Router. This document takes no > > position on whether such functionality is enabled by > > default or mechanisms by which users would configure the > > functionality. > > Note above that the text says "IPv4 PCP client". => as it is in a SHOULD body you can't keep it so loose. > > Now I am confused by the text below that is referring to > "native IPv6"? We all were expecting IPv4 PCP use case and > thus if you can explain what is the IPv6 PCP use case? > [Med] For DS-Lite we have two alternatives for PCP deployment: => I can't see where this level of details will go (*), IMHO if you want to keep a SHOULD for PCP (and I am strongly opposed to this) you need to cite the base spec, the ds-lite application and the server discovery documents. Regards Francis.Dupont@fdupont.fr PS (*): I am confused about the structure of these messages so I can't say what is a comment for the list or a proposed text for the I-D. And I am not happy with this for a WGLC. From fred@cisco.com Thu Mar 15 16:29:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6443E21F8647 for ; Thu, 15 Mar 2012 16:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.575 X-Spam-Level: X-Spam-Status: No, score=-108.575 tagged_above=-999 required=5 tests=[AWL=0.566, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, 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 FP4CXR89P6-C for ; Thu, 15 Mar 2012 16:29:16 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1647621F8646 for ; Thu, 15 Mar 2012 16:29:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=605; q=dns/txt; s=iport; t=1331854155; x=1333063755; h=subject:mime-version:from:date:cc:message-id:to: content-transfer-encoding; bh=+5Zg8AmD55EW/ldgdmpzDPBbuYM7h6IpikcOfQaO61Q=; b=KOBhA5Wc5Oatpaz703JyjDSSJqsj4CFG9oFEcOGAEe2L2Wyw9MoIgVU3 vfOVFc2CxYXKVF/T/d66zY2OfJ49kyzNMTZmVGnXuW9QkFUjfrMm6Bnb8 iJLZa/1pppSq5z9rtzUsyBNJ0Co/XTeZeAMDxmCkk2TSX1FTPsdMMrPe8 0=; X-IronPort-AV: E=Sophos;i="4.73,593,1325462400"; d="scan'208,217";a="33221579" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 15 Mar 2012 23:29:15 +0000 Received: from Freds-Computer.local (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2FNT4VK030681; Thu, 15 Mar 2012 23:29:14 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Thu, 15 Mar 2012 16:29:15 -0700 X-PGP-Universal: processed; by Freds-Computer.local on Thu, 15 Mar 2012 16:29:15 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker Date: Thu, 15 Mar 2012 16:28:22 -0700 Message-Id: <6A3E52B4-3C21-4A03-92E9-D7E42598AA8D@cisco.com> To: v6ops@ietf.org X-Mailer: Apple Mail (2.1084) Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: v6ops-chairs@tools.ietf.org, Ron Bonica Subject: [v6ops] Reminder: draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 23:29:16 -0000
The working group last call for this draft announced last week continues for another week. Please feel free to comment on it.

From shemant@cisco.com Thu Mar 15 16:35:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E00C21E8044 for ; Thu, 15 Mar 2012 16:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.733 X-Spam-Level: X-Spam-Status: No, score=-9.733 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 7qLsyCKBuxib for ; Thu, 15 Mar 2012 16:35:50 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 797A421E800F for ; Thu, 15 Mar 2012 16:35:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=21080; q=dns/txt; s=iport; t=1331854550; x=1333064150; h=mime-version:subject:date:message-id:from:to; bh=i9BRMGbbh01NZR4zbIZ9j/KYJtIBMQvsmecxktb1XKQ=; b=Y5sRK81h5YVfS0/04zAD/bgQ6rjpBrnjmed7OUL79FIt7Q69ov62KzRv tI6gMpiWLE/KBoD12fDCEbTdn/k3KtDlIJorB+7+IOYoz+82ighmhB9Uq YG/MsTErTe4tCLq7oGdr1BlW9+qLcyjy59IVbrEH8BEaWSpiN0AfbNGx5 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAAV8Yk+tJXG+/2dsb2JhbABCgk6zaYEHggIHAQEBBAEBAQ8BCREDPgYRBgEIEQQBAQsGFwEHJh8HAQEFBAEEEwgahSYHgjsLnEWBJ5ccBJAkYwSIJDObSYFogwSBPg X-IronPort-AV: E=Sophos;i="4.73,593,1325462400"; d="scan'208,217";a="66891007" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 15 Mar 2012 23:35:49 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2FNZnck001361 for ; Thu, 15 Mar 2012 23:35:49 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Mar 2012 18:35:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD0304.5AA6ABD8" Date: Thu, 15 Mar 2012 18:35:48 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1F35@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6204bis WGLC Thread-Index: Acz96uXRwjprUWYLSC2XqBbkihlfsgDkDyJAAF9ZkWA= From: "Hemant Singh (shemant)" To: X-OriginalArrivalTime: 15 Mar 2012 23:35:49.0698 (UTC) FILETIME=[5A843A20:01CD0304] Subject: [v6ops] FW: draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 23:35:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD0304.5AA6ABD8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Quick status on WFLC issues closure(s) and forwarding a private email = that went on between us authors.=20 =20 I have closed most issues raised by different folks in the v6ops mailer = except with Ole; will update the next revision with changes due to = Daniel Roesen's review. Will wait on PCP. Ole's major issues have = been recommended to rfc6204ter. One of Ole's issue related to DHCPv6 = may get into rfc6204bis during the documents IESG stage if there is = resolution.=20 =20 Ole's minor issues were 7 in number out of which I have closed 4. See = below for details. Besides I and Wes all other authors are on the road = in different parts of the world and we could not schedule a WebEx yet. = Will try early next week and try and close the last 3 minor issues from = Ole.=20 =20 Regards, =20 Hemant =20 From: Hemant Singh (shemant)=20 Sent: Tuesday, March 13, 2012 8:59 PM To: Ole Tr=F8an; STARK, BARBARA H Cc: Wes Beebee (wbeebee); Chris Donley; Hemant Singh (shemant) Subject: RE: [v6ops] draft-ietf-v6ops-6204bis WGLC =20 Ole, =20 Let's try and sort out some Minor issues via email because folks are = currently spread all over the map. =20 =20 I have replied to issue 1 in an email to cpe-router that Lorenzo has = section 3.2.1 removed. Please see my email from March 9 and see if = issue 1 is a closed issue. =20 For issue 2, where does the W-3 bullet in rfc6204bis say try router = discovery forever? See section 6.3.7 of RFC 4861 that has the host send = only 3 RS's which is MAX_RTR_SOLICITATIONS. =20 I have also taken care of issue 6.=20 =20 Chris, please take issues 4, 5, and 7 because these issues relate to = changes that would not break CableLabs eRouter cable modem. Or we try = and schedule a phone call to discuss these. I personally agree with you = on issue 4.=20 =20 Ignoring issue 3 for now. This was asked of by Frank Bulk. I can go = back later to his use case or discuss this one with him in v6ops. =20 Thanks, =20 Hemant =20 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Ole Tr=F8an Sent: Friday, March 09, 2012 6:51 AM To: v6ops@ietf.org WG Cc: v6ops-chairs@tools.ietf.org Chairs; Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC =20 Minor: =3D=3D=3D=3D=3D=3D =20 1. Section 3.2.1: Why is this section removed? A dual-stack host is multihomed to IPv4 and IPv6 networks. The IPv4 = and IPv6 topologies may not be congruent, and different addresses may have different = reachability, e.g., ULAs. A host stack has to be able to quickly fail over and try a different = source address and destination address pair if communication fails, as outlined in [HAPPY-EYEBALLS]. Suggestion: Add back the missing paragraph. =20 2. W-3. Question: is there a need for "Router Discovery" to continue = forever? Compared to todays behavior where it times out after 3 attempts? =20 3. WAA-4. Has added support for the DNS Search List option. The CPE acts as a demarcation point between two administrative = domains. It will pass some information learnt from the WAN side DHCP client to = its LAN side DHCP server. I think it is a particularly bad idea to let the = ISP set the DNS search lists for hosts within my home. Why is this option added and what is the use case? Suggestion: Remove requirement for DNSSL =20 4. RFC6204 WAA-7 has been removed. Is that a good idea? I think this point is important to make it clear that RA and DHCP = processing can be done independently of each other. Suggestion: Add requirement back. =20 5. New WAA-7. I think the added "unless configured to require a global = IPv6 address on the WAN interface.", dilutes the purpose of that = requirement. The RFC6204 profile is meant to result in a router that can be = plugged into any access network. Even though certain access networks will not operate = the unnumbered addressing model, how are we going to ensure that no user moves this = CPE to another access network, that requires it? How is this additional "unless configured" testable? This same comment applies to WPD-6. Suggestion: Remove addition text on WPD-6 and WAA-7. =20 6. WPD-1. Generally we have tried to avoid having multiple 2119 keywords = in one requirement. Make PD-exclude a separate requirement. Suggestion: Split requirement in two. =20 7. WPD-4. I disagree with this requirement. It is also hard to test, and = becomes meaningless, given that a CPE must do PD even if M=3D0, O=3D0. Suggestion: revert back to RFC6204:WPD-4 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ------_=_NextPart_001_01CD0304.5AA6ABD8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Quick status on WFLC issues closure(s) and = forwarding a private email that went on between us authors. =

 

I have closed most = issues raised by different folks in the v6ops mailer except with Ole; = will update the next revision with changes due to Daniel Roesen’s = review. =A0Will wait on PCP.=A0=A0 Ole’s major issues have been = recommended to rfc6204ter.=A0 One of Ole’s issue related to DHCPv6 = may get into rfc6204bis during the documents IESG stage if there is = resolution.

 

Ole’s minor issues = were 7 in number out of which I have closed 4.=A0 =A0See below for = details.=A0 Besides I and Wes all other authors are on the road in = different parts of the world and we could not schedule a WebEx yet.=A0 = Will try early next week and try and close the last 3 minor issues from = Ole.

 

Regards,

 

Hemant

 

From:= = Hemant Singh (shemant)
Sent: Tuesday, March 13, 2012 8:59 = PM
To: Ole Tr=F8an; STARK, BARBARA H
Cc: Wes Beebee = (wbeebee); Chris Donley; Hemant Singh (shemant)
Subject: RE: = [v6ops] draft-ietf-v6ops-6204bis = WGLC

 

Ole,

 

Let's try and sort out some Minor = issues via email because folks are currently spread all over the = map. 

 

I have = replied to issue 1 in an email to cpe-router that Lorenzo has = section 3.2.1 removed.   Please see my email from March 9 and = see if issue 1 is a closed issue.

 

For issue 2, where does the = W-3 bullet in rfc6204bis say try router discovery forever?  See = section 6.3.7 of RFC 4861 that has the host send only 3 RS’s which = is MAX_RTR_SOLICITATIONS.

 

I have = also taken care of issue 6.

 

Chris, please take issues 4, 5, = and 7 because these issues relate to changes that would not break = CableLabs eRouter cable modem.  Or we try and schedule a phone call = to discuss these.  I personally agree with you on issue 4. =

 

Ignoring = issue 3 for now.  This was asked of by Frank Bulk.  I = can go back later to his use case or discuss this one with him in = v6ops.

 

Thanks,

 

Hemant

 

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@iet= f.org] On Behalf Of Ole Tr=F8an
Sent: Friday, March 09, 2012 6:51 = AM
To: v6ops@ietf.org WG
Cc: = v6ops-chairs@tools.ietf.org Chairs; Ron Bonica
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis = WGLC

 

Minor:

=3D=3D=3D=3D=3D=3D

 

1. Section 3.2.1: Why is this = section removed?

   A dual-stack host is = multihomed to IPv4 and IPv6 networks. The IPv4 and IPv6 = topologies

   may not be congruent, = and different addresses may have different reachability, e.g., = ULAs.

   A host stack has to be = able to quickly fail over and try a different source address and = destination

   address pair if = communication fails, as outlined in = [HAPPY-EYEBALLS].

   Suggestion: Add back = the missing paragraph.

 

2. W-3. Question: is there a need = for "Router Discovery" to continue = forever?

   Compared to todays = behavior where it times out after 3 attempts?

 

3. WAA-4. Has added support for the = DNS Search List option.

   The CPE acts as a demarcation point between two = administrative domains.

   It will pass some information learnt from the WAN = side DHCP client to its LAN

   side DHCP server. I think it is a particularly bad = idea to let the ISP set the

   DNS search lists for hosts within my = home.

   Why is this option = added and what is the use case?

   Suggestion: Remove requirement for = DNSSL

 

4. = RFC6204 WAA-7 has been removed. Is that a good = idea?

   I think this point is = important to make it clear that RA and DHCP = processing

   can be done = independently of each other.

   Suggestion: Add requirement = back.

 

5. New = WAA-7. I think the added "unless configured to require a global = IPv6

   address on the WAN = interface.", dilutes the purpose of that = requirement.

   The RFC6204 profile is = meant to result in a router that can be plugged into = any

   access network. Even = though certain access networks will not operate the = unnumbered

   addressing model, how = are we going to ensure that no user moves this CPE = to

   another access network, = that requires it?

   How is this additional = "unless configured" testable?

   This same comment applies to = WPD-6.

   Suggestion: Remove = addition text on WPD-6 and WAA-7.

 

6. WPD-1. Generally we have tried to = avoid having multiple 2119 keywords in one

   requirement. Make PD-exclude a separate = requirement.

   Suggestion: Split = requirement in two.

 

7. WPD-4. = I disagree with this requirement. It is also hard to test, and = becomes

   meaningless, given that = a CPE must do PD even if M=3D0, O=3D0.

   Suggestion: revert back to = RFC6204:WPD-4

_______________________________________________

v6ops mailing list

v6ops@ietf.org

https://www.ietf.org= /mailman/listinfo/v6ops

------_=_NextPart_001_01CD0304.5AA6ABD8-- From shemant@cisco.com Thu Mar 15 16:44:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 487DA21E801B for ; Thu, 15 Mar 2012 16:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.04 X-Spam-Level: X-Spam-Status: No, score=-10.04 tagged_above=-999 required=5 tests=[AWL=0.558, 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 qVIGqv6y1NGB for ; Thu, 15 Mar 2012 16:44:58 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 408C621E800F for ; Thu, 15 Mar 2012 16:44:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=9856; q=dns/txt; s=iport; t=1331855098; x=1333064698; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=9HkEN9Cgkp0N0djiY9IhTp6MaQTMwzo4NxH46xjEQPw=; b=LLQlnRMF2z+oefeK/sAikkWbYd40QEI6G5BFGcZe6/IJ78AGKq6YO8PE SVUiH3QnXJMt/pGmevKaeUpzmgeNix8pbbtIRvfBi/lT+XfvKpjOvg0Tq zYJLmtRwLdo6NOdAElqsrCxM3bCvoFqAp5006qP1PHYhHHOxMIY0EhQyF o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAOp9Yk+tJV2Z/2dsb2JhbABCgk6zaYEHggkBAQEEEgEJEQNJDAQCAQgQAQQBAQsGFwEGAUUIAQgBAQQTCBqHaJ14lyGQJGMEiFebSYFogwQ X-IronPort-AV: E=Sophos;i="4.73,594,1325462400"; d="scan'208,217";a="66899267" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-7.cisco.com with ESMTP; 15 Mar 2012 23:44:57 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2FNivbn004065; Thu, 15 Mar 2012 23:44:57 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Mar 2012 18:44:57 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD0305.A131D1B8" Date: Thu, 15 Mar 2012 18:44:56 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1F3E@XMB-RCD-109.cisco.com> In-Reply-To: <201203152259.q2FMxnLg090123@givry.fdupont.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) Thread-Index: Ac0C/2LC9LaPD/LkS0KmHSNX5HiexQABQ//Q References: Your message of Wed, 14 Mar 2012 14:42:16 EST. <5B6B2B64C9FE2A489045EEEADDAFF2C3042FEA7C@XMB-RCD-109.cisco.com> <201203152259.q2FMxnLg090123@givry.fdupont.fr> From: "Hemant Singh (shemant)" To: X-OriginalArrivalTime: 15 Mar 2012 23:44:57.0925 (UTC) FILETIME=[A1490750:01CD0305] Cc: v6ops@ietf.org, Alain Durand , "Dan Wang \(danwan\)" , Dave Thaler Subject: Re: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 23:44:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD0305.A131D1B8 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Francis =20 -----Original Message----- From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]=20 Sent: Thursday, March 15, 2012 7:00 PM To: Hemant Singh (shemant) Cc: v6ops@ietf.org; Alain Durand; Dan Wang (danwan); Dave Thaler Subject: Re: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC)=20 =20 =20 >=3D> as it is in a SHOULD body you can't keep it so loose. =20 Could you please provide tighter text? =20 =20 >=3D> I can't see where this level of details will go (*), IMHO if you >want to keep a SHOULD for PCP (and I am strongly opposed to this) you >need to cite the base spec, the ds-lite application and the server >discovery documents. =20 Pcp-base is cited. Please point us to documents for ds-lite application and the server discovery. Since you had trouble reading the new PCP text because the text was combined with review comments, I have shown the new text for PCP in rfc6204bis below. Please review.=20 =20 =20 The WAN interface of the CE router SHOULD support a PCP client as specified in [I-D.ietf-pcp-base] for use by applications on the CE Router. This document takes no position on whether such functionality is enabled by default or mechanisms by which users would configure the functionality. =20 The PCP client SHOULD follow the procedure specified in Section 8.1 of [I-D.ietf-pcp-base] to discover its PCP server. In DS-Lite context, if PCP messages are exchanged using native IPv6 (i.e., IPv4-in-IPv6 is not used) and no PCP server is configured, the PCP client MUST use the address of the AFTR as its PCP server. =20 Handling PCP requests from PCP clients in the LAN side of the CE Router is out of scope. =20 Thanks much for the review. =20 Hemant =20 ------_=_NextPart_001_01CD0305.A131D1B8 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Francis

 

-----Original Message-----
From: = Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]
Sent: = Thursday, March 15, 2012 7:00 PM
To: Hemant Singh (shemant)
Cc: = v6ops@ietf.org; Alain Durand; Dan Wang (danwan); Dave Thaler
Subject: = Re: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) =

 

 

>=3D> as it is in a SHOULD = body you can't keep it so loose.

 

Could you please provide = tighter text?

 

 

>=3D> I can't see where this = level of details will go (*), IMHO if you

>want = to keep a SHOULD for PCP (and I am strongly opposed to this) = you

>need to cite the base spec, the = ds-lite application and the server

>discovery documents.

 

Pcp-base is cited.  = Please point us to documents for ds-lite application and the server = discovery.  Since you had trouble reading the new PCP text because = the text was combined with review comments, I have shown the new text = for PCP in rfc6204bis below.   Please review. =

 

 

   The WAN interface of the CE router SHOULD = support a PCP client

   as = specified in [I-D.ietf-pcp-base] for use by applications on the = CE

   = Router.  This document takes no position on whether = such

   = functionality is enabled by default or mechanisms by which = users

   would = configure the functionality.

 

   The PCP client SHOULD follow the = procedure specified in Section

   8.1 of [I-D.ietf-pcp-base] to discover = its PCP server.  In DS-Lite

   context, if PCP messages are exchanged = using native IPv6 (i.e.,

   IPv4-in-IPv6 is not used) and no PCP = server is configured, the PCP

   client MUST use the address of the AFTR = as its PCP server.

 

   Handling PCP requests from PCP clients in = the LAN side of the CE

   Router is out of = scope.

 

Thanks much for the review.

 

Hemant

 

------_=_NextPart_001_01CD0305.A131D1B8-- From fred@cisco.com Thu Mar 15 17:05:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB0321E804C for ; Thu, 15 Mar 2012 17:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.01 X-Spam-Level: X-Spam-Status: No, score=-109.01 tagged_above=-999 required=5 tests=[AWL=0.989, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 mO+nM-HEtj22 for ; Thu, 15 Mar 2012 17:05:59 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4202921E8045 for ; Thu, 15 Mar 2012 17:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=606; q=dns/txt; s=iport; t=1331856359; x=1333065959; h=from:subject:date:message-id:to:mime-version: content-transfer-encoding; bh=SurVgyD9ahjWHsOBFkW60Z1ey7NYvQZkoM1R4qDmpn4=; b=k3pjKvYNGFHXCZVaLJPYZzjChHMyARXuSOYYDwkiWzvzKbVBG1FeOo2L C/9rlMbzh3Bnd0E09MipUnbdd9NafoOJ1WDnMRgjk0GZaRm5lDJE3qipf xsBUwTnV0fPf6vM8bszspctWFu6Dft5FdaYrAQ7MwrVlWtEc+RGn0vbiS o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAL6CYk+rRDoH/2dsb2JhbABCti6BB4IiASeBfScOh2cMmUCBJ58IkCRjBIhXjQqFbIhTgWiDBg X-IronPort-AV: E=Sophos;i="4.73,593,1325462400"; d="scan'208";a="33225686" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 16 Mar 2012 00:05:58 +0000 Received: from Freds-Computer.local (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2G05di9017806 for ; Fri, 16 Mar 2012 00:05:58 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Thu, 15 Mar 2012 17:05:58 -0700 X-PGP-Universal: processed; by Freds-Computer.local on Thu, 15 Mar 2012 17:05:58 -0700 From: Fred Baker Date: Thu, 15 Mar 2012 17:04:46 -0700 Message-Id: To: v6ops v6ops WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: [v6ops] draft-ietf-intarea-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 00:05:59 -0000 http://tools.ietf.org/html/draft-ietf-intarea-ipv6-required "IPv6 Support Required for all IP-capable Nodes", Lee Howard, Chris Donley, Wesley George, Chris Donley, 8-Dec-11 George raised this question on v6ops a tad over a year ago, but I wonder = if there is a sense of the community that we should forward to intarea = now. Do me a favor if your would; read the draft and post a a comment on = it. Up/down is good; if you don't support it, saying why not so I can = summarize to the Internet Area folks would be helpful. Chris Donley must have had a really major part in this draft...= From shemant@cisco.com Thu Mar 15 17:38:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7F321E8026 for ; Thu, 15 Mar 2012 17:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.755 X-Spam-Level: X-Spam-Status: No, score=-9.755 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 pssdfogpB9NL for ; Thu, 15 Mar 2012 17:38:56 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 4D57D21E800F for ; Thu, 15 Mar 2012 17:38:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=10155; q=dns/txt; s=iport; t=1331858336; x=1333067936; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=3egMqhzzo5FWk3I2KHDywx9oZK3oQQMVwkwIMF8lBj0=; b=QHqjwPMsUW0yBmQwfyCBo722fny1ZNDT6NwnC8ZY85jGQkI/P+cQ/nBS F8aRE0EZNqbyBkyfxKnZJWAnkI+zk+kPo71H5SRUBEiqTJQUF8Etmujuy LWnw8ZP6yENRbNu2lr2wjR30ePyqcG2/ybgFs2yDFqNOCx8LPbi4m3UAN I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAI6KYk+tJXG//2dsb2JhbABCgkWzaYEHggkBAQEEAQEBDwEJEQM+FwQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCAwHB4doC5pjnwiQJGMEiFebSYFogwQ X-IronPort-AV: E=Sophos;i="4.73,594,1325462400"; d="scan'208,217";a="66907419" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 16 Mar 2012 00:38:55 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2G0ct1M011259 for ; Fri, 16 Mar 2012 00:38:55 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Mar 2012 19:38:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD030D.2B0E21F8" Date: Thu, 15 Mar 2012 19:38:54 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1F64@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-intarea-ipv6-required Thread-Index: Ac0DCJf3A+CUkqBWQ/68AIHF90EVrgAAa8hA References: From: "Hemant Singh (shemant)" To: "Fred Baker (fred)" , "v6ops v6ops WG" X-OriginalArrivalTime: 16 Mar 2012 00:38:55.0656 (UTC) FILETIME=[2B1F9280:01CD030D] Subject: Re: [v6ops] draft-ietf-intarea-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 00:38:58 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD030D.2B0E21F8 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Snipped from the document is the text below that I have a comment on. =20 [While transition technologies and other means to extend the lifespan of IPv4 do exist, nearly all of them come with tradeoffs that prevent them from being optimal long-term solutions when compared with deployment of IP version 6 (IPv6) as a means to allow continued growth on the Internet.] =20 Some folks will have an exactly opposite view from what is said above. IPv4 may exist for a long time and thus IPv6 hosts will need to communicate with IPv4 hosts and one will need transition mechanism and the deployment is still optimal. Thus the whole text above can be removed or the text will thrash for discussion. =20 Further, the documents cites RFC 1812 but the title of RFC 1812 clearly mentions "IP version 4 Routers". So isn't RFC 1812 disqualified to be in this document that is trying to find RFCs that have IP specific text that needs qualification by v4 or v6? That leaves only one RFC in RFC 1122 to cite in the document. It would be good to collect more RFCs to list. Lastly, for IPv6 the IETF wrote the ipv6 node reqs RFC which is the goto document for IPv6. From the IPv6 node reqs document one reaches all IPv6 specifications and then one does not go to any IPv4 IETF specification. If one does, then some new features have to get into the ipv6 node reqs document.=20 =20 Most of the text in the third paragraph of the Introduction section is not much use. It works much better to go directly to each device vendor and request strongly for IPv6 support including any public shame in the IETF. There is enough public-domain free IPv6 code around that most devices could start with. I'd recommend some of that code for specific devices. That's how stuff gets done.=20 =20 Regards, =20 Hemant =20 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred) Sent: Thursday, March 15, 2012 8:05 PM To: v6ops v6ops WG Subject: [v6ops] draft-ietf-intarea-ipv6-required =20 http://tools.ietf.org/html/draft-ietf-intarea-ipv6-required "IPv6 Support Required for all IP-capable Nodes", Lee Howard, Chris Donley, Wesley George, Chris Donley, 8-Dec-11 =20 George raised this question on v6ops a tad over a year ago, but I wonder if there is a sense of the community that we should forward to intarea now. Do me a favor if your would; read the draft and post a a comment on it. Up/down is good; if you don't support it, saying why not so I can summarize to the Internet Area folks would be helpful. =20 Chris Donley must have had a really major part in this draft... _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ------_=_NextPart_001_01CD030D.2B0E21F8 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Snipped from the document is the = text below that I have a comment on.

 

[While transition technologies and = other means to extend the lifespan

of IPv4 = do exist, nearly all of them come with tradeoffs that = prevent

them from being optimal long-term = solutions when compared with

= deployment of IP version 6 (IPv6) as a means to allow = continued

growth on the = Internet.]

 

Some folks will have an exactly = opposite view from what is said above.  IPv4 may exist for a long = time and thus IPv6 hosts will need to communicate with IPv4 hosts and = one will need transition mechanism and the deployment is still = optimal.  Thus the whole text above can be removed or the text will = thrash for discussion.

 

Further, the documents cites RFC = 1812 but the title of RFC 1812 clearly mentions “IP version 4 = Routers”.  So isn’t RFC 1812 disqualified to be in this = document that is trying to find RFCs that have IP specific text that = needs qualification by v4 or v6?  That leaves only one RFC in RFC = 1122 to cite in the document.  It would be good to collect more = RFCs to list.  Lastly, for IPv6 the IETF wrote the ipv6 node reqs = RFC which is the goto document for IPv6.  From the IPv6 node reqs = document one reaches all IPv6 specifications and then one does not go to = any IPv4 IETF specification.  If one does, then some new features = have to get into the ipv6 node reqs document.

 

Most of the text in the third = paragraph of the Introduction section is not much use.  It works = much better to go directly to each device vendor and request strongly = for IPv6 support including any public shame in the IETF.  There is = enough public-domain free IPv6 code around that most devices could start = with. I’d recommend some of that code for specific devices.  = That’s how stuff gets done.

 

Regards,

 

Hemant

 

-----Original Message-----
From: = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred = Baker (fred)
Sent: Thursday, March 15, 2012 8:05 PM
To: v6ops = v6ops WG
Subject: [v6ops] = draft-ietf-intarea-ipv6-required

 

http://tools.ietf.org/html/draft-ietf-intarea-ipv6-r= equired

  "IPv6 Support = Required for all IP-capable Nodes", Lee Howard, = Chris

  Donley, Wesley = George, Chris Donley, 8-Dec-11

 

George = raised this question on v6ops a tad over a year ago, but I wonder if = there is a sense of the community that we should forward to intarea now. = Do me a favor if your would; read the draft and post a a comment on it. = Up/down is good; if you don't support it, saying why not so I can = summarize to the Internet Area folks would be helpful.

 

Chris = Donley must have had a really major part in this = draft...

_______________________________________________=

v6ops mailing list

v6ops@ietf.org

https://www.ietf.org/mailman/listinfo/v6ops

------_=_NextPart_001_01CD030D.2B0E21F8-- From brian.e.carpenter@gmail.com Thu Mar 15 17:49:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9706C21E800F for ; Thu, 15 Mar 2012 17:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.203 X-Spam-Level: X-Spam-Status: No, score=-103.203 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, 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 8JCme4mWbwWN for ; Thu, 15 Mar 2012 17:49:37 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id AAFFE21E8059 for ; Thu, 15 Mar 2012 17:49:36 -0700 (PDT) Received: by eeke51 with SMTP id e51so2115872eek.31 for ; Thu, 15 Mar 2012 17:49:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4ml7ltD1WnUuwCzllXf9UhiIJGBYfxzDhKSzVdg0Uow=; b=bNou/+YPBdEd3rgtpXOmXE+XYj4GXdXombchBGH6jUoHZNHwfaiZvLB2vv5K5RP3VJ Wj+/DaHZBycmLP5plgahvaSWVF0OgC6L7sOd/VVE9I0kQYX/oNGW3yQ1oPC6bhMgdQjV L85eJogRu2xaDPW43LuYc913Bz34OrcdaGalvfUYD/ft+KEueXZoG/CCqWMMQDaQkEaW QKrhdm+BFuOWx80BmBmL3H0KCYrh3oJDVmKbSMl641ke5jmNAj+aiENMShVtYJG6fFIc ch2oY4tvPaCMH1UchKksIs5Jo6fsU7uNMprLVWK2esT7ih7DURJgEBx42Ezqkr6aIDDx 7z2w== Received: by 10.213.36.8 with SMTP id r8mr42425ebd.112.1331858975764; Thu, 15 Mar 2012 17:49:35 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id r44sm12570870eef.2.2012.03.15.17.49.31 (version=SSLv3 cipher=OTHER); Thu, 15 Mar 2012 17:49:34 -0700 (PDT) Message-ID: <4F628E15.3060708@gmail.com> Date: Fri, 16 Mar 2012 13:49:25 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Hemant Singh (shemant)" References: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1F64@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1F64@XMB-RCD-109.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops v6ops WG Subject: Re: [v6ops] draft-ietf-intarea-ipv6-required X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 00:49:37 -0000 On 2012-03-16 13:38, Hemant Singh (shemant) wrote: > Snipped from the document is the text below that I have a comment on. > > [While transition technologies and other means to extend the lifespan > of IPv4 do exist, nearly all of them come with tradeoffs that prevent > them from being optimal long-term solutions when compared with > deployment of IP version 6 (IPv6) as a means to allow continued > growth on the Internet.] The problem is what it has been for many years - we should always say either 'coexistence' or 'interworking' to describe a technology; transition is not a technology. > Some folks will have an exactly opposite view from what is said above. > IPv4 may exist for a long time which implies coexistence technology > and thus IPv6 hosts will need to > communicate with IPv4 hosts which implies interworking technology. I think the text above could be revised to make this distinction and to observe that interworking technology inevitably has negative impact on users. Apart from that, I support the document. Brian and one will need transition mechanism and > the deployment is still optimal. Thus the whole text above can be > removed or the text will thrash for discussion. > > > > Further, the documents cites RFC 1812 but the title of RFC 1812 clearly > mentions "IP version 4 Routers". So isn't RFC 1812 disqualified to be > in this document that is trying to find RFCs that have IP specific text > that needs qualification by v4 or v6? That leaves only one RFC in RFC > 1122 to cite in the document. It would be good to collect more RFCs to > list. Lastly, for IPv6 the IETF wrote the ipv6 node reqs RFC which is > the goto document for IPv6. From the IPv6 node reqs document one > reaches all IPv6 specifications and then one does not go to any IPv4 > IETF specification. If one does, then some new features have to get > into the ipv6 node reqs document. > > > > Most of the text in the third paragraph of the Introduction section is > not much use. It works much better to go directly to each device vendor > and request strongly for IPv6 support including any public shame in the > IETF. There is enough public-domain free IPv6 code around that most > devices could start with. I'd recommend some of that code for specific > devices. That's how stuff gets done. > > > > Regards, > > > > Hemant > > > > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Fred Baker (fred) > Sent: Thursday, March 15, 2012 8:05 PM > To: v6ops v6ops WG > Subject: [v6ops] draft-ietf-intarea-ipv6-required > > > > http://tools.ietf.org/html/draft-ietf-intarea-ipv6-required > > "IPv6 Support Required for all IP-capable Nodes", Lee Howard, Chris > > Donley, Wesley George, Chris Donley, 8-Dec-11 > > > > George raised this question on v6ops a tad over a year ago, but I wonder > if there is a sense of the community that we should forward to intarea > now. Do me a favor if your would; read the draft and post a a comment on > it. Up/down is good; if you don't support it, saying why not so I can > summarize to the Internet Area folks would be helpful. > > > > Chris Donley must have had a really major part in this draft... > > _______________________________________________ > > v6ops mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From lorenzo@google.com Thu Mar 15 22:44:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D7921F869E for ; Thu, 15 Mar 2012 22:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.805 X-Spam-Level: X-Spam-Status: No, score=-102.805 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 FhvxsVlAK1+K for ; Thu, 15 Mar 2012 22:44:09 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id A9CA421F869F for ; Thu, 15 Mar 2012 22:44:09 -0700 (PDT) Received: by ghbg16 with SMTP id g16so4371148ghb.31 for ; Thu, 15 Mar 2012 22:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=gUAE1V6QouuPMjfRWcRGWsexWAXG3sOSd2A3EU6LOtc=; b=T9fi0s8HZTAOJnN8F+gWQGhEr1YWkoGXfOQtkTVXBQmjFsd+Z7enNzcJi+bl+Pfu2Z Md2a9o3awoje2MdLJx3Za2fGdhOGjLmCdDKtck4LLIWItvHj+FO43VfcF9F3Tb21dYx9 ic8RLg9EqcboS5hXxCqcReMT0n3+H9GJuYfKkD5MipnjK1FD9Eeh5JLO27HXh2fVtx7A 0pWIjN/Mft6+JF/PpPoPejju4GC4WI2i5ISMBRkY03B2yDKISzdf8nY2jHVkjPhUe6aA EJ+sQ+agGh7Ouorxs7tOlo97tUR1kgUTAJVd7pwJfPk+VyPZDvtQAGKwD2X2cMItTjpv GNSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=gUAE1V6QouuPMjfRWcRGWsexWAXG3sOSd2A3EU6LOtc=; b=ZS1kGRIV8iqAHYoB2Tf6PXV97YYq3D9HhJ2g6VmR0K6OZ9QHnkQ13Rhpb/YItV9OKd zMk5Ad4uDsvN3ZqFqq23KOU9fk2eI+ceoYFNozVpHiIBdJpK+zoV9GOeINfzXxq1DKHC d2Oc+egkoTIwwhoM/s23+nYFHfA3QdzYEkNeJ6stodqNbLF/+2rH+k86jf/9lj1slOkM 9H88l+w7A3PUqQ9qyk81PVl2iYZItvf2pURhTwTfasBd8Hjkahoj+D46VZQezB223m83 ocFw6Xa3EHeVTKQgrhEEbpYtU6KavKMiLGWzpv3HxHx1EaSPvhsxA9wgbdWmXQnF/zjp GrvA== Received: by 10.60.4.10 with SMTP id g10mr1393646oeg.18.1331876648814; Thu, 15 Mar 2012 22:44:08 -0700 (PDT) Received: by 10.60.4.10 with SMTP id g10mr1393633oeg.18.1331876648643; Thu, 15 Mar 2012 22:44:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.63.231 with HTTP; Thu, 15 Mar 2012 22:43:48 -0700 (PDT) In-Reply-To: References: <20120315113825.GA84425@Space.Net> From: Lorenzo Colitti Date: Fri, 16 Mar 2012 14:43:48 +0900 Message-ID: To: Wojciech Dec Content-Type: multipart/alternative; boundary=e89a8ff252da86ebe804bb55b233 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmSioBfkfrtabkHbfG4k4Z9zz+UMcQnsBiUs3Fdi+i/OyskH0hM3BzT1PlVBlukH/4HwQnk2e0V0M3TpT2YHDr0ZJRMBfuYbE4wCCalARLX8TF7MkVNPqRV0WlqzbH9DSte1DxZ Cc: v6ops@ietf.org Subject: Re: [v6ops] Nomative language in draft-ietf-v6ops-464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 05:44:10 -0000 --e89a8ff252da86ebe804bb55b233 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 16, 2012 at 03:40, Wojciech Dec wrote: > The point is that NAT64 allows other configurations while your "document" > somehow insist on that /96 hard rule. Modify the text to saying that this > is what you used/configured in your deployment, why you found it useful > perhaps, and we'd be settled on this point. > Where does the draft insist that a /96 should be used? Are you talking about the IPv6 address format in section 6.1 or the text in section 6.5 that says "CLAT may take ownership of a /96 from an attached interface's /64"? --e89a8ff252da86ebe804bb55b233 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 16, 2012 at 03:40, Wojciech Dec <wdec.ietf@gmail.co= m> wrote:
The point is that NAT64 allows other config= urations while your "document" somehow insist on that /96 hard ru= le. Modify the text to saying that this is what you used/configured in your= deployment, why you found it useful perhaps, and we'd be settled on th= is point.

Where does the draft insi= st that a /96 should be used? Are you talking about the IPv6 address format= in section 6.1 or the text in section 6.5 that says "CLAT may take ow= nership of a /96 from=A0an attached interface's /64"?
--e89a8ff252da86ebe804bb55b233-- From tjc@ecs.soton.ac.uk Fri Mar 16 00:05:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5699E21F86F5 for ; Fri, 16 Mar 2012 00:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 KlGF7qJk37Gr for ; Fri, 16 Mar 2012 00:05:43 -0700 (PDT) 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 2BF6B21F86F8 for ; Fri, 16 Mar 2012 00:05:42 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q2G75T5t010028; Fri, 16 Mar 2012 07:05:29 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q2G75T5t010028 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1331881530; bh=dFrls/hASSOYexjVeZRQLq3cCoY=; h=References:In-Reply-To:Mime-Version:Cc:From:Subject:Date:To; b=axDXQkByPhW+rEVy+zNyxdicB78MG09rhGxWbVw6f1dldHAOXPAZbII8ZmvpYJtT4 3/XYoYtLj4jeysOnERdndIHOZcIBiMU5IuFkdRoZq6L5f9Ud5LqrLQdwCL9byen2EO 2E3jHAJrXH2aAvKR18gHNY64fggGhDdCud5n+Yw4= 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 id o2F75Y0543701061e8 ret-id none; Fri, 16 Mar 2012 07:05:30 +0000 Received: from [192.168.1.104] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q2G747E7029513 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 16 Mar 2012 07:04:07 GMT References: <201203152259.q2FMxnLg090123@givry.fdupont.fr> <32FD7D56-56B2-43F2-BC23-5971BAAD8C1B@ecs.soton.ac.uk> In-Reply-To: <201203152259.q2FMxnLg090123@givry.fdupont.fr> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-ID: X-Mailer: iPad Mail (9A405) From: Tim Chown Date: Fri, 16 Mar 2012 07:03:56 +0000 To: Francis Dupont X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o2F75Y054370106100; tid=o2F75Y0543701061e8; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=6:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q2G75T5t010028 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Cc: "v6ops@ietf.org" , Alain Durand , "Dan Wang \(danwan\)" , Dave Thaler Subject: Re: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 07:05:44 -0000 On 15 Mar 2012, at 22:59, Francis Dupont wrote: > In your previous mail you wrote: >=20 >> This is some change that Med has asked to make to the PCP text in >> rfc6204bis. Please provide comments. Cc to some PCP and DS-Lite >> individuals as well. >=20 > =3D> I have still a concern about a recommendation for PCP when we need > only the functionality, PCP is only one of the protocols which can > provide it. This is the current position in the homenet architecture text, i.e. if "Simp= le Security" is in use then a signalling protocol is needed, but as yet no s= pecific mechanism is recommended.=20 There is likely to be some discussion of this in Paris. Tim= From mohamed.boucadair@orange.com Fri Mar 16 00:24:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E9621F85B8 for ; Fri, 16 Mar 2012 00:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.173 X-Spam-Level: X-Spam-Status: No, score=-2.173 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 bl6f6S5icHGs for ; Fri, 16 Mar 2012 00:24:43 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 04CD921F85B5 for ; Fri, 16 Mar 2012 00:24:42 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 9D6DA2DC4EE; Fri, 16 Mar 2012 08:24:41 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 7FE4C23806C; Fri, 16 Mar 2012 08:24:41 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Fri, 16 Mar 2012 08:24:41 +0100 From: To: Francis Dupont , "Hemant Singh (shemant)" Date: Fri, 16 Mar 2012 08:24:40 +0100 Thread-Topic: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) Thread-Index: Ac0C/12WhSJ00IX9QQKGMOpqC41mtwARUGSQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E285577F1@PUEXCB1B.nanterre.francetelecom.fr> References: Your message of Wed, 14 Mar 2012 14:42:16 EST. <5B6B2B64C9FE2A489045EEEADDAFF2C3042FEA7C@XMB-RCD-109.cisco.com> <201203152259.q2FMxnLg090123@givry.fdupont.fr> In-Reply-To: <201203152259.q2FMxnLg090123@givry.fdupont.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.16.63319 Cc: "v6ops@ietf.org" , Alain Durand , "Dan Wang \(danwan\)" , Dave Thaler Subject: Re: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 07:24:43 -0000 Hi Francis, The current text specifies the client counterpart of REQ#10 http://tools.ie= tf.org/html/draft-ietf-behave-lsn-requirements-05. Which other protocols you want to include? Cheers, Med >-----Message d'origine----- >De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De=20 >la part de Francis Dupont >Envoy=E9 : vendredi 16 mars 2012 00:00 >=C0 : Hemant Singh (shemant) >Cc : v6ops@ietf.org; Alain Durand; Dan Wang (danwan); Dave Thaler >Objet : Re: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) > > In your previous mail you wrote: > >> This is some change that Med has asked to make to the PCP text in >> rfc6204bis. Please provide comments. Cc to some PCP and DS-Lite >> individuals as well. > >=3D> I have still a concern about a recommendation for PCP when we need >only the functionality, PCP is only one of the protocols which can >provide it. From v6ops@globis.net Fri Mar 16 01:10:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A77921F871A for ; Fri, 16 Mar 2012 01:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.263 X-Spam-Level: X-Spam-Status: No, score=-2.263 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 gagLvOImJAcj for ; Fri, 16 Mar 2012 01:10:37 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 8E14C21F8716 for ; Fri, 16 Mar 2012 01:10:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 1031187008A; Fri, 16 Mar 2012 09:10:35 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKUp859DnPvl; Fri, 16 Mar 2012 09:10:30 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 50A1B870064; Fri, 16 Mar 2012 09:10:30 +0100 (CET) Message-ID: <4F62F576.3070209@globis.net> Date: Fri, 16 Mar 2012 09:10:30 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: "Hemant Singh (shemant)" References: <867F4B6A1672E541A94676D556793ACD0EB995043C@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3042FEBDB@XMB-RCD-109.cisco.com> <4F61E53D.4050904@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1C75@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1C75@XMB-RCD-109.cisco.com> Content-Type: multipart/alternative; boundary="------------090702000403010500040603" Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 08:10:38 -0000 This is a multi-part message in MIME format. --------------090702000403010500040603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Requirement L2 requires assignment of a /64 to each LAN interface and is a MUST. Those addresses may be obtained by WPD-1 (again DHCPv6 PD support is a MUST). The "too small" error of DHCPv6 PD is an issue that can completely "brick" the CE router to use your own term. That to me is an important issue. As a consumer, I could buy a fully compliant RFC6204bis-07 router and connect it to a fully compliant RFC6204bis-07 Service Provider and it will not function at all. I find that very odd. BCP 157 (RFC 6177) says "it should be easy for an end site to obtain address space to number multiple subnets (i.e., a block larger than a single /64) and to support reasonable growth projections over long time periods (e.g., a decade or more)." You are correct that the BCP doesn't say fixed /48 or /56 any more, nor define "long time periods". But a decade is very much longer than any PD timers I know of. And allocating a single /64 per end site is clearly not Best Current Practice, as that does not support numbering of multiple subnets on the end site. Following IMVHO: We go into great detail on address assignment in 6204bis, but miss the obvious statement that a CE device needs to be delegated enough addresses so that it can assign a /64 per LAN in order for 6204bis to work as designed. v6ops WG shouldn't encourage SP's who ignore BCP (by assigning a single /64 to an end site) to continue such practices without a very good reason, and that reason has not been presented. I think RFC6177 is required for 6204bis to work as designed, and is thus normative. Suggestion: RFC6204bis refer to BCP 157 (RFC6177) as a normative reference. regards, RayH Hemant Singh (shemant) wrote: > > Ray, > > *From:* Ray Hunter [mailto:v6ops@globis.net] > *Sent:* Thursday, March 15, 2012 8:49 AM > *To:* Hemant Singh (shemant) > *Cc:* Wuyts Carl; v6ops@ietf.org > *Subject:* Re: Re: [v6ops] RFC6204bis-07 > > >Hermant, IMHO the root cause of the prefix size "too small" problem is > that the operator of the DHCPv6 PD delegating router has not adhered > to BCP >RFC6177 Section 5 Summary. > > Not quite. Carl just reported he their CE routers deployed with a > /64. RFC 6177 does not recommend a size but does relax the old /48 > with a /56 recommendation. > > > >WPD-3 of RFC6204bis suggests logging a system management error, but I > don't see anything in RFC6204bis or RFC3633 or RFC3315 that would > allow a CE >manufacturer/end user who is operating the requesting > router to be able to signal back to the delegating router (where the > root cause of the >problem lies) that the prefix was too small (either > via a DHCPv6 PD status code such as "PREFIX_TOO_SMALL", or any other > standard logging >mechanism). > > That is why the CE router has to log an error. How the CE does that > is out of scope of the document. Some CE router can be a > sophisticated SOHO router that supports syslog error messages while > another cheap retail router uses an LED to signal the error. Or use a > different color with an existing LED. Also if the CE router supports > a web UI, the UI also displays the error. > > > >Local system management logging would not seem to address the root > cause, and would seem to potentially leave the end user/ CE > manufacturer in no >man's land. > > With the error, the user can at least call the SP to report the > issue. Sure, calling the SP is not a good option, but what can the > CE do if the protocols do not support reporting such a failure. At > this point I am not sure if the protocols can even do anything about > the situation because one does not know when the user provisions > his/her last subnet that goes one over the PD allocation which could > be days after the PD was acquired with DHCPv6. > > > >To address the root cause, I'd like to propose RFC6024bis refer to > RFC6177 as a normative reference. > > But Carl already has a use case of a /64. I am not for or against > adding RFC 6177. Others in the WG can comment. > > > Regards, > > Hemant > --------------090702000403010500040603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Requirement L2 requires assignment of a /64 to each LAN interface and is a MUST. Those addresses may be obtained by WPD-1 (again DHCPv6 PD support is a MUST). The "too small" error of DHCPv6 PD is an issue that can completely "brick" the CE router to use your own term. That to me is an important issue. As a consumer, I could buy a fully compliant RFC6204bis-07 router and connect it to a fully compliant RFC6204bis-07 Service Provider and it will not function at all. I find that very odd.

BCP 157 (RFC 6177) says "it should be easy for an end site to obtain address space to
        number multiple subnets (i.e., a block larger than a single /64)
        and to support reasonable growth projections over long time
        periods (e.g., a decade or more)."

You are correct that the BCP doesn't say fixed /48 or /56 any more, nor define "long time periods".

But a decade is very much longer than any PD timers I know of.

And allocating a single /64 per end site is clearly not Best Current Practice, as that does not support numbering of multiple subnets on the end site.

Following IMVHO: We go into great detail on address assignment in 6204bis, but miss the obvious statement that a CE device needs to be delegated enough addresses so that it can assign a /64 per LAN in order for 6204bis to work as designed. v6ops WG shouldn't encourage SP's who ignore BCP (by assigning a single /64 to an end site) to continue such practices without a very good reason, and that reason has not been presented. I think RFC6177 is required for 6204bis to work as designed, and is thus normative.

Suggestion: RFC6204bis refer to BCP 157 (RFC6177) as a normative reference.

regards,
RayH

Hemant Singh (shemant) wrote:

Ray,

 

From: Ray Hunter [mailto:v6ops@globis.net]
Sent: Thursday, March 15, 2012 8:49 AM
To: Hemant Singh (shemant)
Cc: Wuyts Carl; v6ops@ietf.org
Subject: Re: Re: [v6ops] RFC6204bis-07

 

>Hermant, IMHO the root cause of the prefix size "too small" problem is that the operator of the DHCPv6 PD delegating router has not adhered to BCP >RFC6177 Section 5 Summary.

Not  quite.  Carl just reported he their CE routers deployed with a /64.    RFC 6177 does not recommend a size but does relax the old /48 with a /56 recommendation.


>WPD-3 of RFC6204bis suggests logging a system management error, but I don't see anything in RFC6204bis or RFC3633 or RFC3315 that would allow a CE >manufacturer/end user who is operating the requesting router to be able to signal back to the delegating router (where the root cause of the >problem lies) that the prefix was too small (either via a DHCPv6 PD status code such as "PREFIX_TOO_SMALL", or any other standard logging >mechanism).

That is why the CE router has to log an error.  How the CE does that is out of scope of the document.   Some CE router can be a sophisticated SOHO router that supports syslog error messages while another cheap retail router uses an LED to signal the error.  Or use a different color with an existing LED.   Also if the CE router supports a web UI, the UI also displays the error.


>Local system management logging would not seem to address the root cause, and would seem to potentially leave the end user/ CE manufacturer in no >man's land.

With the error, the user can at least call the SP to report the issue.   Sure, calling the SP is not a good option, but what can the CE do if the protocols do not support reporting such a failure.    At this point I am not sure if the protocols can even do anything about the situation because one does not know when the user provisions his/her last subnet that goes one over the PD allocation which could be days after the PD was acquired with DHCPv6. 


>To address the root cause, I'd like to propose RFC6024bis refer to RFC6177 as a normative reference.

But Carl already has a use case of a /64.   I am not for or against adding RFC 6177.   Others in the WG can comment.


Regards,

 

Hemant


--------------090702000403010500040603-- From shemant@cisco.com Fri Mar 16 05:01:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC12D21F869C for ; Fri, 16 Mar 2012 05:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.775 X-Spam-Level: X-Spam-Status: No, score=-9.775 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 sydrhUelUHYw for ; Fri, 16 Mar 2012 05:01:23 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id D02D821F8692 for ; Fri, 16 Mar 2012 05:01:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=6752; q=dns/txt; s=iport; t=1331899282; x=1333108882; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=MrFeOGuseBXGQjhKFiGj15xIyhkb//4XmYqFQP9/Ptc=; b=lfovtr/9ItsadVeEUbj5kMMcktmoxDZEVX841v9ff4drnNYk7W7jGTOW HIx5gEjpKA25lpE8GKzWyAxwYOd6h52jgthZbSwudANIlo3Hkjd6k+kTf iqv4Uqz7FRcnRHHgXEUpV5IkBtYxQ83uhVLP6An1AYsYK36YZMO1DKcHy I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAKEqY0+tJXG9/2dsb2JhbABCgk+zcIEHggkBAQEEEgEJEQNJEAIBCA4DBAEBCwYXAQYBRQkIAQEEEwgah2ieZpcvkBpjBIhWm0+BaIME X-IronPort-AV: E=Sophos;i="4.73,597,1325462400"; d="scan'208,217";a="67030355" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 16 Mar 2012 12:01:22 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2GC1MJj003274; Fri, 16 Mar 2012 12:01:22 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Mar 2012 07:01:22 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD036C.81026058" Date: Fri, 16 Mar 2012 07:01:21 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1FB5@XMB-RCD-109.cisco.com> In-Reply-To: <4F62F576.3070209@globis.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] RFC6204bis-07 Thread-Index: Ac0DTEXYtgpns+9TQ0egqJcdD0unfwAHFmLQ References: <867F4B6A1672E541A94676D556793ACD0EB995043C@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3042FEBDB@XMB-RCD-109.cisco.com> <4F61E53D.4050904@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1C75@XMB-RCD-109.cisco.com> <4F62F576.3070209@globis.net> From: "Hemant Singh (shemant)" To: "Ray Hunter" X-OriginalArrivalTime: 16 Mar 2012 12:01:22.0085 (UTC) FILETIME=[8118CD50:01CD036C] Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 12:01:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD036C.81026058 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Ray, =20 From: Ray Hunter [mailto:v6ops@globis.net]=20 Sent: Friday, March 16, 2012 4:11 AM To: Hemant Singh (shemant) Cc: Wuyts Carl; v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-07 =20 >Following IMVHO: We go into great detail on address assignment in 6204bis, but miss the obvious statement that a CE device needs to be delegated enough >addresses so that it can assign a /64 per LAN in order for 6204bis to work as designed. v6ops WG shouldn't encourage SP's who ignore BCP (by assigning a >single /64 to an end site) to continue such practices without a very good >reason, and that reason has not been presented. I think RFC6177 is required >for 6204bis to work as designed, and is thus normative. OK. I agree using a /64 in the LAN is something the IETF should discourage. =20 >Suggestion: RFC6204bis refer to BCP 157 (RFC6177) as a normative reference. Taken. Will add the normative reference. Thanks much, =20 Hemant ------_=_NextPart_001_01CD036C.81026058 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Ray,

 

From: = Ray Hunter [mailto:v6ops@globis.net] =
Sent: Friday, March 16, 2012 4:11 AM
To: Hemant = Singh (shemant)
Cc: Wuyts Carl; v6ops@ietf.org
Subject: Re: = [v6ops] RFC6204bis-07

 


>Following IMVHO: We = go into great detail on address assignment in 6204bis, but miss the = obvious statement that a CE device needs to be delegated enough = >addresses so that it can assign a /64 per LAN in order for 6204bis = to work as designed. v6ops WG shouldn't encourage SP's who ignore BCP = (by assigning a >single /64 to an end site) to continue such = practices without a very good >reason, and that = reason has not been presented. I think RFC6177 is required >for = 6204bis to work as designed, and is thus normative.

OK.  I agree using a /64 in the LAN is = something the IETF should discourage. 


>Suggestion: RFC6204bis refer to BCP 157 (RFC6177) as a = normative reference.

Taken.  Will add the normative reference.

Thanks = much,

 

Hemant

------_=_NextPart_001_01CD036C.81026058-- From shemant@cisco.com Fri Mar 16 05:11:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3217D21F865C for ; Fri, 16 Mar 2012 05:11:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.081 X-Spam-Level: X-Spam-Status: No, score=-10.081 tagged_above=-999 required=5 tests=[AWL=0.517, 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 B5dLrOTGQ6uL for ; Fri, 16 Mar 2012 05:11:20 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 71E1421F865B for ; Fri, 16 Mar 2012 05:11:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=4407; q=dns/txt; s=iport; t=1331899880; x=1333109480; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=PdTs3lh2BeadnDFdShIru7OPWw8K2SF42/Pq6fd36+8=; b=Hbv2TQobIWh9IJUOACgCsxCuYLdKGHeqZbnuO3OTysad4ajPbb2NPUt8 YR28HfyqPCeTeI7u91sdWToJKh+iDsG/aASYjp3Ebv8MCs8m5gkkXapWA M4Th+XdQJRd6svpWycUEPaPA/XwOO6s2qfGdNqRdEcP0D253BJflsY0Md k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAP8sY0+tJV2b/2dsb2JhbABCgkazcIEHggkBAQEEEgEJEQNJEAIBCA4DBAEBCwYXAQYBRQkIAQEEEwgah2iad58VkBpjBIhWm0+BaIME X-IronPort-AV: E=Sophos;i="4.73,597,1325462400"; d="scan'208,217";a="67026032" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 16 Mar 2012 12:11:20 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2GCBJST009246; Fri, 16 Mar 2012 12:11:20 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Mar 2012 07:11:19 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD036D.E5435E78" Date: Fri, 16 Mar 2012 07:11:19 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1FB6@XMB-RCD-109.cisco.com> In-Reply-To: <4F62F576.3070209@globis.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] RFC6204bis-07 Thread-Index: Ac0DTEXYtgpns+9TQ0egqJcdD0unfwAIS7yA References: <867F4B6A1672E541A94676D556793ACD0EB995043C@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3042FEBDB@XMB-RCD-109.cisco.com> <4F61E53D.4050904@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1C75@XMB-RCD-109.cisco.com> <4F62F576.3070209@globis.net> From: "Hemant Singh (shemant)" To: "Ray Hunter" X-OriginalArrivalTime: 16 Mar 2012 12:11:19.0835 (UTC) FILETIME=[E56236B0:01CD036D] Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 12:11:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD036D.E5435E78 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable =20 From: Ray Hunter [mailto:v6ops@globis.net]=20 Sent: Friday, March 16, 2012 4:11 AM To: Hemant Singh (shemant) Cc: Wuyts Carl; v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-07 =20 >Suggestion: RFC6204bis refer to BCP 157 (RFC6177) as a normative reference. RFC 6177 seems like a good candidate to have made it to the ipv6 node reqs document in RFC 6434. After all, an SP delegating router/dhcpv6 server is configured for prefix allocation and the configuration of such nodes for a prefix can use guidance from RFC 6177. =20 Hemant ------_=_NextPart_001_01CD036D.E5435E78 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

 

From: Ray Hunter [mailto:v6ops@globis.net]
Sent: Friday, = March 16, 2012 4:11 AM
To: Hemant Singh = (shemant)
Cc: Wuyts Carl; v6ops@ietf.org
Subject: = Re: [v6ops] RFC6204bis-07

 


>Suggestion: RFC6204bis refer to BCP = 157 (RFC6177) as a normative reference.

RFC 6177 seems like a good candidate to have made = it to the ipv6 node reqs document in RFC 6434.  After all, an SP = delegating router/dhcpv6 server is configured for prefix allocation and = the configuration of such nodes for a prefix can use guidance from RFC = 6177.

 

Hemant

------_=_NextPart_001_01CD036D.E5435E78-- From shemant@cisco.com Fri Mar 16 06:48:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B91021F86A7 for ; Fri, 16 Mar 2012 06:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] 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 ou73taIDwXgj for ; Fri, 16 Mar 2012 06:48:29 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0D521F8621 for ; Fri, 16 Mar 2012 06:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=281243; q=dns/txt; s=iport; t=1331905707; x=1333115307; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=oNWGdIHbbGrpE+slMjGz20xWcrVBBSR5BtE0Nouo7YM=; b=WlD+SlW2ptNj273qCTpjyLSlHU6mhiJtCDJUN1kN1eteBycLUZRrtnwd fiqAmSL35vp5B4bnvBHXm18Bp7pgG3/obXfzTWcGjsBkmAVFqj3t1zXSy ZTsHYjw92St+quwjR6eDRR8kIApRJTxQNvtH105iuOlVjOB3wUdLbdjQY E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsEAAFEY0+tJXHB/2dsb2JhbAC3fw X-IronPort-AV: E=Sophos;i="4.73,598,1325462400"; d="scan'208,217";a="67002918" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 16 Mar 2012 13:48:26 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q2GDmQKG028885; Fri, 16 Mar 2012 13:48:26 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Mar 2012 08:48:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD037B.76263DF8" Date: Fri, 16 Mar 2012 08:48:23 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1FF3@XMB-RCD-109.cisco.com> In-Reply-To: <9B1C4EC1-50ED-436F-876A-1F2512BB54C9@employees.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6204bis WGLC Thread-Index: Acz96uXRwjprUWYLSC2XqBbkihlfsgFj7b8w References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> <9B1C4EC1-50ED-436F-876A-1F2512BB54C9@employees.org> From: "Hemant Singh (shemant)" To: =?iso-8859-1?Q?Ole_Tr=F8an?= , X-OriginalArrivalTime: 16 Mar 2012 13:48:26.0629 (UTC) FILETIME=[766C6B50:01CD037B] Cc: v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 13:48:29 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD037B.76263DF8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Folks, =20 Here is the delta between -07 that was sent out for LastCall and -08 = which has edits from review. Three minor items from Ole need closure = during this week. PCP needs closure between Med and Francis. Changes = from DanielR, RayH, and Ole have been incorporated.=20 =20 Thanks, =20 Hemant =20 < = draft-ietf-v6ops-6204bis-07.txt = =20 draft-ietf-v6ops-6204bis-08.txt = > = =20 =09 =09 =20 Network Working Group H. = Singh Network Working Group H. Singh =20 Internet-Draft W. = Beebee Internet-Draft W. Beebee =20 Obsoletes: 6204 (if approved) Cisco Systems, = Inc. Obsoletes: 6204 (if approved) Cisco Systems, Inc. =20 Intended status: Informational C. = Donley Intended status: Informational C. Donley =20 =20 =09 Expires: September 9, 2012 = CableLabs Expires: September 17, 2012 CableLabs =20 B. = Stark B. Stark =20 = AT&T AT&T =20 O. Troan, = Ed. O. Troan, Ed. =20 Cisco Systems, = Inc. Cisco Systems, Inc. =20 =20 =09 March 8, = 2012 March 16, 2012 =20 =20 Basic Requirements for IPv6 Customer Edge Routers Basic Requirements for IPv6 Customer Edge Routers =20 =20 =09 draft-ietf-v6ops-6204bis-07 draft-ietf-v6ops-6204bis-08 =20 =20 Abstract Abstract =20 =20 This document specifies requirements for an IPv6 Customer Edge (CE) This document specifies requirements for an IPv6 Customer Edge (CE) =20 router. Specifically, the current version of this document focuses router. Specifically, the current version of this document focuses =20 on the basic provisioning of an IPv6 CE router and the provisioning on the basic provisioning of an IPv6 CE router and the provisioning =20 of IPv6 hosts attached to it. The document also covers IP = transition of IPv6 hosts attached to it. The document also covers IP transition =20 technologies. Two transition technologies in RFC 5969's 6rd and RFC technologies. Two transition technologies in RFC 5969's 6rd and RFC =20 6333's DS-Lite. are covered in the document. The document obsoletes 6333's DS-Lite. are covered in the document. The document obsoletes =20 RFC 6204, if approved. RFC 6204, if approved. =20 =20 =20 skipping to change at page 1, line=20 42 =20 skipping to change at page 1, line=20 42 =20 Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering =20 Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute =20 working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet- =20 Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/. =20 =20 Internet-Drafts are draft documents valid for a maximum of six = months Internet-Drafts are draft documents valid for a maximum of six months =20 and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any =20 time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference =20 material or to cite them other than as "work in progress." material or to cite them other than as "work in progress." =20 =20 =20 =09 This Internet-Draft will expire on September 9, 2012. This Internet-Draft will expire on September 17, 2012. =20 =20 Copyright Notice Copyright Notice =20 =20 Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the =20 document authors. All rights reserved. document authors. All rights reserved. =20 =20 This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal =20 Provisions Relating to IETF Documents Provisions Relating to IETF Documents =20 (http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of =20 publication of this document. Please review these documents publication of this document. Please review these documents =20 =20 =20 skipping to change at page 3, line=20 28 =20 skipping to change at page 3, line=20 28 =20 of its LAN interfaces, and fetches other configuration information of its LAN interfaces, and fetches other configuration information =20 from the service provider network. Automatic provisioning of more from the service provider network. Automatic provisioning of more =20 complex topology than a single router with multiple LAN interfaces = is complex topology than a single router with multiple LAN interfaces is =20 out of scope for this document. out of scope for this document. =20 =20 See [RFC4779] for a discussion of options available for deploying See [RFC4779] for a discussion of options available for deploying =20 IPv6 in service provider access networks. IPv6 in service provider access networks. =20 =20 The document also covers IP transition technologies. Two transition The document also covers IP transition technologies. Two transition =20 technologies in 6rd [RFC5969] and DS-Lite [RFC6333] are covered in technologies in 6rd [RFC5969] and DS-Lite [RFC6333] are covered in =20 =20 =09 the document. At the time of writing this document these were the the document. =20 only two transition technologies available in RFC form to be = included =20 in this document. =20 =20 1.1. Requirements Language 1.1. Requirements Language =20 =20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", =20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this =20 document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119]. =20 =20 2. Terminology 2. Terminology =20 =20 End-User Network one or more links attached to the IPv6 CE End-User Network one or more links attached to the IPv6 CE =20 =20 =20 skipping to change at page 9, line=20 8 =20 skipping to change at page 9, line=20 8 =20 router MUST support IPv6 over PPP [RFC5072]. router MUST support IPv6 over PPP [RFC5072]. =20 =20 WLL-3: If the WAN interface supports PPP encapsulation, in a dual- WLL-3: If the WAN interface supports PPP encapsulation, in a dual- =20 stack environment with IPCP and IPV6CP running over one PPP stack environment with IPCP and IPV6CP running over one PPP =20 logical channel, the Network Control Protocols (NCP's) MUST logical channel, the Network Control Protocols (NCP's) MUST =20 be treated as independent of each other and start and be treated as independent of each other and start and =20 terminate independently. terminate independently. =20 =20 Address assignment requirements: Address assignment requirements: =20 =20 =20 =09 WAA-1: The IPv6 CE router MUST support Stateless Address WAA-1: The IPv6 CE router MUST support Stateless Address =20 Autoconfiguration (SLAAC) [RFC4862]. Autoconfiguration (SLAAC) [RFC4862]. =20 =20 =20 =09 WAA-2: The IPv6 CE router MUST follow the recommendations in = Section WAA-2: The IPv6 CE router MUST follow the recommendations in =20 4 of [RFC5942], and in particular the handling of the L flag Section 4 of [RFC5942], and in particular the handling of =20 in the Router Advertisement Prefix Information option. the L flag in the Router Advertisement Prefix Information =20 option. =20 =20 =20 =09 WAA-3: The IPv6 CE router MUST support DHCPv6 [RFC3315] client WAA-3: The IPv6 CE router MUST support DHCPv6 [RFC3315] client =20 behavior. behavior. =20 =20 =20 =09 WAA-4: The IPv6 CE router MUST be able to support the following WAA-4: The IPv6 CE router MUST be able to support the following =20 DHCPv6 options: IA_NA, Reconfigure Accept [RFC3315], and DHCPv6 options: IA_NA, Reconfigure Accept [RFC3315], and =20 DNS_SERVERS [RFC3646]. The IPv6 CE router SHOULD be able to DNS_SERVERS [RFC3646]. The IPv6 CE router SHOULD be able to =20 support the DNS Search List DNSSL option as specified in support the DNS Search List DNSSL option as specified in =20 [RFC3646]. [RFC3646]. =20 =20 =20 =09 WAA-5: The IPv6 CE router SHOULD support the DHCPv6 Simple Network WAA-5: The IPv6 CE router SHOULD implement the Simple Network Time =20 Time Protocol (SNTP) option [RFC4075] and the Information Protocol (SNTP) as specified in [RFC2030]. If the CE router =20 Refresh Time option [RFC4242]. implements SNTP, it requests the SNTP option [RFC4075] and =20 uses the received list of servers as primary time = reference, =20 unless explicitly configured otherwise. =20 =20 =20 =09 WAA-6: If the IPv6 CE router receives a Router Advertisement = message WAA-6: The IPv6 CE router SHOULD implement the Information Refresh =20 (described in [RFC4861]) with the M flag set to 1, the IPv6 Time option and associated client behavior as specified in =20 CE router MUST do DHCPv6 address assignment (request an = IA_NA [RFC4242]. =20 option). =20 =20 =20 =09 WAA-7: If the IPv6 CE router does not acquire global IPv6 WAA-7: If the IPv6 CE router receives a Router Advertisement =20 address(es) from either SLAAC or DHCPv6, then it MUST create message (described in [RFC4861]) with the M flag set to 1, =20 global IPv6 address(es) from its delegated prefix(es) and the IPv6 CE router MUST do DHCPv6 address assignment =20 configure those on one of its internal virtual network (request an IA_NA option). =20 interfaces, unless configured to require a global IPv6 =20 address on the WAN interface. =20 =20 =20 =09 WAA-8: The CE Router MUST support the DHCPv6 SOL_MAX_RT option WAA-8: If the IPv6 CE router does not acquire global IPv6 =20 [I-D.droms-dhc-dhcpv6-maxsolrt-update] in a received DHCPv6 address(es) from either SLAAC or DHCPv6, then it MUST create =20 Advertise or Reply message and set its internal SOL_MAX_RT global IPv6 address(es) from its delegated prefix(es) and =20 parameter to the value contained in the SOL_MAX_RT option. configure those on one of its internal virtual network =20 interfaces, unless configured to require a global IPv6 =20 address on the WAN interface. =20 =20 =20 =09 WAA-9: As a router, the IPv6 CE router MUST follow the weak host WAA-9: The CE Router MUST support the DHCPv6 SOL_MAX_RT option =20 (Weak ES) model [RFC1122]. When originating packets from an [I-D.droms-dhc-dhcpv6-maxsolrt-update] in a received DHCPv6 =20 interface, it will use a source address from another one of Advertise or Reply message and set its internal SOL_MAX_RT =20 its interfaces if the outgoing interface does not have an parameter to the value contained in the SOL_MAX_RT option. =20 address of suitable scope. =20 WAA-10: As a router, the IPv6 CE router MUST follow the weak host =20 (Weak ES) model [RFC1122]. When originating packets from = an =20 interface, it will use a source address from another one = of =20 its interfaces if the outgoing interface does not have an =20 address of suitable scope. =20 =20 Prefix delegation requirements: Prefix delegation requirements: =20 =20 WPD-1: The IPv6 CE router MUST support DHCPv6 prefix delegation WPD-1: The IPv6 CE router MUST support DHCPv6 prefix delegation =20 requesting router behavior as specified in [RFC3633] (IA_PD requesting router behavior as specified in [RFC3633] (IA_PD =20 =20 =09 option). The IPv6 CE Router SHOULD support the option). =20 = =20 =20 WPD-2: The IPv6 CE Router SHOULD support the =20 [I-D.ietf-dhc-pd-exclude] PD-Exclude option. [I-D.ietf-dhc-pd-exclude] PD-Exclude option. =20 =20 =20 =09 WPD-2: The IPv6 CE router MAY indicate as a hint to the delegating WPD-3: The IPv6 CE router MAY indicate as a hint to the delegating =20 router the size of the prefix it requires. If so, it MUST router the size of the prefix it requires. If so, it MUST =20 ask for a prefix large enough to assign one /64 for each of ask for a prefix large enough to assign one /64 for each of =20 its interfaces, rounded up to the nearest nibble, and SHOULD its interfaces, rounded up to the nearest nibble, and SHOULD =20 be configurable to ask for more. be configurable to ask for more. =20 =20 =20 =09 WPD-3: The IPv6 CE router MUST be prepared to accept a delegated WPD-4: The IPv6 CE router MUST be prepared to accept a delegated =20 prefix size different from what is given in the hint. If = the prefix size different from what is given in the hint. If the =20 delegated prefix is too small to address all of its delegated prefix is too small to address all of its =20 interfaces, the IPv6 CE router SHOULD log a system = management interfaces, the IPv6 CE router SHOULD log a system management =20 =20 =09 error. error. [RFC6177] covers the recommendations for service =20 providers for prefix allocation sizes. =20 =20 =20 =09 WPD-4: By default, the IPv6 CE router MUST initiate DHCPv6 prefix WPD-5: By default, the IPv6 CE router MUST initiate DHCPv6 prefix =20 delegation when either the M or O flags are set to 1 in a delegation when either the M or O flags are set to 1 in a =20 received Router Advertisement message. received Router Advertisement message. =20 =20 =20 =09 WPD-5: If the delegated prefix(es) are aggregate route(s) of WPD-6: If the delegated prefix(es) are aggregate route(s) of =20 multiple, more-specific routes, the IPv6 CE router MUST multiple, more-specific routes, the IPv6 CE router MUST =20 discard packets that match the aggregate route(s), but not discard packets that match the aggregate route(s), but not =20 any of the more-specific routes. In other words, the next any of the more-specific routes. In other words, the next =20 hop for the aggregate route(s) should be the null hop for the aggregate route(s) should be the null =20 destination. This is necessary to prevent forwarding loops destination. This is necessary to prevent forwarding loops =20 when some addresses covered by the aggregate are not when some addresses covered by the aggregate are not =20 reachable [RFC4632]. reachable [RFC4632]. =20 =20 (a) The IPv6 CE router SHOULD send an ICMPv6 Destination (a) The IPv6 CE router SHOULD send an ICMPv6 Destination =20 Unreachable message in accordance with Section 3.1 of Unreachable message in accordance with Section 3.1 of =20 [RFC4443] back to the source of the packet, if the [RFC4443] back to the source of the packet, if the =20 packet is to be dropped due to this rule. packet is to be dropped due to this rule. =20 =20 =20 =09 WPD-6: If the IPv6 CE router requests both an IA_NA and an IA_PD WPD-7: If the IPv6 CE router requests both an IA_NA and an IA_PD =20 option in DHCPv6, it MUST accept an IA_PD option in DHCPv6 option in DHCPv6, it MUST accept an IA_PD option in DHCPv6 =20 Advertise/Reply messages, even if the message does not Advertise/Reply messages, even if the message does not =20 contain any addresses, unless configured to only obtain its contain any addresses, unless configured to only obtain its =20 WAN IPv6 address via DHCPv6. WAN IPv6 address via DHCPv6. =20 =20 =20 =09 WPD-7: By default, an IPv6 CE router MUST NOT initiate any dynamic WPD-8: By default, an IPv6 CE router MUST NOT initiate any dynamic =20 routing protocol on its WAN interface. routing protocol on its WAN interface. =20 =20 4.3. LAN-Side Configuration 4.3. LAN-Side Configuration =20 =20 The IPv6 CE router distributes configuration information obtained The IPv6 CE router distributes configuration information obtained =20 during WAN interface provisioning to IPv6 hosts and assists IPv6 during WAN interface provisioning to IPv6 hosts and assists IPv6 =20 hosts in obtaining IPv6 addresses. It also supports connectivity of hosts in obtaining IPv6 addresses. It also supports connectivity of =20 these devices in the absence of any working WAN interface. these devices in the absence of any working WAN interface. =20 =20 An IPv6 CE router is expected to support an IPv6 end-user network = and An IPv6 CE router is expected to support an IPv6 end-user network and =20 =20 =20 skipping to change at page 16, line=20 28 =20 skipping to change at page 16, line=20 29 =20 draft-droms-dhc-dhcpv6-maxsolrt-update-00 (work in draft-droms-dhc-dhcpv6-maxsolrt-update-00 (work in =20 progress), November 2011. progress), November 2011. =20 =20 [I-D.ietf-dhc-pd-exclude] [I-D.ietf-dhc-pd-exclude] =20 Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, =20 "Prefix Exclude Option for DHCPv6-based Prefix "Prefix Exclude Option for DHCPv6-based Prefix =20 Delegation", draft-ietf-dhc-pd-exclude-04 (work in Delegation", draft-ietf-dhc-pd-exclude-04 (work in =20 progress), December 2011. progress), December 2011. =20 =20 [I-D.ietf-pcp-base] [I-D.ietf-pcp-base] =20 =20 =09 Cheshire, S., Boucadair, M., Selkirk, P., Wing, D., and = R. Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. =20 Penno, "Port Control Protocol (PCP)", Selkirk, "Port Control Protocol (PCP)", =20 draft-ietf-pcp-base-23 (work in progress), February 2012. draft-ietf-pcp-base-24 (work in progress), March 2012. =20 =20 [RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts - =20 Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989. =20 =20 =20 =09 =09 [RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 =20 for IPv4, IPv6 and OSI", RFC 2030, October 1996. =20 = =20 =20 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate =20 Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997. =20 =20 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", =20 RFC 2131, March 1997. RFC 2131, March 1997. =20 =20 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet =20 Networks", RFC 2464, December 1998. Networks", RFC 2464, December 1998. =20 =20 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: =20 =20 =20 skipping to change at page 18, line=20 25 =20 skipping to change at page 18, line=20 30 =20 =20 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 =20 Infrastructures (6rd) -- Protocol Specification", Infrastructures (6rd) -- Protocol Specification", =20 RFC 5969, August 2010. RFC 5969, August 2010. =20 =20 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities = in [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in =20 Customer Premises Equipment (CPE) for Providing Customer Premises Equipment (CPE) for Providing =20 Residential IPv6 Internet Service", RFC 6092, Residential IPv6 Internet Service", RFC 6092, =20 January 2011. January 2011. =20 =20 =20 =09 =09 [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address =20 Assignment to End Sites", BCP 157, RFC 6177, March 2011. =20 = =20 =20 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- =20 Stack Lite Broadband Deployments Following IPv4 Stack Lite Broadband Deployments Following IPv4 =20 Exhaustion", RFC 6333, August 2011. Exhaustion", RFC 6333, August 2011. =20 =20 [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration =20 Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", =20 RFC 6334, August 2011. RFC 6334, August 2011. =20 =20 [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node =20 Requirements", RFC 6434, December 2011. Requirements", RFC 6434, December 2011. =20 =20 =20 End of changes. 25 change=20 blocks.=20 =20 52 lines changed or deleted =20 66 lines changed or added =20 This html diff was produced by rfcdiff 1.39p1. The latest version is = available from http://tools.ietf.org/tools/rfcdiff/ = =20 =20 =20 ------_=_NextPart_001_01CD037B.76263DF8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Folks,

 

Here is the = delta between -07 that was sent out for LastCall and -08 which has edits = from review.=A0 Three minor items from Ole need closure during this = week.=A0=A0 PCP needs closure between Med and Francis. =A0=A0Changes = from DanielR, RayH, and Ole have been incorporated.

 

Thanks,

 

Hemant

 

 

< draft-ietf-v6ops-6204bis-07.txt <= o:p>

 draft-ietf-v6ops-6204bis-08.txt <= a = href=3D"http://www.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=3Ddraft-ietf-= v6ops-6204bis-08.txt">>

 

Network Working = Group=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 H. = Singh

=

Network Working = Group=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 H. = Singh

 

Internet-Draft=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=A0 W. Beebee

=

Internet-Draft=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=A0 W. Beebee

 

Obsoletes: 6204 (if = approved)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 Cisco Systems, Inc.

=

Obsoletes: 6204 (if = approved)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 Cisco Systems, Inc.

 

Intended status: = Informational=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 C. = Donley

=

Intended status: = Informational=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 C. = Donley

 

 

Expires: September 9, 2012 = =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=A0CableLabs

=

Expires: September 17, = 2012=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 = CableLabs

 

=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=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0B. Stark

=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=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0B. = Stark

 

=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=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = AT&T

=

=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=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0AT&T=

 

=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=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 O. Troan, = Ed.

=

=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=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0O. Troan, = Ed.

 

=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=A0=A0=A0=A0=A0Cisco Systems, = Inc.

=

=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=A0= =A0=A0=A0=A0=A0Cisco Systems, Inc.

 

 

=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=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0March 8, = 2012

=

=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=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0March 16, = 2012

 

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Basic Requirements for IPv6 = Customer Edge Routers

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Basic Requirements for IPv6 = Customer Edge Routers

 

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = draft-ietf-v6ops-6204bis-07

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0d= raft-ietf-v6ops-6204bis-08

 

 

Abstract

=

Abstract

 

 

=A0=A0 This document specifies requirements for an IPv6 Customer = Edge (CE)

=

=A0=A0=A0This document specifies requirements for an IPv6 Customer = Edge (CE)

 

=A0=A0 router.=A0 Specifically, the current version of this = document focuses

=

=A0=A0=A0router.=A0 Specifically, the current version of this = document focuses

 

=A0=A0 on the basic provisioning of an IPv6 CE router and the = provisioning

=

=A0=A0=A0on the basic provisioning of an IPv6 CE router and the = provisioning

 

=A0=A0 of IPv6 hosts attached to it.=A0 The document also covers = IP transition

=

=A0=A0=A0of IPv6 hosts attached to it.=A0 The document also covers = IP transition

 

=A0=A0 technologies.=A0 Two transition technologies in RFC 5969's = 6rd and RFC

=

=A0=A0=A0technologies.=A0 Two transition technologies in RFC = 5969's 6rd and RFC

 

=A0=A0 6333's DS-Lite. are covered in the document.=A0 The = document obsoletes

=

=A0=A0=A06333's DS-Lite. are covered in the document.=A0 The = document obsoletes

 

=A0=A0 RFC 6204, if approved.

=A0=A0=A0RFC 6204, if approved.

 

 

 

skipping to change = at page 1, line =

42

 

skipping to change = at page 1, line =

42

 

=A0=A0 Internet-Drafts are working documents of the Internet = Engineering

=

=A0=A0=A0Internet-Drafts are working documents of the Internet = Engineering

 

=A0=A0 Task Force (IETF).=A0 Note that other groups may also = distribute

=

=A0=A0=A0Task Force (IETF).=A0 Note that other groups may also = distribute

 

=A0=A0 working documents as Internet-Drafts.=A0 The list of = current Internet-

=

=A0=A0=A0working documents as Internet-Drafts.=A0 The list of = current Internet-

 

=A0=A0 Drafts is at = http://datatracker.ietf.org/drafts/current/.

=A0=A0=A0Drafts is at = http://datatracker.ietf.org/drafts/current/.

 

=A0=A0 Internet-Drafts are draft documents valid for a maximum of = six months

=

=A0=A0=A0Internet-Drafts are draft documents valid for a maximum = of six months

 

=A0=A0 and may be updated, replaced, or obsoleted by other = documents at any

=

=A0=A0=A0and may be updated, replaced, or obsoleted by other = documents at any

 

=A0=A0 time.=A0 It is inappropriate to use Internet-Drafts as = reference

=

=A0=A0=A0time.=A0 It is inappropriate to use Internet-Drafts as = reference

 

=A0=A0 material or to cite them other than as "work in = progress."

=

=A0=A0=A0material or to cite them other than as "work in = progress."

 

 

 

=A0=A0 This Internet-Draft will expire on September 9, 2012.

=A0=A0=A0This Internet-Draft will expire on September 17, 2012.

 

 

Copyright Notice

=

Copyright Notice

 

 

=A0=A0 Copyright (c) 2012 IETF Trust and the persons identified as = the

=

=A0=A0=A0Copyright (c) 2012 IETF Trust and the persons identified = as the

 

=A0=A0 document authors.=A0 All rights = reserved.

=

=A0=A0=A0document authors.=A0 All rights = reserved.

 

 

=A0=A0 This document is subject to BCP 78 and the IETF Trust's = Legal

=

=A0=A0=A0This document is subject to BCP 78 and the IETF Trust's = Legal

 

=A0=A0 Provisions Relating to IETF = Documents

=

=A0=A0=A0Provisions Relating to IETF = Documents

 

=A0=A0 (http://trustee.ietf.org/license-info) in effect on the = date of

=

=A0=A0=A0(http://trustee.ietf.org/license-info) in effect on the = date of

 

=A0=A0 publication of this document.=A0 Please review these = documents

=

=A0=A0=A0publication of this document.=A0 Please review these = documents

 

 

 

skipping to change = at page 3, line =

28

 

skipping to change = at page 3, line =

28

 

=A0=A0 of its LAN interfaces, and fetches other configuration = information

=

=A0=A0=A0of its LAN interfaces, and fetches other configuration = information

 

=A0=A0 from the service provider network.=A0 Automatic = provisioning of more

=

=A0=A0=A0from the service provider network.=A0 Automatic = provisioning of more

 

=A0=A0 complex topology than a single router with multiple LAN = interfaces is

=

=A0=A0=A0complex topology than a single router with multiple LAN = interfaces is

 

=A0=A0 out of scope for this = document.

=

=A0=A0=A0out of scope for this = document.

 

 

=A0=A0 See [RFC4779] for a discussion of options available for = deploying

=

=A0=A0=A0See [RFC4779] for a discussion of options available for = deploying

 

=A0=A0 IPv6 in service provider access = networks.

=

=A0=A0=A0IPv6 in service provider access = networks.

 

 

=A0=A0 The document also covers IP transition technologies.=A0 Two = transition

=

=A0=A0=A0The document also covers IP transition technologies.=A0 = Two transition

 

=A0=A0 technologies in 6rd [RFC5969] and DS-Lite [RFC6333] are = covered in

=

=A0=A0=A0technologies in 6rd [RFC5969] and DS-Lite [RFC6333] are = covered in

 

 

=A0=A0 the document.=A0 At the time of = writing this document these were = the

=

=A0=A0=A0the document.

 

=A0=A0 only two = transition technologies available in RFC form to be = included

=

 

=A0=A0 in this = document.

=

 

 

1.1.=A0 Requirements Language

1.1.=A0 Requirements Language

 

 

=A0=A0 The key words "MUST", "MUST NOT", = "REQUIRED", "SHALL", "SHALL = NOT",

=

=A0=A0=A0The key words "MUST", "MUST NOT", = "REQUIRED", "SHALL", "SHALL = NOT",

 

=A0=A0 "SHOULD", "SHOULD NOT", = "RECOMMENDED", "MAY", and "OPTIONAL" in = this

=

=A0=A0=A0"SHOULD", "SHOULD NOT", = "RECOMMENDED", "MAY", and "OPTIONAL" in = this

 

=A0=A0 document are to be interpreted as described in RFC 2119 = [RFC2119].

=

=A0=A0=A0document are to be interpreted as described in RFC 2119 = [RFC2119].

 

 

2.=A0 Terminology

=

2.=A0 Terminology

 

 

=A0=A0 End-User Network=A0=A0=A0=A0=A0=A0=A0=A0=A0 one or more = links attached to the IPv6 CE

=

=A0=A0=A0End-User Network=A0=A0=A0=A0=A0=A0=A0=A0=A0 one or more = links attached to the IPv6 CE

 

 

 

skipping to change = at page 9, line =

8

 

skipping to change = at page 9, line =

8

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 router MUST support IPv6 over PPP = [RFC5072].

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0router MUST support IPv6 over PPP = [RFC5072].

 

 

=A0=A0 WLL-3:=A0 If the WAN interface supports PPP encapsulation, = in a dual-

=

=A0=A0=A0WLL-3:=A0 If the WAN interface supports PPP = encapsulation, in a dual-

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 stack environment with IPCP and = IPV6CP running over one PPP

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0stack environment with IPCP and = IPV6CP running over one PPP

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 logical channel, the Network = Control Protocols (NCP's) MUST

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0logical channel, the Network = Control Protocols (NCP's) MUST

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 be treated as independent of each = other and start and

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0be treated as independent of each = other and start and

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 terminate = independently.

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0terminate = independently.

 

 

=A0=A0 Address assignment = requirements:

=

=A0=A0=A0Address assignment = requirements:

 

 

 

=A0=A0 WAA-1:=A0 The IPv6 CE router MUST support Stateless = Address

=

=A0=A0=A0WAA-1:=A0=A0 The IPv6 CE router MUST support Stateless = Address

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Autoconfiguration (SLAAC) = [RFC4862].

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Autoconfiguration (SLAAC) = [RFC4862].

 

 

 

=A0=A0 WAA-2:=A0 The IPv6 CE router MUST follow the = recommendations in Section

=

=A0=A0=A0WAA-2:=A0=A0 The IPv6 CE router MUST follow the = recommendations in

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 4 of [RFC5942], and in particular = the handling of the L flag

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Section 4 of [RFC5942], and in = particular the handling of

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 in the Router Advertisement Prefix = Information option.

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0the L flag in the Router = Advertisement Prefix Information

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0option.

 

 

 

=A0=A0 WAA-3:=A0 The IPv6 CE router MUST support DHCPv6 [RFC3315] = client

=

=A0=A0=A0WAA-3:=A0=A0 The IPv6 CE router MUST support DHCPv6 = [RFC3315] client

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = behavior.

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0behavior.

=

 

 

 

=A0=A0 WAA-4:=A0 The IPv6 CE router MUST be able to support the = following

=

=A0=A0=A0WAA-4:=A0=A0 The IPv6 CE router MUST be able to support = the following

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 DHCPv6 options: IA_NA, Reconfigure = Accept [RFC3315], and

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0DHCPv6 options: IA_NA, = Reconfigure Accept [RFC3315], and

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 DNS_SERVERS [RFC3646].=A0 The IPv6 = CE router SHOULD be able to

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0DNS_SERVERS [RFC3646].=A0 The = IPv6 CE router SHOULD be able to

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 support the DNS Search List DNSSL = option as specified in

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0support the DNS Search List = DNSSL option as specified in

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = [RFC3646].

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0[RFC3646].

 

 

 

=A0=A0 WAA-5:=A0 The IPv6 CE router SHOULD support the DHCPv6 = Simple Network

=

=A0=A0=A0WAA-5:=A0=A0 The IPv6 CE router SHOULD implement the Simple Network = Time

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Time Protocol (SNTP) option = [RFC4075] and the Information

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Protocol (SNTP) as specified in [RFC2030].=A0 If the CE = router

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Refresh Time option = [RFC4242].

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0implements SNTP, it requests = the SNTP option [RFC4075] = and

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0uses the received list of = servers as primary time reference,

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0unless explicitly configured = otherwise.

 

 

 

=A0=A0 WAA-6:=A0 If the IPv6 CE = router receives a Router Advertisement = message

=

=A0=A0=A0WAA-6:=A0=A0 The IPv6 CE = router SHOULD implement the Information Refresh

 

=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0(described in [RFC4861]) with the M flag set to 1, the = IPv6

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Time option and associated = client behavior as specified in

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 CE router MUST do DHCPv6 address = assignment (request an IA_NA

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0[RFC4242].

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 option).

=

 

 

 

=A0=A0 WAA-7:=A0 If the IPv6 CE router does = not acquire global IPv6

=A0=A0=A0WAA-7:=A0=A0 If the IPv6 CE router receives a Router = Advertisement

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 address(es) from either SLAAC or = DHCPv6, then it MUST create

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0message (described in = [RFC4861]) with the M flag set to 1,

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 global IPv6 address(es) from its = delegated prefix(es) and

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0the IPv6 CE router MUST do DHCPv6 address assignment

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 configure those on one of its = internal virtual network

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0(request an IA_NA = option).

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 interfaces, unless configured to = require a global = IPv6

=

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 address on = the WAN interface.

=

 

 

 

=A0=A0 WAA-8:=A0 The CE Router MUST = support the DHCPv6 SOL_MAX_RT = option

=

=A0=A0=A0WAA-8:=A0=A0 If the IPv6 CE router does not acquire global = IPv6

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = [I-D.droms-dhc-dhcpv6-maxsolrt-update] in a received = DHCPv6

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0address(es) from either = SLAAC or DHCPv6, then it MUST = create

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Advertise or Reply message and set its internal SOL_MAX_RT

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0global IPv6 address(es) from = its delegated prefix(es) = and

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 parameter to the value contained in the SOL_MAX_RT = option.

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0configure those on one of its internal virtual network

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0interfaces, unless = configured to require a global = IPv6

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0address on the WAN interface.

 

 

 

=A0=A0 WAA-9:=A0 As a router, the IPv6 CE router MUST follow the = weak host

=

=A0=A0=A0WAA-9:=A0=A0 The CE Router MUST = support the DHCPv6 SOL_MAX_RT = option

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (Weak ES) model [RFC1122].=A0 When = originating packets from an

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0[I-D.droms-dhc-dhcpv6-maxsolrt-= update] in a received DHCPv6

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 interface, it will use a source = address from another one of

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Advertise or Reply message and = set its internal SOL_MAX_RT

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 its interfaces if the outgoing = interface does not have an

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0parameter to the value = contained in the SOL_MAX_RT option.

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 address of suitable = scope.

=

 

=A0=A0=A0WAA-10:=A0 As a router, the = IPv6 CE router MUST follow the weak host

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0(Weak ES) model [RFC1122].=A0 = When originating packets from an

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0interface, it will use a = source address from another one of

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0its interfaces if the outgoing = interface does not have an

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0address of suitable = scope.

 

 

=A0=A0 Prefix delegation = requirements:

=

=A0=A0=A0Prefix delegation = requirements:

 

 

=A0=A0 WPD-1:=A0 The IPv6 CE router MUST support DHCPv6 prefix = delegation

=

=A0=A0=A0WPD-1:=A0 The IPv6 CE router MUST support DHCPv6 prefix = delegation

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 requesting router behavior as = specified in [RFC3633] (IA_PD

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0requesting router behavior as = specified in [RFC3633] (IA_PD

 

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 option).=A0 The IPv6 CE Router = SHOULD support the

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0option).

 

=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=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=A0WPD-2:=A0 The IPv6 CE Router = SHOULD support the

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [I-D.ietf-dhc-pd-exclude] = PD-Exclude option.

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0[I-D.ietf-dhc-pd-exclude] = PD-Exclude option.

 

 

 

=A0=A0 WPD-2:=A0 The IPv6 CE router = MAY indicate as a hint to the delegating

=A0=A0=A0WPD-3:=A0 The IPv6 CE router = MAY indicate as a hint to the delegating

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 router the size of the prefix it = requires.=A0 If so, it MUST

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0router the size of the prefix it = requires.=A0 If so, it MUST

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ask for a prefix large enough to = assign one /64 for each of

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0ask for a prefix large enough to = assign one /64 for each of

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 its interfaces, rounded up to the = nearest nibble, and SHOULD

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0its interfaces, rounded up to the = nearest nibble, and SHOULD

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 be configurable to ask for = more.

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0be configurable to ask for = more.

 

 

 

=A0=A0 WPD-3:=A0 The IPv6 CE router = MUST be prepared to accept a delegated

=A0=A0=A0WPD-4:=A0 The IPv6 CE router = MUST be prepared to accept a delegated

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 prefix size different from what is = given in the hint.=A0 If the

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0prefix size different from what = is given in the hint.=A0 If the

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 delegated prefix is too small to = address all of its

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0delegated prefix is too small to = address all of its

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 interfaces, the IPv6 CE router = SHOULD log a system management

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0interfaces, the IPv6 CE router = SHOULD log a system management

 

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = error.

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0error.=A0 [RFC6177] covers the recommendations for = service

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0providers for prefix allocation = sizes.

 

 

 

=A0=A0 WPD-4:=A0 By default, the IPv6 = CE router MUST initiate DHCPv6 prefix

=A0=A0=A0WPD-5:=A0 By default, the = IPv6 CE router MUST initiate DHCPv6 prefix

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 delegation when either the M or O = flags are set to 1 in a

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0delegation when either the M or O = flags are set to 1 in a

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 received Router Advertisement = message.

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0received Router Advertisement = message.

 

 

 

=A0=A0 WPD-5:=A0 If the delegated = prefix(es) are aggregate route(s) of

=A0=A0=A0WPD-6:=A0 If the delegated = prefix(es) are aggregate route(s) of

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 multiple, more-specific routes, the = IPv6 CE router MUST

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0multiple, more-specific routes, = the IPv6 CE router MUST

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 discard packets that match the = aggregate route(s), but not

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0discard packets that match the = aggregate route(s), but not

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 any of the more-specific routes.=A0 = In other words, the next

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0any of the more-specific = routes.=A0 In other words, the next

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 hop for the aggregate route(s) = should be the null

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0hop for the aggregate route(s) = should be the null

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 destination.=A0 This is necessary = to prevent forwarding loops

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0destination.=A0 This is necessary = to prevent forwarding loops

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 when some addresses covered by the = aggregate are not

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0when some addresses covered by = the aggregate are not

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 reachable = [RFC4632].

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0reachable = [RFC4632].

 

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (a)=A0 The IPv6 CE router SHOULD = send an ICMPv6 Destination

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0(a)=A0 The IPv6 CE router SHOULD = send an ICMPv6 Destination

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Unreachable message = in accordance with Section 3.1 of

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Unreachable = message in accordance with Section 3.1 of

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [RFC4443] back to = the source of the packet, if the

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0[RFC4443] back to = the source of the packet, if the

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 packet is to be = dropped due to this rule.

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0packet is to be = dropped due to this rule.

 

 

 

=A0=A0 WPD-6:=A0 If the IPv6 CE = router requests both an IA_NA and an IA_PD

=A0=A0=A0WPD-7:=A0 If the IPv6 CE = router requests both an IA_NA and an IA_PD

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 option in DHCPv6, it MUST accept an = IA_PD option in DHCPv6

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0option in DHCPv6, it MUST accept = an IA_PD option in DHCPv6

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Advertise/Reply messages, even if = the message does not

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Advertise/Reply messages, even if = the message does not

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 contain any addresses, unless = configured to only obtain its

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0contain any addresses, unless = configured to only obtain its

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 WAN IPv6 address via = DHCPv6.

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0WAN IPv6 address via = DHCPv6.

 

 

 

=A0=A0 WPD-7:=A0 By default, an IPv6 = CE router MUST NOT initiate any dynamic

=A0=A0=A0WPD-8:=A0 By default, an = IPv6 CE router MUST NOT initiate any = dynamic

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 routing protocol on its WAN = interface.

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0routing protocol on its WAN = interface.

 

 

4.3.=A0 LAN-Side Configuration

4.3.=A0 LAN-Side Configuration

 

 

=A0=A0 The IPv6 CE router distributes configuration information = obtained

=

=A0=A0=A0The IPv6 CE router distributes configuration information = obtained

 

=A0=A0 during WAN interface provisioning to IPv6 hosts and assists = IPv6

=

=A0=A0=A0during WAN interface provisioning to IPv6 hosts and = assists IPv6

 

=A0=A0 hosts in obtaining IPv6 addresses.=A0 It also supports = connectivity of

=

=A0=A0=A0hosts in obtaining IPv6 addresses.=A0 It also supports = connectivity of

 

=A0=A0 these devices in the absence of any working WAN = interface.

=

=A0=A0=A0these devices in the absence of any working WAN = interface.

 

 

=A0=A0 An IPv6 CE router is expected to support an IPv6 end-user = network and

=

=A0=A0=A0An IPv6 CE router is expected to support an IPv6 end-user = network and

 

 

 

skipping to change = at page 16, line =

28

 

skipping to change = at page 16, line =

29

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = draft-droms-dhc-dhcpv6-maxsolrt-update-00 (work = in

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0draft-droms-dhc-dhcpv6-ma= xsolrt-update-00 (work in

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 progress), November = 2011.

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0progress), November = 2011.

 

 

=A0=A0 [I-D.ietf-dhc-pd-exclude]

=A0=A0=A0[I-D.ietf-dhc-pd-exclude]

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Korhonen, J., Savolainen, = T., Krishnan, S., and O. Troan,

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Korhonen, J., = Savolainen, T., Krishnan, S., and O. = Troan,

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 "Prefix Exclude = Option for DHCPv6-based Prefix

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0"Prefix Exclude = Option for DHCPv6-based Prefix

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Delegation", = draft-ietf-dhc-pd-exclude-04 (work in

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Delegation", = draft-ietf-dhc-pd-exclude-04 (work in

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 progress), December = 2011.

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0progress), December = 2011.

 

 

=A0=A0 [I-D.ietf-pcp-base]

=A0=A0=A0[I-D.ietf-pcp-base]

 

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Cheshire, S., Boucadair, = M., Selkirk, P., Wing, D., and = R.

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Wing, D., Cheshire, S., Boucadair, M., Penno, = R., and P.

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Penno, "Port Control = Protocol (PCP)",

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Selkirk, "Port = Control Protocol (PCP)",

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 draft-ietf-pcp-base-23 (work in progress), February 2012.

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0draft-ietf-pcp-base-24 (work in progress), March 2012.

 

 

=A0=A0 [RFC1122]=A0 Braden, R., "Requirements for Internet = Hosts -

=

=A0=A0=A0[RFC1122]=A0 Braden, R., "Requirements for Internet = Hosts -

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Communication = Layers", STD 3, RFC 1122, October = 1989.

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Communication = Layers", STD 3, RFC 1122, October = 1989.

 

 

 

=A0=A0=A0[RFC2030]=A0 Mills, D., = "Simple Network Time Protocol (SNTP) Version = 4

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0for IPv4, IPv6 and = OSI", RFC 2030, October 1996.

 

=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=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 [RFC2119]=A0 Bradner, S., "Key words for use in RFCs = to Indicate

=

=A0=A0=A0[RFC2119]=A0 Bradner, S., "Key words for use in RFCs = to Indicate

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Requirement Levels", = BCP 14, RFC 2119, March 1997.

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Requirement = Levels", BCP 14, RFC 2119, March = 1997.

 

 

=A0=A0 [RFC2131]=A0 Droms, R., "Dynamic Host Configuration = Protocol",

=

=A0=A0=A0[RFC2131]=A0 Droms, R., "Dynamic Host Configuration = Protocol",

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 RFC 2131, March = 1997.

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0RFC 2131, March = 1997.

 

 

=A0=A0 [RFC2464]=A0 Crawford, M., "Transmission of IPv6 = Packets over Ethernet

=

=A0=A0=A0[RFC2464]=A0 Crawford, M., "Transmission of IPv6 = Packets over Ethernet

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Networks", RFC 2464, = December 1998.

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Networks", RFC = 2464, December 1998.

 

 

=A0=A0 [RFC2827]=A0 Ferguson, P. and D. Senie, "Network = Ingress Filtering:

=

=A0=A0=A0[RFC2827]=A0 Ferguson, P. and D. Senie, "Network = Ingress Filtering:

 

 

 

skipping to change = at page 18, line =

25

 

skipping to change = at page 18, line =

30

 

 

=A0=A0 [RFC5969]=A0 Townsley, W. and O. Troan, "IPv6 Rapid = Deployment on IPv4

=

=A0=A0=A0[RFC5969]=A0 Townsley, W. and O. Troan, "IPv6 Rapid = Deployment on IPv4

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Infrastructures (6rd) -- = Protocol Specification",

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Infrastructures (6rd) -- = Protocol Specification",

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 RFC 5969, August = 2010.

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0RFC 5969, August = 2010.

 

 

=A0=A0 [RFC6092]=A0 Woodyatt, J., "Recommended Simple = Security Capabilities in

=

=A0=A0=A0[RFC6092]=A0 Woodyatt, J., "Recommended Simple = Security Capabilities in

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Customer Premises = Equipment (CPE) for Providing

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Customer Premises = Equipment (CPE) for Providing

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Residential IPv6 Internet = Service", RFC 6092,

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Residential IPv6 = Internet Service", RFC 6092,

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 January = 2011.

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0January = 2011.

 

 

 

=A0=A0=A0[RFC6177]=A0 Narten, T., Huston, = G., and L. Roberts, "IPv6 = Address

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Assignment to End = Sites", BCP 157, RFC 6177, March 2011.

 

=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=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 [RFC6333]=A0 Durand, A., Droms, R., Woodyatt, J., and Y. = Lee, "Dual-

=

=A0=A0=A0[RFC6333]=A0 Durand, A., Droms, R., Woodyatt, J., and Y. = Lee, "Dual-

 

=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0Stack Lite Broadband = Deployments Following IPv4

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Stack Lite Broadband = Deployments Following IPv4

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Exhaustion", RFC = 6333, August 2011.

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Exhaustion", RFC = 6333, August 2011.

 

 

=A0=A0 [RFC6334]=A0 Hankins, D. and T. Mrugalski, "Dynamic = Host Configuration

=

=A0=A0=A0[RFC6334]=A0 Hankins, D. and T. Mrugalski, "Dynamic = Host Configuration

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Protocol for IPv6 (DHCPv6) = Option for Dual-Stack Lite",

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Protocol for IPv6 = (DHCPv6) Option for Dual-Stack Lite",

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 RFC 6334, August = 2011.

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0RFC 6334, August = 2011.

 

 

=A0=A0 [RFC6434]=A0 Jankiewicz, E., Loughney, J., and T. Narten, = "IPv6 Node

=

=A0=A0=A0[RFC6434]=A0 Jankiewicz, E., Loughney, J., and T. Narten, = "IPv6 Node

 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Requirements", RFC = 6434, December 2011.

=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Requirements", RFC = 6434, December 2011.

 

 

 

 End of = changes. 25 change

blocks. 

 

52 lines changed or = deleted

 

66 lines changed or = added

 


This html diff = was produced by rfcdiff 1.39p1. The latest version is available from http://tools.ietf.org/t= ools/rfcdiff/

 

 

------_=_NextPart_001_01CD037B.76263DF8-- From wesley.george@twcable.com Fri Mar 16 07:02:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD25021F841C for ; Fri, 16 Mar 2012 07:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.265 X-Spam-Level: X-Spam-Status: No, score=-0.265 tagged_above=-999 required=5 tests=[AWL=-0.403, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 hOFnm54n5dDb for ; Fri, 16 Mar 2012 07:02:07 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 79D5721F86A1 for ; Fri, 16 Mar 2012 07:02:07 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.73,598,1325480400"; d="scan'208,217";a="338297288" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 16 Mar 2012 10:01:44 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Fri, 16 Mar 2012 10:01:51 -0400 From: "George, Wes" To: "Hemant Singh (shemant)" , "Fred Baker (fred)" , v6ops v6ops WG Date: Fri, 16 Mar 2012 10:01:50 -0400 Thread-Topic: Old/completed draft! (was RE: [v6ops] draft-ietf-intarea-ipv6-required) Thread-Index: Ac0DCJf3A+CUkqBWQ/68AIHF90EVrgAAa8hAABx7coA= Message-ID: References: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1F64@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1F64@XMB-RCD-109.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_DCC302FAA9FE5F4BBA4DCAD465693779173BAF4416PRVPEXVS03cor_" MIME-Version: 1.0 Subject: [v6ops] Old/completed draft! (was RE: draft-ietf-intarea-ipv6-required) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 14:02:11 -0000 --_000_DCC302FAA9FE5F4BBA4DCAD465693779173BAF4416PRVPEXVS03cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, the referenced draft has long since passed Last Call and is in the R= FC editor's queue. It is currently in AUTH-48 status awaiting the AD's dete= rmination as to whether it will be a BCP or a PS. (There was apparently som= e confusion because the draft changed status between revisions. Despite wha= t the datatracker says, the authors believe that the last guidance was for = it to be a BCP). http://datatracker.ietf.org/doc/draft-ietf-intarea-ipv6-required/ I do not believe that the wording nits below warrant changes at this stage,= and am disinclined to do anything about them. I believe that the draft that Fred intended to point you to is http://tools.ietf.org/html/draft-george-ipv6-support-01 since this one is being discussed in INT-Area in Paris and we are certainly= open to comments from v6ops as well. The draft names are similar, so I understand how there might have been conf= usion. Hopefully this clears it up. Thanks, Wes George From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of H= emant Singh (shemant) Sent: Thursday, March 15, 2012 8:39 PM To: Fred Baker (fred); v6ops v6ops WG Subject: Re: [v6ops] draft-ietf-intarea-ipv6-required Snipped from the document is the text below that I have a comment on. [While transition technologies and other means to extend the lifespan of IPv4 do exist, nearly all of them come with tradeoffs that prevent them from being optimal long-term solutions when compared with deployment of IP version 6 (IPv6) as a means to allow continued growth on the Internet.] Some folks will have an exactly opposite view from what is said above. IPv= 4 may exist for a long time and thus IPv6 hosts will need to communicate wi= th IPv4 hosts and one will need transition mechanism and the deployment is = still optimal. Thus the whole text above can be removed or the text will t= hrash for discussion. Further, the documents cites RFC 1812 but the title of RFC 1812 clearly men= tions "IP version 4 Routers". So isn't RFC 1812 disqualified to be in this= document that is trying to find RFCs that have IP specific text that needs= qualification by v4 or v6? That leaves only one RFC in RFC 1122 to cite i= n the document. It would be good to collect more RFCs to list. Lastly, fo= r IPv6 the IETF wrote the ipv6 node reqs RFC which is the goto document for= IPv6. From the IPv6 node reqs document one reaches all IPv6 specification= s and then one does not go to any IPv4 IETF specification. If one does, th= en some new features have to get into the ipv6 node reqs document. Most of the text in the third paragraph of the Introduction section is not = much use. It works much better to go directly to each device vendor and re= quest strongly for IPv6 support including any public shame in the IETF. Th= ere is enough public-domain free IPv6 code around that most devices could s= tart with. I'd recommend some of that code for specific devices. That's ho= w stuff gets done. Regards, Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-b= ounces@ietf.org] On Behalf Of Fred Baker (fred) Sent: Thursday, March 15, 2012 8:05 PM To: v6ops v6ops WG Subject: [v6ops] draft-ietf-intarea-ipv6-required http://tools.ietf.org/html/draft-ietf-intarea-ipv6-required "IPv6 Support Required for all IP-capable Nodes", Lee Howard, Chris Donley, Wesley George, Chris Donley, 8-Dec-11 George raised this question on v6ops a tad over a year ago, but I wonder if= there is a sense of the community that we should forward to intarea now. D= o me a favor if your would; read the draft and post a a comment on it. Up/d= own is good; if you don't support it, saying why not so I can summarize to = the Internet Area folks would be helpful. Chris Donley must have had a really major part in this draft... _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_DCC302FAA9FE5F4BBA4DCAD465693779173BAF4416PRVPEXVS03cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks, the referenced = draft has long since passed Last Call and is in the RFC editor’s queu= e. It is currently in AUTH-48 status awaiting the AD’s determination = as to whether it will be a BCP or a PS. (There was apparently some confusion because the draft changed status between revisio= ns. Despite what the datatracker says, the authors believe that the last gu= idance was for it to be a BCP).

http://datatracker.ietf.org/doc/draft-ietf-intare= a-ipv6-required/

I do not believe that = the wording nits below warrant changes at this stage, and am disinclined to= do anything about them.

 

I believe that the dra= ft that Fred intended to point you to is

http://tools.ietf.org/html/draft-george-ipv6-support-01=

since this one is bein= g discussed in INT-Area in Paris and we are certainly open to comments from= v6ops as well.

 

The draft names are si= milar, so I understand how there might have been confusion. Hopefully this = clears it up.

 

Thank= s,

=  

Wes G= eorge

 

 

From: v6ops-bo= unces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Hemant Singh (shemant)
Sent: Thursday, March 15, 2012 8:39 PM
To: Fred Baker (fred); v6ops v6ops WG
Subject: Re: [v6ops] draft-ietf-intarea-ipv6-required

 

Snipped from the document is the text below that I have a comment on.

 

[While transition technologies and other means to extend the lifespan

of IPv4 do exist, nearly all of them come with tradeoffs that prevent

them from being optimal long-term solutions when compared with

deployment of IP version 6 (IPv6) as a means to allow continued

growth on the Internet.]

 

Some folks will have an exactly opposite view from what is said above. &= nbsp;IPv4 may exist for a long time and thus IPv6 hosts will need to commun= icate with IPv4 hosts and one will need transition mechanism and the deployment is still optimal.  Thus the whole text a= bove can be removed or the text will thrash for discussion.

 

Further, the documents cites RFC 1812 but the title of RFC 1812 clearly = mentions “IP version 4 Routers”.  So isn’t RFC 1812 = disqualified to be in this document that is trying to find RFCs that have IP specific text that needs qualification by v4 or v6?  That lea= ves only one RFC in RFC 1122 to cite in the document.  It would be goo= d to collect more RFCs to list.  Lastly, for IPv6 the IETF wrote the i= pv6 node reqs RFC which is the goto document for IPv6.  From the IPv6 node reqs document one reaches all IPv6 specific= ations and then one does not go to any IPv4 IETF specification.  If on= e does, then some new features have to get into the ipv6 node reqs document= .

 

Most of the text in the third paragraph of the Introduction section is n= ot much use.  It works much better to go directly to each device vendo= r and request strongly for IPv6 support including any public shame in the IETF.  There is enough public-domain free IPv6 co= de around that most devices could start with. I’d recommend some of t= hat code for specific devices.  That’s how stuff gets done.

 

Regards,

 

Hemant

 

-----Original Message-----
From: v6ops-bounces@ietf.org = [mailto:v6ops-bounces@ietf.org] On Behalf Of Fred Baker (fred)
Sent: Thursday, March 15, 2012 8:05 PM
To: v6ops v6ops WG
Subject: [v6ops] draft-ietf-intarea-ipv6-required

 

http://tools.ietf.org/html/draft-ietf-intarea-ipv6-r= equired

  "IPv6 Support Required for all IP-cap= able Nodes", Lee Howard, Chris

  Donley, Wesley George, Chris Donley, 8-Dec= -11

 

George raised this question on v6ops a tad over a= year ago, but I wonder if there is a sense of the community that we should= forward to intarea now. Do me a favor if your would; read the draft and po= st a a comment on it. Up/down is good; if you don't support it, saying why not so I can summarize to the Internet= Area folks would be helpful.

 

Chris Donley must have had a really major part in= this draft...

_______________________________________________

v6ops mailing list

v6ops@ietf.org<= /a>

https://www.ietf.org/mailman/listinfo/v6ops


This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_DCC302FAA9FE5F4BBA4DCAD465693779173BAF4416PRVPEXVS03cor_-- From fred@cisco.com Fri Mar 16 08:25:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5683621F8650 for ; Fri, 16 Mar 2012 08:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.062 X-Spam-Level: X-Spam-Status: No, score=-109.062 tagged_above=-999 required=5 tests=[AWL=0.936, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 FzkGjU3uVobj for ; Fri, 16 Mar 2012 08:25:36 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 73B0B21F860F for ; Fri, 16 Mar 2012 08:25:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=23328; q=dns/txt; s=iport; t=1331911535; x=1333121135; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=b1qUKMWjpnMDpBXCc3ksXQgAWVkTS6/0JfoVoM3H/rs=; b=JSEOMJg2gSpXPHVL0WM2n3USWWi1WWB8+CbKfpAxxEay/oYAlXrMzUS0 CM/Ece5gH1JGXAvq3ehwJx+c4mpTKE0XKd8cdpwmhFpDdlfU92DqB8YBp 19otpqKoCsdJnPAuRFG3iD8TE10cUfCP+uGVhhRZ/utWu8sM7QFPtX4Qi E=; X-IronPort-AV: E=Sophos;i="4.73,598,1325462400"; d="scan'208,217";a="33850801" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 16 Mar 2012 15:25:34 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2GFPX0A031474; Fri, 16 Mar 2012 15:25:33 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Fri, 16 Mar 2012 08:25:33 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Fri, 16 Mar 2012 08:25:33 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Fri, 16 Mar 2012 08:25:07 -0700 Message-Id: References: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1F64@XMB-RCD-109.cisco.com> To: "George, Wes" X-Mailer: Apple Mail (2.1084) Content-Type: multipart/alternative; boundary=Apple-Mail-41--730494246 Cc: v6ops v6ops WG Subject: Re: [v6ops] Old/completed draft! (was RE: draft-ietf-intarea-ipv6-required) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 15:25:37 -0000 --Apple-Mail-41--730494246 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Thanks. Yes, I went looking for draft-george-support-ipv6, and for some = reason didn't find it - perhaps because the tag I had reference a -02. = My error. On Mar 16, 2012, at 7:01 AM, George, Wes wrote: > Folks, the referenced draft has long since passed Last Call and is in = the RFC editor=92s queue. It is currently in AUTH-48 status awaiting the = AD=92s determination as to whether it will be a BCP or a PS. (There was = apparently some confusion because the draft changed status between = revisions. Despite what the datatracker says, the authors believe that = the last guidance was for it to be a BCP). > http://datatracker.ietf.org/doc/draft-ietf-intarea-ipv6-required/ > I do not believe that the wording nits below warrant changes at this = stage, and am disinclined to do anything about them. > =20 > I believe that the draft that Fred intended to point you to is > http://tools.ietf.org/html/draft-george-ipv6-support-01 > since this one is being discussed in INT-Area in Paris and we are = certainly open to comments from v6ops as well. > =20 > The draft names are similar, so I understand how there might have been = confusion. Hopefully this clears it up. > =20 > Thanks, > =20 > Wes George > =20 > =20 > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Hemant Singh (shemant) > Sent: Thursday, March 15, 2012 8:39 PM > To: Fred Baker (fred); v6ops v6ops WG > Subject: Re: [v6ops] draft-ietf-intarea-ipv6-required > =20 > Snipped from the document is the text below that I have a comment on. > =20 > [While transition technologies and other means to extend the lifespan > of IPv4 do exist, nearly all of them come with tradeoffs that prevent > them from being optimal long-term solutions when compared with > deployment of IP version 6 (IPv6) as a means to allow continued > growth on the Internet.] > =20 > Some folks will have an exactly opposite view from what is said above. = IPv4 may exist for a long time and thus IPv6 hosts will need to = communicate with IPv4 hosts and one will need transition mechanism and = the deployment is still optimal. Thus the whole text above can be = removed or the text will thrash for discussion. > =20 > Further, the documents cites RFC 1812 but the title of RFC 1812 = clearly mentions =93IP version 4 Routers=94. So isn=92t RFC 1812 = disqualified to be in this document that is trying to find RFCs that = have IP specific text that needs qualification by v4 or v6? That leaves = only one RFC in RFC 1122 to cite in the document. It would be good to = collect more RFCs to list. Lastly, for IPv6 the IETF wrote the ipv6 = node reqs RFC which is the goto document for IPv6. =46rom the IPv6 node = reqs document one reaches all IPv6 specifications and then one does not = go to any IPv4 IETF specification. If one does, then some new features = have to get into the ipv6 node reqs document. > =20 > Most of the text in the third paragraph of the Introduction section is = not much use. It works much better to go directly to each device vendor = and request strongly for IPv6 support including any public shame in the = IETF. There is enough public-domain free IPv6 code around that most = devices could start with. I=92d recommend some of that code for specific = devices. That=92s how stuff gets done. > =20 > Regards, > =20 > Hemant > =20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Fred Baker (fred) > Sent: Thursday, March 15, 2012 8:05 PM > To: v6ops v6ops WG > Subject: [v6ops] draft-ietf-intarea-ipv6-required > =20 > http://tools.ietf.org/html/draft-ietf-intarea-ipv6-required > "IPv6 Support Required for all IP-capable Nodes", Lee Howard, Chris > Donley, Wesley George, Chris Donley, 8-Dec-11 > =20 > George raised this question on v6ops a tad over a year ago, but I = wonder if there is a sense of the community that we should forward to = intarea now. Do me a favor if your would; read the draft and post a a = comment on it. Up/down is good; if you don't support it, saying why not = so I can summarize to the Internet Area folks would be helpful. > =20 > Chris Donley must have had a really major part in this draft... > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops >=20 > This E-mail and any of its attachments may contain Time Warner Cable = proprietary information, which is privileged, confidential, or subject = to copyright belonging to Time Warner Cable. This E-mail is intended = solely for the use of the individual or entity to which it is addressed. = If you are not the intended recipient of this E-mail, you are hereby = notified that any dissemination, distribution, copying, or action taken = in relation to the contents of and attachments to this E-mail is = strictly prohibited and may be unlawful. If you have received this = E-mail in error, please notify the sender immediately and permanently = delete the original and any copy of this E-mail and any printout. --Apple-Mail-41--730494246 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Thanks. Yes, I went looking for = draft-george-support-ipv6, and for some reason didn't find it - perhaps = because the tag I had reference a -02. My error.

On = Mar 16, 2012, at 7:01 AM, George, Wes wrote:

Folks, the referenced draft has long since passed Last Call = and is in the RFC editor=92s queue. It is currently in AUTH-48 status = awaiting the AD=92s determination as to whether it will be a BCP or a = PS. (There was apparently some confusion because the draft changed = status between revisions. Despite what the datatracker says, the authors = believe that the last guidance was for it to be a = BCP).
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.or= g] On Behalf = Of Hemant Singh = (shemant)
Sent: Thursday, March 15, 2012 = 8:39 PM
To: Fred Baker (fred); v6ops = v6ops WG
Subject: Re: [v6ops] = draft-ietf-intarea-ipv6-required
 
Snipped from the document is the text below that I have a = comment on.
 
[While transition technologies and other means to extend the = lifespan
of IPv4 do exist, nearly all of them come with tradeoffs that = prevent
them from being optimal long-term solutions when compared = with
growth on the Internet.]
 
Further, the documents = cites RFC 1812 but the title of RFC 1812 clearly mentions =93IP version = 4 Routers=94.  So isn=92t RFC 1812 disqualified to be in this = document that is trying to find RFCs that have IP specific text that = needs qualification by v4 or v6?  That leaves only one RFC in RFC = 1122 to cite in the document.  It would be good to collect more = RFCs to list.  Lastly, for IPv6 the IETF wrote the ipv6 node reqs = RFC which is the goto document for IPv6.  =46rom the IPv6 node reqs = document one reaches all IPv6 specifications and then one does not go to = any IPv4 IETF specification.  If one does, then some new features = have to get into the ipv6 node reqs = document.
 
Most of the text in the third paragraph of the Introduction = section is not much use.  It works much better to go directly to = each device vendor and request strongly for IPv6 support including any = public shame in the IETF.  There is enough public-domain free IPv6 = code around that most devices could start with. I=92d recommend some of = that code for specific devices.  That=92s how stuff gets = done.
 
Regards,
 
Hemant
 
 v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On = Behalf Of Fred Baker (fred)
Sent: Thursday, March 15, 2012 8:05 = PM
To: v6ops v6ops WG
Subject: [v6ops] = draft-ietf-intarea-ipv6-required
 

= --Apple-Mail-41--730494246-- From bs7652@att.com Fri Mar 16 14:16:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E9E21F8642 for ; Fri, 16 Mar 2012 14:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.028 X-Spam-Level: X-Spam-Status: No, score=-106.028 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, 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 vmyFImF+z6e8 for ; Fri, 16 Mar 2012 14:16:35 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF4321F85F6 for ; Fri, 16 Mar 2012 14:16:19 -0700 (PDT) X-Env-Sender: bs7652@att.com X-Msg-Ref: server-7.tower-120.messagelabs.com!1331932577!314256!1 X-Originating-IP: [144.160.20.146] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 26763 invoked from network); 16 Mar 2012 21:16:18 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-7.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 16 Mar 2012 21:16:18 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q2GLEgd7024655; Fri, 16 Mar 2012 17:14:43 -0400 Received: from sflint04.pst.cso.att.com (sflint04.pst.cso.att.com [144.154.234.231]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q2GLEJRt023718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Mar 2012 17:14:37 -0400 Received: from GAALPA1MSGHUB9C.ITServices.sbc.com (gaalpa1msghub9c.itservices.sbc.com [130.8.36.89]) by sflint04.pst.cso.att.com (RSA Interceptor); Fri, 16 Mar 2012 17:15:29 -0400 Received: from GAALPA1MSGUSR9N.ITServices.sbc.com ([169.254.6.156]) by GAALPA1MSGHUB9C.ITServices.sbc.com ([130.8.36.89]) with mapi id 14.01.0355.002; Fri, 16 Mar 2012 17:15:29 -0400 From: "STARK, BARBARA H" To: "Hemant Singh (shemant)" , Ray Hunter Thread-Topic: [v6ops] RFC6204bis-07 Thread-Index: AQHNA0xPemVwT4EJL0Czamf26OPXRJZtFXaAgABVglA= Date: Fri, 16 Mar 2012 21:15:28 +0000 Message-ID: <2D09D61DDFA73D4C884805CC7865E6110724B2@GAALPA1MSGUSR9N.ITServices.sbc.com> References: <867F4B6A1672E541A94676D556793ACD0EB995043C@MOPESMBX01.eu.thmulti.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3042FEBDB@XMB-RCD-109.cisco.com> <4F61E53D.4050904@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1C75@XMB-RCD-109.cisco.com> <4F62F576.3070209@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1FB5@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1FB5@XMB-RCD-109.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.103.91] Content-Type: multipart/alternative; boundary="_000_2D09D61DDFA73D4C884805CC7865E6110724B2GAALPA1MSGUSR9NIT_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 21:16:37 -0000 --_000_2D09D61DDFA73D4C884805CC7865E6110724B2GAALPA1MSGUSR9NIT_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No. IMO this is not a good thing to do. This is a CE router spec. It is not= , nor will it ever be, an access network spec. My interpretation of this suggestion is "well, maybe if we require the worl= d around the CE router to be perfect, then the CE router won't ever be face= d with imperfections." What a lovely world that would be. And thoroughly un= realistic. The CE router and the IETF have zero control over the access net= work that the CE router finds itself in. The goal needs to be to make the C= E router reasonably robust, to handle a variety of situations. My tea leaf = reading says that no matter how hard or how often the IETF tries to dictate= to access network providers what the IETF thinks providers should do, ther= e will always be those providers who ignore the IETF. Live with it. Deal wi= th it. And the CE router needs to deal with it, too. That's reality. Again. This is a CE router spec. The proposal does not place any additional= requirement on the CE router. A normative reference for the CE router to e= nsure that the access network always provides something bigger than a /64 = is meaningless and useless. Barbara From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of H= emant Singh (shemant) Sent: Friday, March 16, 2012 8:01 AM To: Ray Hunter Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-07 Ray, From: Ray Hunter [mailto:v6ops@globis.net] Sent: Friday, March 16, 2012 4:11 AM To: Hemant Singh (shemant) Cc: Wuyts Carl; v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-07 >Following IMVHO: We go into great detail on address assignment in 6204bis,= but miss the obvious statement that a CE device needs to be delegated enou= gh >addresses so that it can assign a /64 per LAN in order for 6204bis to w= ork as designed. v6ops WG shouldn't encourage SP's who ignore BCP (by assig= ning a >single /64 to an end site) to continue such practices without a ver= y good >reason, and that reason has not been presented. I think RFC6177 is = required >for 6204bis to work as designed, and is thus normative. OK. I agree using a /64 in the LAN is something the IETF should discourage= . >Suggestion: RFC6204bis refer to BCP 157 (RFC6177) as a normative reference= . Taken. Will add the normative reference. Thanks much, Hemant --_000_2D09D61DDFA73D4C884805CC7865E6110724B2GAALPA1MSGUSR9NIT_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

No. IMO this is not a goo= d thing to do. This is a CE router spec. It is not, nor will it ever be, an= access network spec.

 <= /p>

My interpretation of this= suggestion is “well, maybe if we require the world around the CE rou= ter to be perfect, then the CE router won’t ever be faced with imperfections.” What a lovely world that would be. And thoroughly un= realistic. The CE router and the IETF have zero control over the access net= work that the CE router finds itself in. The goal needs to be to make the C= E router reasonably robust, to handle a variety of situations. My tea leaf reading says that no matter how hard = or how often the IETF tries to dictate to access network providers what the= IETF thinks providers should do, there will always be those providers who = ignore the IETF. Live with it. Deal with it. And the CE router needs to deal with it, too. That’s realit= y.

 <= /p>

Again. This is a CE route= r spec. The proposal does not place any additional requirement on the CE ro= uter. A normative reference for the CE router to ensure that the access network always provides something bigger than a /64  = is meaningless and useless.

Barbara=

 <= /p>

From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf= .org] On Behalf Of Hemant Singh (shemant)
Sent: Friday, March 16, 2012 8:01 AM
To: Ray Hunter
Cc: v6ops@ietf.org
Subject: Re: [v6ops] RFC6204bis-07

 

Ray,

 

From: Ray Hunter [mailto:v6ops@globis.net] =
Sent: Friday, March 16, 2012 4:11 AM
To: Hemant Singh (shemant)
Cc: Wuyts Carl; v6ops@ietf.org=
Subject: Re: [v6ops] RFC6204bis-07

 


>Following IMVHO: We go into great detail on address ass= ignment in 6204bis, but miss the obvious statement that a CE device needs to be delegated enough >addresses so that it can assign a = /64 per LAN in order for 6204bis to work as designed. v6ops WG shouldn't en= courage SP's who ignore BCP (by assigning a >single /64 to an end site) = to continue such practices without a very good >reason, and that reason has not been presented. I= think RFC6177 is required >for 6204bis to work as designed, and is thus normative.

OK.  I agree using a /64 in the LAN = is something the IETF should discourage. 


>Suggestion: RFC6204bis refer to BCP 157 (RFC6177) as a normative refere= nce.

Taken.  Will add the n= ormative reference.

Thanks much,

 

Hemant

--_000_2D09D61DDFA73D4C884805CC7865E6110724B2GAALPA1MSGUSR9NIT_-- From shemant@cisco.com Fri Mar 16 14:42:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740E521F86C7 for ; Fri, 16 Mar 2012 14:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.093 X-Spam-Level: X-Spam-Status: No, score=-10.093 tagged_above=-999 required=5 tests=[AWL=0.505, 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 pre+pUSFGdhc for ; Fri, 16 Mar 2012 14:42:38 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9326821F86C2 for ; Fri, 16 Mar 2012 14:42:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10052; q=dns/txt; s=iport; t=1331934158; x=1333143758; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=0rfTxjcqmLDVbJjtpdeKzcVIzigfInRMRZJd4UE3MSc=; b=bpNU05b8Xg1EVqJQf+eekhGmwChBCgRueAo5G34G/feZf2SvRoNMgMh+ gRiCCLEgQ02nNYmqNwOYNvcYqYFef4yhKUKJgalF4xjqL/dsuNX6Sdpm8 TUfOnXgfOURMvRFCwQdRGXQPUO6pg0yUj+E+z4xrE5BUUHTXIuSNEljZ1 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAFezY0+tJV2Y/2dsb2JhbABCgkazdIEHggkBAQEEEgEJEQNJEAIBCBEEAQELBhcBBgFFCQgCBAESCBcDh2iaSp8mkBpjBIhWm0+BaIME X-IronPort-AV: E=Sophos;i="4.73,599,1325462400"; d="scan'208,217";a="64150247" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 16 Mar 2012 21:42:34 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2GLgXSb002773; Fri, 16 Mar 2012 21:42:33 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Mar 2012 16:42:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD03BD.B221D5B8" Date: Fri, 16 Mar 2012 16:42:33 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A2270@XMB-RCD-109.cisco.com> In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6110724B2@GAALPA1MSGUSR9N.ITServices.sbc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] RFC6204bis-07 Thread-Index: AQHNA0xPemVwT4EJL0Czamf26OPXRJZtFXaAgABVglCAAAgZYA== References: <867F4B6A1672E541A94676D556793ACD0EB995043C@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C3042FEBDB@XMB-RCD-109.cisco.com><4F61E53D.4050904@globis.net><5B6B2B64C9FE2A489045EEEADDAFF2C3043A1C75@XMB-RCD-109.cisco.com><4F62F576.3070209@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1FB5@XMB-RCD-109.cisco.com> <2D09D61DDFA73D4C884805CC7865E6110724B2@GAALPA1MSGUSR9N.ITServices.sbc.com> From: "Hemant Singh (shemant)" To: "STARK, BARBARA H" , "Ray Hunter" X-OriginalArrivalTime: 16 Mar 2012 21:42:33.0868 (UTC) FILETIME=[B24C9CC0:01CD03BD] Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 21:42:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD03BD.B221D5B8 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Does the new text work because the IETF does want to discourage a /64 delegated prefix to the CE and Ray would like RFC 6177 referenced? I personally do not like adding a specific prefix length to the bullet but then how else is the IETF going to discourage CE routers using a /64? =20 =20 WPD-4: The IPv6 CE router MUST be prepared to accept a delegated prefix size different from what is given in the hint. If the delegated prefix is too small to address all of its interfaces or not shorter than a /64, the IPv6 CE router=20 SHOULD log a system management error. [RFC6177] provides=20 guidance for a shorter than /64 delegated prefix on the CE router. =20 Hemant =20 From: STARK, BARBARA H [mailto:bs7652@att.com]=20 Sent: Friday, March 16, 2012 5:15 PM To: Hemant Singh (shemant); Ray Hunter Cc: v6ops@ietf.org Subject: RE: [v6ops] RFC6204bis-07 =20 No. IMO this is not a good thing to do. This is a CE router spec. It is not, nor will it ever be, an access network spec.=20 =20 My interpretation of this suggestion is "well, maybe if we require the world around the CE router to be perfect, then the CE router won't ever be faced with imperfections." What a lovely world that would be. And thoroughly unrealistic. The CE router and the IETF have zero control over the access network that the CE router finds itself in. The goal needs to be to make the CE router reasonably robust, to handle a variety of situations. My tea leaf reading says that no matter how hard or how often the IETF tries to dictate to access network providers what the IETF thinks providers should do, there will always be those providers who ignore the IETF. Live with it. Deal with it. And the CE router needs to deal with it, too. That's reality. =20 Again. This is a CE router spec. The proposal does not place any additional requirement on the CE router. A normative reference for the CE router to ensure that the access network always provides something bigger than a /64 is meaningless and useless. Barbara ------_=_NextPart_001_01CD03BD.B221D5B8 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Does the new text work because the IETF does want to = discourage a /64 delegated prefix to the CE and Ray would like RFC 6177 = referenced?  I personally do not like adding a specific prefix = length to the bullet but then how else is the IETF going to discourage = CE routers using a /64? 

 

WPD-4:  The IPv6 CE router MUST be prepared to = accept a delegated

         = ;  prefix size different from what is given in the hint.  If = the

         = ;  delegated prefix is too small to address all of = its

         = ;  interfaces or not shorter than a /64, the IPv6 CE router =

         = ;  SHOULD log a system management error.  [RFC6177] =  provides

         = ;  guidance for a shorter than /64 delegated prefix on the CE = router.

 

Hemant

 

From: STARK, BARBARA H [mailto:bs7652@att.com]
Sent: Friday, = March 16, 2012 5:15 PM
To: Hemant Singh (shemant); Ray = Hunter
Cc: v6ops@ietf.org
Subject: RE: [v6ops] = RFC6204bis-07

 

No. IMO this is not a good thing to do. This is a CE router spec. It = is not, nor will it ever be, an access network spec. =

 

My interpretation of this suggestion is “well, maybe if we = require the world around the CE router to be perfect, then the CE router = won’t ever be faced with imperfections.” What a lovely world = that would be. And thoroughly unrealistic. The CE router and the IETF = have zero control over the access network that the CE router finds = itself in. The goal needs to be to make the CE router reasonably robust, = to handle a variety of situations. My tea leaf reading says that no = matter how hard or how often the IETF tries to dictate to access network = providers what the IETF thinks providers should do, there will always be = those providers who ignore the IETF. Live with it. Deal with it. And the = CE router needs to deal with it, too. That’s = reality.

 

Again. This is a CE router spec. The proposal does not place any = additional requirement on the CE router. A normative reference for the = CE router to ensure that the access network always provides something = bigger than a /64  is meaningless and = useless.

Barbara

------_=_NextPart_001_01CD03BD.B221D5B8-- From Francis.Dupont@fdupont.fr Fri Mar 16 14:47:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321E221F8745 for ; Fri, 16 Mar 2012 14:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 IgnQr9IUWUlc for ; Fri, 16 Mar 2012 14:47:20 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 2B4FB21F8729 for ; Fri, 16 Mar 2012 14:47:19 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2GLlFcU073499; Fri, 16 Mar 2012 22:47:15 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203162147.q2GLlFcU073499@givry.fdupont.fr> From: Francis Dupont To: "Hemant Singh (shemant)" In-reply-to: Your message of Thu, 15 Mar 2012 18:44:56 EST. <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1F3E@XMB-RCD-109.cisco.com> Date: Fri, 16 Mar 2012 22:47:15 +0100 Sender: Francis.Dupont@fdupont.fr Cc: v6ops@ietf.org, Alain Durand , "Dan Wang \(danwan\)" , Dave Thaler Subject: Re: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 21:47:21 -0000 In your previous mail you wrote: > >=> as it is in a SHOULD body you can't keep it so loose. > > Could you please provide tighter text? > > >=> I can't see where this level of details will go (*), IMHO if you > >want to keep a SHOULD for PCP (and I am strongly opposed to this) you > >need to cite the base spec, the ds-lite application and the server > >discovery documents. > > Pcp-base is cited. Please point us to documents for ds-lite application > and the server discovery. Since you had trouble reading the new PCP > text because the text was combined with review comments, I have shown > the new text for PCP in rfc6204bis below. Please review. > > The WAN interface of the CE router SHOULD support a PCP client => I am still strongly opposed to this SHOULD for PCP. For the other comments I'll consider this is nevertheless kept. > as specified in [I-D.ietf-pcp-base] for use by applications on the CE > Router. This document takes no position on whether such > functionality is enabled by default or mechanisms by which users > would configure the functionality. > > The PCP client SHOULD follow the procedure specified in Section > 8.1 of [I-D.ietf-pcp-base] to discover its PCP server. => I am not convinced 8.1 is enough but if the PCP WG doesn't propose something better for a CPE we could keep this. > In DS-Lite context, if PCP messages are exchanged using native > IPv6 (i.e., IPv4-in-IPv6 is not used) and no PCP server is > configured, the PCP client MUST use the address of the AFTR as > its PCP server. => it is bad, I propose: > In DS-Lite context, the procedure of [I-D.dupont-pcp-dslite] MUST > be applied. > Handling PCP requests from PCP clients in the LAN side of the CE > Router is out of scope. => again there is no reason to restrict this to PCP: we should describe the function we want and give PCP (or better PCP and UPnP IGD) as examples of protocols providing it. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Fri Mar 16 15:04:36 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925F421F85B1 for ; Fri, 16 Mar 2012 15:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 S2KmDEeZYSwB for ; Fri, 16 Mar 2012 15:04:36 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id B01EA21F85A3 for ; Fri, 16 Mar 2012 15:04:35 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2GM4XuB074929; Fri, 16 Mar 2012 23:04:33 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203162204.q2GM4XuB074929@givry.fdupont.fr> From: Francis Dupont To: mohamed.boucadair@orange.com In-reply-to: Your message of Fri, 16 Mar 2012 08:24:40 +0100. <94C682931C08B048B7A8645303FDC9F36E285577F1@PUEXCB1B.nanterre.francetelecom.fr> Date: Fri, 16 Mar 2012 23:04:33 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "v6ops@ietf.org" , Alain Durand , "Dan Wang \(danwan\)" , Dave Thaler Subject: Re: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 22:04:36 -0000 In your previous mail you wrote: > The current text specifies the client counterpart of REQ#10 > http://tools.ietf.org/html/draft-ietf-behave-lsn-requirements-05. => ah, a requirement from the WG which documents from are clearly ignored in the real world (:-)? > Which other protocols you want to include? => UPnP IGD as another example (and please cite the v2 spec) Regards Francis.Dupont@fdupont.fr From jhw@apple.com Fri Mar 16 15:07:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED62921E802D for ; Fri, 16 Mar 2012 15:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.325 X-Spam-Level: X-Spam-Status: No, score=-110.325 tagged_above=-999 required=5 tests=[AWL=0.274, 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 70az4cIoiJR9 for ; Fri, 16 Mar 2012 15:07:34 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id DD1A621E801A for ; Fri, 16 Mar 2012 15:07:34 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay17.apple.com ([17.128.113.18]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0M1000HAV01470P2@mail-out.apple.com> for v6ops@ietf.org; Fri, 16 Mar 2012 15:07:20 -0700 (PDT) X-AuditID: 11807112-b7cf2ae000006cde-4e-4f63b998b8ac Received: from kallisti.apple.com (kallisti.apple.com [17.193.13.64]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by relay17.apple.com (Apple SCV relay) with SMTP id 40.EE.27870.899B36F4; Fri, 16 Mar 2012 15:07:20 -0700 (PDT) From: james woodyatt In-reply-to: <201203162204.q2GM4XuB074929@givry.fdupont.fr> Date: Fri, 16 Mar 2012 15:07:19 -0700 Message-id: <6C7736F2-5290-4938-8A2C-1B1A6E1A1E13@apple.com> References: <201203162204.q2GM4XuB074929@givry.fdupont.fr> To: IPv6 Ops WG X-Mailer: Apple Mail (2.1443) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmluLIzCtJLcpLzFFi42IRPMjroDtjZ7K/wfV2dovTx/YyOzB6LFny kymAMYrLJiU1J7MstUjfLoErY9qvHUwF55kqZt1UamBsY+pi5OSQEDCRWPJgIiuELSZx4d56 ti5GLg4hgdlMEsu/zGQHSTALaEtMmjsBKMHBwSugJzFlrhBIWFjAQWLnxH3MIDabgIrEt8t3 wWZyClhLXLr6AizOIqAq8WbfQhaYMcsWvgaL8wrYSOzc/RbMFhKwkjh/cRXYKhEBBYkd/3dC 3SYrcWzLY5YJjHyzkFwxC+GKWUimLmBkXsUoWJSak1hpaK6XWFCQk6qXnJ+7iREURA2FQjsY 7+/SO8QowMGoxMMb0Z3sL8SaWFZcmXuIUYKDWUmEN3s+UIg3JbGyKrUoP76oNCe1+BCjNAeL kjjv9E1AKYH0xJLU7NTUgtQimCwTB6dUAyOzzKzTti4mx24cOsXPO83H85eb5J8ZK+9KeS2a EHqJ7yfrUkflzJXpoUsOr2Lta3NKf53DUpm34nh3B5f9mrVH3//dPiX9wuWM7mapE/OCiliC Zct3XE+SnPuJ5+yRxB/bn+oeTvVcI3J/U1t148GXN9KPz3dSNVy7Y27YO2fZWTtNDn+Ieb5K iaU4I9FQi7moOBEAjOPZYB4CAAA= Subject: Re: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 22:07:36 -0000 On Mar 16, 2012, at 15:04 , Francis Dupont wrote: > > UPnP IGD as another example (and please cite the v2 spec) We can't cite that spec as a normative reference. Only as an *informative* reference. -- james woodyatt member of technical staff, core os networking From shemant@cisco.com Fri Mar 16 16:44:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CB0021E808C for ; Fri, 16 Mar 2012 16:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.106 X-Spam-Level: X-Spam-Status: No, score=-10.106 tagged_above=-999 required=5 tests=[AWL=0.493, 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 MamM4OXceE4s for ; Fri, 16 Mar 2012 16:44:01 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id C0D0C21E808A for ; Fri, 16 Mar 2012 16:44:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=946; q=dns/txt; s=iport; t=1331941442; x=1333151042; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=npskFas59pM8RxEVSdha6abHWDXJvsn6N4068WUoP2o=; b=kU5Z7lyAVtuToi0zMJkKnrWIk/3sOrY41SQSZX/DZU6BTsCLexZ7hHxA pTWid4UxSlXi1HtEjwyUm3rJCjeLyf4zHDPjmtH7KO/uhQjEUw6DpBIfX OIUngFchsPBXK/qzx1luXjqog3AiIdOGidIr3MURJYyv9GdGuGa4cyczs o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPPOY0+tJXHB/2dsb2JhbABCtj+BB4IJAQEBAwESAR0KPwUHBAIBCBABBAEBCwYXAQYBRQgBCAEBBBMIGodjBZpbnyaNV4I/YwSIVptPgWiDBIE+ X-IronPort-AV: E=Sophos;i="4.73,601,1325462400"; d="scan'208";a="67190571" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 16 Mar 2012 23:44:01 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id q2GNi1Pn028572; Fri, 16 Mar 2012 23:44:01 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Mar 2012 18:44:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 16 Mar 2012 18:43:48 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A22A3@XMB-RCD-109.cisco.com> In-Reply-To: <201203162147.q2GLlFcU073499@givry.fdupont.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) Thread-Index: Ac0DvlyZFc8+KvWETI6mYnH5h7jyXwAD61Iw References: Your message of Thu, 15 Mar 2012 18:44:56 EST. <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1F3E@XMB-RCD-109.cisco.com> <201203162147.q2GLlFcU073499@givry.fdupont.fr> From: "Hemant Singh (shemant)" To: X-OriginalArrivalTime: 16 Mar 2012 23:44:01.0432 (UTC) FILETIME=[AA06A180:01CD03CE] Cc: v6ops@ietf.org, Alain Durand , "Dan Wang \(danwan\)" , Dave Thaler Subject: Re: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 23:44:03 -0000 Francis, -----Original Message----- From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]=20 Sent: Friday, March 16, 2012 5:47 PM To: Hemant Singh (shemant) Cc: v6ops@ietf.org; Alain Durand; Dan Wang (danwan); Dave Thaler Subject: Re: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC)=20 > In DS-Lite context, the procedure of [I-D.dupont-pcp-dslite] MUST > be applied. The IPv6 CE router document can only add a technology in RFC form and the above document is not an RFC. In rare exceptions the rfc6204bis accepts a draft but the draft should be in the IESG. The above document is not in the IESG either. Thus we will have to settle for the text already proposed. Also, I am very sorry, I have a hard time reading your email because I do not understand the delimiters for what is old vs. new text. I will try again carefully and see if I can reply further. Thanks and regards, Hemant From shemant@cisco.com Fri Mar 16 16:46:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D602D21E808F for ; Fri, 16 Mar 2012 16:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.117 X-Spam-Level: X-Spam-Status: No, score=-10.117 tagged_above=-999 required=5 tests=[AWL=0.481, 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 zStXwGdKobSb for ; Fri, 16 Mar 2012 16:46:59 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B913421E808A for ; Fri, 16 Mar 2012 16:46:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=5209; q=dns/txt; s=iport; t=1331941619; x=1333151219; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=TiqaHs4HVKsfKa2KInNCBvRqHjQyfUgCsBOnD49AMqg=; b=DJT4O3Lm2z8HzOrI3/cbu+IX1qmSFecSR51ix0MNWOLeGnxS20fssk17 F+i0V9Q2wQPSrbr1cvZ0EfY2yKX+uzz3zN4MHkVfOwrdWY+e/AF7s1UP/ 8wWShgB4cW9fn9FohYq73FdPz8kAHURy++EU4Qfa6t+c8fmyQ65kiwuRY k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHPPY0+tJXG//2dsb2JhbABCgkazeYEHggkBAQEDARIBCREDTgcEAgEIEAEEAQELBhcBBgFFCAEIAQEEARIIGodjBZpbnyaKQYVVYwSIVptPgWiDBIE2 X-IronPort-AV: E=Sophos;i="4.73,601,1325462400"; d="scan'208,217";a="66978589" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 16 Mar 2012 23:46:58 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2GNkwQu016441; Fri, 16 Mar 2012 23:46:58 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 16 Mar 2012 18:46:58 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD03CF.1352F6F8" Date: Fri, 16 Mar 2012 18:46:51 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A22A5@XMB-RCD-109.cisco.com> In-Reply-To: <6C7736F2-5290-4938-8A2C-1B1A6E1A1E13@apple.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) Thread-Index: Ac0DwTcjYzhiMsc8SROELvjBHy2qGAADX/5g References: <201203162204.q2GM4XuB074929@givry.fdupont.fr> <6C7736F2-5290-4938-8A2C-1B1A6E1A1E13@apple.com> From: "Hemant Singh (shemant)" To: "james woodyatt" , "IPv6 Ops WG" X-OriginalArrivalTime: 16 Mar 2012 23:46:58.0292 (UTC) FILETIME=[13715340:01CD03CF] Subject: Re: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 23:47:00 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD03CF.1352F6F8 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable =20 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of james woodyatt Sent: Friday, March 16, 2012 6:07 PM To: IPv6 Ops WG Subject: Re: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) =20 >>On Mar 16, 2012, at 15:04 , Francis Dupont wrote: >>=20 >> UPnP IGD as another example (and please cite the v2 spec) =20 > We can't cite that spec as a normative reference. Only as an *informative* reference. =20 Sorry, we only agreed to limited PCP requirement to add to the IPv6 CE router document. UPnP is a new requirement that is hard to add during the LastCall of the document. Could we consider UPnP for rfc6204ter? =20 Thanks, =20 Hemant =20 ------_=_NextPart_001_01CD03CF.1352F6F8 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

 

-----Original Message-----
From: v6ops-bounces@ietf.org = [mailto:v6ops-bounces@ietf.org] On Behalf Of james woodyatt
Sent: = Friday, March 16, 2012 6:07 PM
To: IPv6 Ops WG
Subject: Re: = [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis = WGLC)

 

>>On Mar 16, 2012, at 15:04 , Francis Dupont = <Francis.Dupont@fdupont.fr> wrote:

>> =

>> UPnP IGD as another example = (and please cite the v2 spec)

 

> We can't cite that spec as a = normative reference.  Only as an *informative* = reference.

 

Sorry, we only agreed to = limited PCP requirement to add to the IPv6 CE router document.  = UPnP is a new requirement that is hard to add during the LastCall of the = document.  Could we consider UPnP for = rfc6204ter?

 

Thanks,

 

Hemant

 

------_=_NextPart_001_01CD03CF.1352F6F8-- From xing@cernet.edu.cn Sat Mar 17 06:41:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B8621F867B for ; Sat, 17 Mar 2012 06:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 1ppg+bx+rA-z for ; Sat, 17 Mar 2012 06:41:36 -0700 (PDT) Received: from cernet.edu.cn (cernet.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 9499721F867A for ; Sat, 17 Mar 2012 06:41:34 -0700 (PDT) Received: from [127.0.0.1] (unknown [125.34.53.93]) by centos (Coremail) with SMTP id AQAAf3BLcQOQk2RPyQcSAA--.8161S2; Sat, 17 Mar 2012 21:37:38 +0800 (CST) Message-ID: <4F649442.3090705@cernet.edu.cn> Date: Sat, 17 Mar 2012 21:40:18 +0800 From: Xing Li User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Cameron Byrne References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-CM-TRANSID: AQAAf3BLcQOQk2RPyQcSAA--.8161S2 X-Coremail-Antispam: 1UD129KBjvJXoW3XrWDAFykuryxZrWDJFykuFg_yoW7Wr1xpa yFqFs0kr4kGFy0k3yvqw1rXa4F9rWfJ343ZF13t34DuFZxKFy7WF4xAw4a9FyUXr1rGF12 vrWUGFW3X3WUXw7anT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUhCb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28EF7xvwVC0I7IYx2 IY67AKxVWUJVWUCwA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwA2z4x0Y4vEx4A2 jsIE14v26r4j6F4UM28EF7xvwVC2z280aVCY1x0267AKxVW8JVW8Jr1le2I262IYc4CY6c 8Ij28IcVAaY2xG8wAqx4xG64xvF2IEw4CE5I8CrVC2j2WlYx0Ex4A2jsIE14v26r1j6r4U McvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwCYjI0SjxkI62AI1cAE67vIY487Mx kIecxEwVAFwVW5GwCF04k20xvY0x0EwIxGrwC20s026c02F40E14v26r1j6r18MI8I3I0E 7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkvb40EIxkG14v26r4j6r yUMIIYrxkI7VAKI48JMIIF0xvE42xK8VAvwI8IcIk0rVWrJr0_WFyUJwCI42IY6I8E87Iv 67AKxVW8JVWxJwCI42IY6I8E87Iv6xkF7I0E14v26r4j6r4UJbIYCTnIWIevJa73UjIFyT uYvjxUgM5lDUUUU X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/ Cc: IPv6 Ops WG Subject: Re: [v6ops] 464XLAT Trial Deployment Report X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 13:41:37 -0000 Hi, Cameron, > No, i disagree. The MAP work seems to be a "design by committee" and > the 464XLAT is more of a ground-up "solve for x", where x is whatever > it takes to make IPv6-only networks have service parity with IPv4-only > status quo networks. And, it works today. I sent the deployment > report showing 100% service parity with IPv4 on Android phones, no one > has challenged those results. The MAP work has solid roots. For example, MAP-T is a new name of dIVI. The dIVI has been running at CERNET2 for more than two years and it has also been tested at China Telecoms network. Some references are: http://tools.ietf.org/html/draft-xli-behave-divi-04 http://tools.ietf.org/id/draft-sunq-v6ops-ivi-sp-02.txt Regards, xing > > In all honesty, i turned my own nose up at NAT46 on the handset at > first. I had the same perspective as James Woodyatt, those IPv4-only > apps will get their just desserts.... But, then the folks on this > board changed my mind http://talk.maemo.org/showthread.php?t=60320 > They solved their own problems with NAT46 on the handset, and it > worked. > > I can't argue with results and running code. > > CB > >> Regards, >> Wojciech >> >> >> On 3 February 2012 21:17, Cameron Byrne wrote: >>> Hi, >>> >>> I have recently concluded a simple initial experimental deployment >>> 464XLAT [1] on the T-Mobile USA IPv6-only network [2] using an Android >>> Nexus S phone. >>> >>> The high level summary is that a sample of the top ~200 free Android >>> apps that use network services (ie not a calculator with no ads), >>> ~85+% work on an IPv6-only DNS64/NAT64 mobile UMTS network using a >>> stock Android 4.0 (ICS) on a stock Nexus S phone. >>> >>> When using custom 464XLAT code [3] on Android, 100% of the ~15% of >>> apps that failed in the initial test now work. The 464XLAT CLAT code >>> on the Android allowed for IPv4 socket bindings and IPv4 referrals to >>> proceed on the IPv6-only network by doing RFC 6145 protocol >>> translation locally on the phone. The tested application sample set >>> is at [4]. >>> >>> I believe this simple experiment running real code on a real network >>> shows the value of draft-mawatari-v6ops-464xlat for enabling network >>> operators to embrace IPv6-only networks as the going forward future of >>> access networks. 464XLAT, like NAT64/DNS64, is a bridge technology >>> that makes IPv6 deployment feasible without harming the customer >>> experience. 464XLAT, like DNS64/NAT64, is not used when apps and >>> service are IPv6 native. Thus, as IPv6 deployment progresses across >>> the Internet, the 464XLAT as well as the NAT64/DNS64 fall out of >>> service. >>> >>> I hope the problem statement that draft-mawatari-v6ops-464xlat >>> addresses is clear as it applies to this trial: 15% of applications >>> for this sample in the Android market require IPv4 addresses. >>> >>> And, i hope the proposed applicability and usefulness of 464XLAT is >>> clear as it applies to this trial: 464XLAT allows for 100% >>> functionality of all applications in the sample and is only used when >>> IPv4 sockets are required (IPv4 literals, IPv4 referrals, ...). >>> >>> I do have 2 requests of the group. First, please read and comment on >>> draft-mawatari-v6ops-464xlat [1]. We are looking for working group >>> adoption of this draft since we believe it will broadly support the >>> ability of network operators to move forward with IPv6 in the near >>> term (code is running, network is deployed). Right now, some networks >>> feel they are held back by "IPv6 spoilers" like Skype that require >>> IPv4. But now, even Skype works on IPv6 with the help of 464XLAT :) . >>> I would like to emphasize that Skype and others MUST still deploy and >>> support IPv6. That said, we cannot let their failure hold the rest of >>> us back. Second, the IPv4 exhaustion problem is real and now, the >>> urgency must be high. Please also comment to the folks at Android >>> that this code should be brought into the Android main line >>> distribution because network operators (v6ops) need it to continue >>> growing the Internet and restoring the end-to-end principle [5]. >>> >>> Thanks, >>> >>> Cameron >>> >>> ps. Big thanks to Dan Drown for open-sourcing his CLAT code! >>> >>> >>> [1] http://tools.ietf.org/html/draft-mawatari-v6ops-464xlat >>> >>> [2] http://goo.gl/HGmsy or >>> https://sites.google.com/site/tmoipv6/lg-mytouch >>> >>> [3] http://code.google.com/p/android-clat/ and >>> http://dan.drown.org/android/clat/ and >>> >>> [4] http://goo.gl/z3j3q or >>> >>> https://docs.google.com/spreadsheet/ccc?key=0AnVbRg3DotzFdGVwZWlWeG5wXzVMcG5qczZEZloxWGc >>> >>> [5] http://goo.gl/W55YQ or http >>> >>> ://www.androidpolice.com/2012/01/29/t-mobile-usa-testing-ipv6-on-select-devices-here-is-what-it-all-means-and-yes-no-more-nat/ >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From fred@cisco.com Sat Mar 17 06:55:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF67621F867B for ; Sat, 17 Mar 2012 06:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.099 X-Spam-Level: X-Spam-Status: No, score=-110.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 yUfOb1dgNR0d for ; Sat, 17 Mar 2012 06:55:01 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 42E0D21F867A for ; Sat, 17 Mar 2012 06:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=130; q=dns/txt; s=iport; t=1331992501; x=1333202101; h=date:from:message-id:to:subject:cc; bh=VZgJHp9oxcAzI0zBCaUfmmD1gZrw9/OlCclkZZiXdwE=; b=RtDyY726of3aWXD/iIjAF/YwDBL0IwPONDkX0s9F3Eblsh8W/1FDXrQA fCN5JMBVqViDnsiSmSB1r4Mb8hEdpndERllFN+/nZsT7yiyQG2wHgjGMY AgK08a9Re2s1+baFjTEwG9CMLt/2KqaaeY9lBM7bAhCx2lh/R4M208iyh M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcIALOWZE+rRDoJ/2dsb2JhbABCpSoBkRWBB4IiAWY8LYEKh2cMmxWedI1agj9jBIhWm1KBaIMG X-IronPort-AV: E=Sophos;i="4.73,602,1325462400"; d="scan'208";a="33976148" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 17 Mar 2012 13:55:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2HDt0rH015461; Sat, 17 Mar 2012 13:55:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id q2HDt0D29526; Sat, 17 Mar 2012 06:55:00 -0700 (PDT) Date: Sat, 17 Mar 2012 06:55:00 -0700 (PDT) From: Message-Id: <201203171355.q2HDt0D29526@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-ma-v6ops-terminal-test@tools.ietf.org Subject: [v6ops] new draft: draft-ma-v6ops-terminal-test X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 13:55:02 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-ma-v6ops-terminal-test. Please take a look at it and comment. From fred@cisco.com Sat Mar 17 06:55:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED00821F867C for ; Sat, 17 Mar 2012 06:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.155 X-Spam-Level: X-Spam-Status: No, score=-110.155 tagged_above=-999 required=5 tests=[AWL=0.444, 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 DeT4Tlf3CuIX for ; Sat, 17 Mar 2012 06:55:01 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3B27F21F8673 for ; Sat, 17 Mar 2012 06:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=137; q=dns/txt; s=iport; t=1331992501; x=1333202101; h=date:from:message-id:to:subject:cc; bh=hEhiXt3aQDTGzGwWXWrIq7bo2YQLTfh1ygjB8zEzhLg=; b=LOOkEu5xqdh+LR14atKCa8ULPotSIXRoP9a1cEmy5OvDR6hn4/s4C3Sv +cAyTY5EhRNxPb5hfyjRMZk9+c0iPr52MQe8HS03StKva1IO3ilKF9VrP due3fGp848uVFl5lGtUdcsjZ6YkEzhkk8DKbvP9B6Qy9Obrvh7GLwBcgB U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcIAOiWZE+rRDoI/2dsb2JhbABCpSoBkRWBB4IiAWY8LYEKh2cMmxWedI1agyIEiFabUoFogwY X-IronPort-AV: E=Sophos;i="4.73,602,1325462400"; d="scan'208";a="36461149" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-4.cisco.com with ESMTP; 17 Mar 2012 13:55:00 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2HDt0L1001165; Sat, 17 Mar 2012 13:55:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id q2HDt0Q29532; Sat, 17 Mar 2012 06:55:00 -0700 (PDT) Date: Sat, 17 Mar 2012 06:55:00 -0700 (PDT) From: Message-Id: <201203171355.q2HDt0Q29532@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-townsley-v6ops-6rd-sunsetting@tools.ietf.org Subject: [v6ops] new draft: draft-townsley-v6ops-6rd-sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 13:55:02 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-townsley-v6ops-6rd-sunsetting. Please take a look at it and comment. From fred@cisco.com Sat Mar 17 06:55:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0438B21F8680 for ; Sat, 17 Mar 2012 06:55:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.199 X-Spam-Level: X-Spam-Status: No, score=-110.199 tagged_above=-999 required=5 tests=[AWL=0.400, 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 z6AYtCi+6N7x for ; Sat, 17 Mar 2012 06:55:01 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 42B5521F8674 for ; Sat, 17 Mar 2012 06:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=132; q=dns/txt; s=iport; t=1331992501; x=1333202101; h=date:from:message-id:to:subject:cc; bh=+y1yWr33+jhFoEPzP1FEBUjWG8saSeVR7KUKJ4MGGog=; b=P/Y1tIdoFs7JAhKcYuG1cWwzM37GoojflZOVd/7TKAQGbDQp58exHuH8 M+Uozr/8ZtXO1THpX3czMwFSsw9FE2lzKKLB2+r1hfIQQkPt/RiAO46E+ fCm/RXbOPfLq+8BTyDc7dasud7Lg7k47qR4IskRHPf03jXSgf2mg812xD M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcIABiXZE+rRDoG/2dsb2JhbABCpSoBkRWBB4IiAWY8LYEKh2cMmxeedI1agyIEiFabUoFogwY X-IronPort-AV: E=Sophos;i="4.73,602,1325462400"; d="scan'208";a="33438237" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 17 Mar 2012 13:55:00 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2HDt0wQ001696; Sat, 17 Mar 2012 13:55:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id q2HDt0s29520; Sat, 17 Mar 2012 06:55:00 -0700 (PDT) Date: Sat, 17 Mar 2012 06:55:00 -0700 (PDT) From: Message-Id: <201203171355.q2HDt0s29520@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-jiang-v6ops-v4v6mc-proxy@tools.ietf.org Subject: [v6ops] new draft: draft-jiang-v6ops-v4v6mc-proxy X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 13:55:02 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-jiang-v6ops-v4v6mc-proxy. Please take a look at it and comment. From Francis.Dupont@fdupont.fr Sat Mar 17 06:55:22 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFCD121F86B4 for ; Sat, 17 Mar 2012 06:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 Qi5DqwWdIc0B for ; Sat, 17 Mar 2012 06:55:22 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id C6DFA21F867A for ; Sat, 17 Mar 2012 06:55:21 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2HDtHAP033373; Sat, 17 Mar 2012 14:55:17 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203171355.q2HDtHAP033373@givry.fdupont.fr> From: Francis Dupont To: james woodyatt In-reply-to: Your message of Fri, 16 Mar 2012 15:07:19 MST. <6C7736F2-5290-4938-8A2C-1B1A6E1A1E13@apple.com> Date: Sat, 17 Mar 2012 14:55:17 +0100 Sender: Francis.Dupont@fdupont.fr Cc: IPv6 Ops WG Subject: Re: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 13:55:22 -0000 In your previous mail you wrote: > On Mar 16, 2012, at 15:04 , Francis Dupont wrote: > > > > UPnP IGD as another example (and please cite the v2 spec) > > We can't cite that spec as a normative reference. Only as an *informative* reference. => example implies informative reference (so we should agree) Thanks Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Sat Mar 17 07:06:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0CC21F8670 for ; Sat, 17 Mar 2012 07:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 kgROnZvKQ2mc for ; Sat, 17 Mar 2012 07:06:39 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 6491C21F8629 for ; Sat, 17 Mar 2012 07:06:39 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2HE6aL1034245; Sat, 17 Mar 2012 15:06:36 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203171406.q2HE6aL1034245@givry.fdupont.fr> From: Francis Dupont To: "Hemant Singh (shemant)" In-reply-to: Your message of Fri, 16 Mar 2012 18:43:48 EST. <5B6B2B64C9FE2A489045EEEADDAFF2C3043A22A3@XMB-RCD-109.cisco.com> Date: Sat, 17 Mar 2012 15:06:36 +0100 Sender: Francis.Dupont@fdupont.fr Cc: v6ops@ietf.org, Alain Durand , "Dan Wang \(danwan\)" , Dave Thaler Subject: Re: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 14:06:40 -0000 In your previous mail you wrote: > > In DS-Lite context, the procedure of [I-D.dupont-pcp-dslite] MUST > > be applied. > > The IPv6 CE router document can only add a technology in RFC form and > the above document is not an RFC. In rare exceptions the rfc6204bis > accepts a draft but the draft should be in the IESG. The above document > is not in the IESG either. => I understand your concern but if the PCP is referenced only as an example (cf homenet-arch, with UPnP IGD) then: - it can go to informative references - only the base-spec should be cited so it solves the problem and even more. > Thus we will have to settle for the text already proposed. Also, I am > very sorry, I have a hard time reading your email because I do not > understand the delimiters for what is old vs. new text. I will try > again carefully and see if I can reply further. => perhaps my MUA config junked again: old text is supposed to get "> " before, and I manually add "=> " before the text I type. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Sat Mar 17 07:10:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F75921F85D6 for ; Sat, 17 Mar 2012 07:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 3ydbwZHYP4MU for ; Sat, 17 Mar 2012 07:10:55 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 19D0721F8577 for ; Sat, 17 Mar 2012 07:10:50 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2HEAkMr034492; Sat, 17 Mar 2012 15:10:46 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203171410.q2HEAkMr034492@givry.fdupont.fr> From: Francis Dupont To: "Hemant Singh (shemant)" In-reply-to: Your message of Fri, 16 Mar 2012 18:46:51 EST. <5B6B2B64C9FE2A489045EEEADDAFF2C3043A22A5@XMB-RCD-109.cisco.com> Date: Sat, 17 Mar 2012 15:10:46 +0100 Sender: Francis.Dupont@fdupont.fr Cc: IPv6 Ops WG Subject: Re: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 14:10:56 -0000 In your previous mail you wrote: > Sorry, we only agreed to limited PCP requirement to add to the IPv6 CE > router document. UPnP is a new requirement that is hard to add during > the LastCall of the document. Could we consider UPnP for rfc6204ter? => you didn't understand: I don't want a requirement for UPnP but a requirement for the *function* with PCP and UPnP IGD as example of protocols providing the function. Quoting draft-ietf-homenet-arch-02.txt as suggested by Tim: ... Applications or hosts wanting to accept inbound connections in networks that are compliant with the architecture presented in this document would then need to signal that desire through a protocol such as UPnP or PCP. so what we need is just a similar text explaining what we want and giving examples about how to get it. Regards Francis.Dupont@fdupont.fr From shemant@cisco.com Sat Mar 17 07:26:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2960421F862B for ; Sat, 17 Mar 2012 07:26:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.139 X-Spam-Level: X-Spam-Status: No, score=-10.139 tagged_above=-999 required=5 tests=[AWL=0.460, 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 g2U4Kp+rxrZC for ; Sat, 17 Mar 2012 07:26:16 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3183F21F85ED for ; Sat, 17 Mar 2012 07:26:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1083; q=dns/txt; s=iport; t=1331994376; x=1333203976; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=mSG9zrpJFcOIhNSKlnF/uSkV+xAVexI8t4nD3kUbKeU=; b=lXhbohlVEsyCZ2OdNqAy+FgBxEXhKw+yM4Do5lkk3wqPBaIh54KUiykL 02BmwTZifc7eZ/lXDPFwOovrPXfQysa58xf8zMUGKOtcYgHGGEH0QWe0I bUz9KbMFRJDzFTlMGW8m0vfBC7uiyyTSaKfvB5vTVdfn9qsbOdsKZ8vzz M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANaeZE+tJXG//2dsb2JhbABCtkCBB4IJAQEBBBIBHQo/DAQCAQgQAQEDAQELBhcBBgFFAwUBCAEBBBMIGodomw6ebY1agj9jBIhWm1KBaIME X-IronPort-AV: E=Sophos;i="4.73,602,1325462400"; d="scan'208";a="67260407" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 17 Mar 2012 14:26:15 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2HEQFJX009657; Sat, 17 Mar 2012 14:26:15 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 17 Mar 2012 09:26:16 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sat, 17 Mar 2012 09:26:13 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A22E9@XMB-RCD-109.cisco.com> In-Reply-To: <201203171410.q2HEAkMr034492@givry.fdupont.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) Thread-Index: Ac0ER8JLT84FFZSTTfi/egHrfCJe5wAAZpnw References: Your message of Fri, 16 Mar 2012 18:46:51 EST. <5B6B2B64C9FE2A489045EEEADDAFF2C3043A22A5@XMB-RCD-109.cisco.com> <201203171410.q2HEAkMr034492@givry.fdupont.fr> From: "Hemant Singh (shemant)" To: X-OriginalArrivalTime: 17 Mar 2012 14:26:16.0091 (UTC) FILETIME=[E98A96B0:01CD0449] Cc: IPv6 Ops WG Subject: Re: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 14:26:17 -0000 Francis, Could you please provide text. Can you please also work with Med on the text for PCP and send one final text that both of you hash out. Thanks and regards, Hemant -----Original Message----- From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]=20 Sent: Saturday, March 17, 2012 10:11 AM To: Hemant Singh (shemant) Cc: james woodyatt; IPv6 Ops WG Subject: Re: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC)=20 =3D> you didn't understand: I don't want a requirement for UPnP but a requirement for the *function* with PCP and UPnP IGD as example of protocols providing the function. Quoting draft-ietf-homenet-arch-02.txt as suggested by Tim: ... Applications or hosts wanting to accept inbound connections in networks that are compliant with the architecture presented in this document would then need to signal that desire through a protocol such as UPnP or PCP. so what we need is just a similar text explaining what we want and giving examples about how to get it. Regards Francis.Dupont@fdupont.fr From v6ops@globis.net Sat Mar 17 12:25:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD43021F855A for ; Sat, 17 Mar 2012 12:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.050, 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 NrXyAEk+G0fL for ; Sat, 17 Mar 2012 12:25:09 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 5B40021F85D2 for ; Sat, 17 Mar 2012 12:25:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 5B12287004D; Sat, 17 Mar 2012 20:25:07 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38GFgcLMxaZY; Sat, 17 Mar 2012 20:25:00 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id AA9F4870021; Sat, 17 Mar 2012 20:25:00 +0100 (CET) Message-ID: <4F64E50C.4010602@globis.net> Date: Sat, 17 Mar 2012 20:25:00 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: "Hemant Singh (shemant)" References: <867F4B6A1672E541A94676D556793ACD0EB995043C@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C3042FEBDB@XMB-RCD-109.cisco.com><4F61E53D.4050904@globis.net><5B6B2B64C9FE2A489045EEEADDAFF2C3043A1C75@XMB-RCD-109.cisco.com><4F62F576.3070209@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1FB5@XMB-RCD-109.cisco.com> <2D09D61DDFA73D4C884805CC7865E6110724B2@GAALPA1MSGUSR9N.ITServices.sbc.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A2270@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A2270@XMB-RCD-109.cisco.com> Content-Type: multipart/alternative; boundary="------------020705060005040602090302" Cc: "v6ops@ietf.org WG" Subject: Re: [v6ops] RFC6204bis-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 19:25:11 -0000 This is a multi-part message in MIME format. --------------020705060005040602090302 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hemant: your suggested text works fine for me. Many thanks. After reading Carl's and Barbara's comments on this requirement carefully, I've also tried to draft alternative text myself for further consideration: WPD-4: The IPv6 CE router MUST be prepared to accept a delegated prefix size different from that given in the hint. If the delegated prefix is too small to address all of its interfaces, or the prefix is not shorter than a /64, the IPv6 CE router * * * *SHOULD assign a separate /64 from its delegated prefix(es) to each of as many of its LAN interfaces as possible, and SHOULD log a system management error. Best Current Practice for IPv6 Address Assignment to End Sites is provided in BCP 157 (RFC6177) [RFC6177]. Idea being that the requirement defines some positive behavior to perform to make the best of this situation (Barbara's "just deal with it" comment), that can be tested for compliance (Carl's comment that no behavior was defined that could be compliance tested and thus this was a redundant requirement), still deprecates single /64 (my concern) without over-stepping what is already generally agreed in BCP157 (Barbara's "A normative reference for the CE router to ensure that the access network always provides something bigger than a /64 is meaningless and useless."), prevents SLAAC being broken by assignment of longer than /64 prefixes on the LAN or some other prefix sharing hack (a lot of people's concern), and does raise an error (your suggestion to do something to alert a human to the undesirable situation) . Feel free to improve, or keep your original proposed text. Thanks, RayH Hemant Singh (shemant) wrote: > > Does the new text work because the IETF does want to discourage a /64 > delegated prefix to the CE and Ray would like RFC 6177 referenced? I > personally do not like adding a specific prefix length to the bullet > but then how else is the IETF going to discourage CE routers using a > /64? 0 > > WPD-4: The IPv6 CE router MUST be prepared to accept a delegated > > prefix size different from what is given in the hint. If the > > delegated prefix is too small to address all of its > > interfaces or *not shorter than a /64*, the IPv6 CE router > > SHOULD log a system management error. [RFC6177] provides > > guidance for a shorter than /64 delegated prefix on the CE > router. > > Hemant > > *From:* STARK, BARBARA H [mailto:bs7652@att.com] > *Sent:* Friday, March 16, 2012 5:15 PM > *To:* Hemant Singh (shemant); Ray Hunter > *Cc:* v6ops@ietf.org > *Subject:* RE: [v6ops] RFC6204bis-07 > > No. IMO this is not a good thing to do. This is a CE router spec. It > is not, nor will it ever be, an access network spec. > > My interpretation of this suggestion is "well, maybe if we require the > world around the CE router to be perfect, then the CE router won't > ever be faced with imperfections." What a lovely world that would be. > And thoroughly unrealistic. The CE router and the IETF have zero > control over the access network that the CE router finds itself in. > The goal needs to be to make the CE router reasonably robust, to > handle a variety of situations. My tea leaf reading says that no > matter how hard or how often the IETF tries to dictate to access > network providers what the IETF thinks providers should do, there will > always be those providers who ignore the IETF. Live with it. Deal with > it. And the CE router needs to deal with it, too. That's reality. > > Again. This is a CE router spec. The proposal does not place any > additional requirement on the CE router. A normative reference for the > CE router to ensure that the access network always provides something > bigger than a /64 is meaningless and useless. > > Barbara > --------------020705060005040602090302 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hemant: your suggested text works fine for me. Many thanks.


After reading Carl's and Barbara's comments on this requirement carefully, I've also tried to draft alternative text myself for further consideration:        

WPD-4:  The IPv6 CE router MUST be prepared to accept a delegated

           prefix size different from that given in the hint.  

           If the delegated prefix is too small to address all of its

           interfaces, or the prefix is not shorter than a /64, the IPv6 CE router

           SHOULD assign a separate /64 from its delegated prefix(es) to each of as many of its LAN interfaces as possible,

           and SHOULD log a system management error.

           Best Current Practice for IPv6 Address Assignment to End Sites is provided in BCP 157 (RFC6177) [RFC6177].

Idea being that the requirement defines some positive behavior to perform to make the best of this situation (Barbara's "just deal with it" comment), that can be tested for compliance (Carl's comment that no behavior was defined that could be compliance tested and thus this was a redundant requirement), still deprecates single /64 (my concern) without over-stepping what is already generally agreed in BCP157 (Barbara's "A normative reference for the CE router to ensure that the access network always provides something bigger than a /64  is meaningless and useless."), prevents SLAAC being broken by assignment of longer than /64 prefixes on the LAN or some other prefix sharing hack (a lot of people's concern), and does raise an error (your suggestion to do something to alert a human to the undesirable situation) .

Feel free to improve, or keep your original proposed text.

Thanks,
RayH

Hemant Singh (shemant) wrote:

Does the new text work because the IETF does want to discourage a /64 delegated prefix to the CE and Ray would like RFC 6177 referenced?  I personally do not like adding a specific prefix length to the bullet but then how else is the IETF going to discourage CE routers using a /64? 0

 

WPD-4:  The IPv6 CE router MUST be prepared to accept a delegated

           prefix size different from what is given in the hint.  If the

           delegated prefix is too small to address all of its

           interfaces or not shorter than a /64, the IPv6 CE router

           SHOULD log a system management error.  [RFC6177]  provides

           guidance for a shorter than /64 delegated prefix on the CE router.

 

Hemant

 

From: STARK, BARBARA H [mailto:bs7652@att.com]
Sent: Friday, March 16, 2012 5:15 PM
To: Hemant Singh (shemant); Ray Hunter
Cc: v6ops@ietf.org
Subject: RE: [v6ops] RFC6204bis-07

 

No. IMO this is not a good thing to do. This is a CE router spec. It is not, nor will it ever be, an access network spec.

 

My interpretation of this suggestion is “well, maybe if we require the world around the CE router to be perfect, then the CE router won’t ever be faced with imperfections.” What a lovely world that would be. And thoroughly unrealistic. The CE router and the IETF have zero control over the access network that the CE router finds itself in. The goal needs to be to make the CE router reasonably robust, to handle a variety of situations. My tea leaf reading says that no matter how hard or how often the IETF tries to dictate to access network providers what the IETF thinks providers should do, there will always be those providers who ignore the IETF. Live with it. Deal with it. And the CE router needs to deal with it, too. That’s reality.

 

Again. This is a CE router spec. The proposal does not place any additional requirement on the CE router. A normative reference for the CE router to ensure that the access network always provides something bigger than a /64  is meaningless and useless.

Barbara


--------------020705060005040602090302-- From shemant@cisco.com Sat Mar 17 15:02:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 095F821F8658 for ; Sat, 17 Mar 2012 15:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.148 X-Spam-Level: X-Spam-Status: No, score=-10.148 tagged_above=-999 required=5 tests=[AWL=0.450, 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 Os8yfZyAjGu0 for ; Sat, 17 Mar 2012 15:02:02 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 97B6921F864A for ; Sat, 17 Mar 2012 15:02:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=12593; q=dns/txt; s=iport; t=1332021721; x=1333231321; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=sWX3PG9gU7Iz1nGP8+aJxJKWQItvfsQZqXcM+e/I1EU=; b=Cs7SIB9+2svp+JJKuoz/CRAGurgxjqUzKJm2IyVW0U0KUB0u3e654XH4 vfrzcdx4nSX+0qcyqupU3qwnnySMGQ1PrpWTIBwcs1P9LizCkgY0yZDhJ Jo+/8L8NoChdrMH+Gi8CmIxjYM13w7SCqw5GXy9wQf6oumz7tYnedKGx0 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAEsIZU+tJXG9/2dsb2JhbABCgkarCwGIb4EHggkBAQEEEgEJEQNJEAIBCA4DBAEBCwYXAQYBRQkIAQEEEwgah2gLmwKePZAZYwSIVptSgWiDBA X-IronPort-AV: E=Sophos;i="4.73,604,1325462400"; d="scan'208,217";a="67095149" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-1.cisco.com with ESMTP; 17 Mar 2012 22:02:01 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2HM21tC006738; Sat, 17 Mar 2012 22:02:01 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 17 Mar 2012 17:02:01 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD0489.946A48E8" Date: Sat, 17 Mar 2012 17:01:59 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A231A@XMB-RCD-109.cisco.com> In-Reply-To: <4F64E50C.4010602@globis.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] RFC6204bis-07 Thread-Index: Ac0Ec6xrnIAwSuhCRgS5uZacpBJs0wAFPpIA References: <867F4B6A1672E541A94676D556793ACD0EB995043C@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C3042FEBDB@XMB-RCD-109.cisco.com><4F61E53D.4050904@globis.net><5B6B2B64C9FE2A489045EEEADDAFF2C3043A1C75@XMB-RCD-109.cisco.com><4F62F576.3070209@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1FB5@XMB-RCD-109.cisco.com> <2D09D61DDFA73D4C884805CC7865E6110724B2@GAALPA1MSGUSR9N.ITServices.sbc.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A2270@XMB-RCD-109.cisco.com> <4F64E50C.4010602@globis.net> From: "Hemant Singh (shemant)" To: "Ray Hunter" X-OriginalArrivalTime: 17 Mar 2012 22:02:01.0449 (UTC) FILETIME=[94A51590:01CD0489] Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 22:02:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD0489.946A48E8 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ray, =20 A bullet above the bullet that includes "too small" actually defines what is too small. The other bullet is shown below.=20 =20 WPD-2: The IPv6 CE router MAY indicate as a hint to the delegating router the size of the prefix it requires. If so, it MUST ask for a prefix large enough to assign one /64 for each of its interfaces, rounded up to the nearest nibble, and SHOULD be configurable to ask for more. =20 =20 Thus we can leave the bullet with "too small" as is and add the reference to RFC 6177 to the bullet above. The bullet numbers have shifted around. Check either of rfc6204 or RFC6204bis-07 at=20 =20 http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-07 =20 Thanks, =20 Hemant =20 From: Ray Hunter [mailto:v6ops@globis.net]=20 Sent: Saturday, March 17, 2012 3:25 PM To: Hemant Singh (shemant) Cc: STARK, BARBARA H; v6ops@ietf.org WG; Wuyts Carl Subject: Re: [v6ops] RFC6204bis-07 =20 Hemant: your suggested text works fine for me. Many thanks. After reading Carl's and Barbara's comments on this requirement carefully, I've also tried to draft alternative text myself for further consideration: =20 WPD-4: The IPv6 CE router MUST be prepared to accept a delegated=20 prefix size different from that given in the hint. =20 If the delegated prefix is too small to address all of its=20 interfaces, or the prefix is not shorter than a /64, the IPv6 CE router=20 SHOULD assign a separate /64 from its delegated prefix(es) to each of as many of its LAN interfaces as possible, and SHOULD log a system management error. Best Current Practice for IPv6 Address Assignment to End Sites is provided in BCP 157 (RFC6177) [RFC6177].=20 Idea being that the requirement defines some positive behavior to perform to make the best of this situation (Barbara's "just deal with it" comment), that can be tested for compliance (Carl's comment that no behavior was defined that could be compliance tested and thus this was a redundant requirement), still deprecates single /64 (my concern) without over-stepping what is already generally agreed in BCP157 (Barbara's "A normative reference for the CE router to ensure that the access network always provides something bigger than a /64 is meaningless and useless."), prevents SLAAC being broken by assignment of longer than /64 prefixes on the LAN or some other prefix sharing hack (a lot of people's concern), and does raise an error (your suggestion to do something to alert a human to the undesirable situation) . Feel free to improve, or keep your original proposed text. Thanks, RayH =20 =20 ------_=_NextPart_001_01CD0489.946A48E8 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ray,

 

A = bullet above the bullet that includes “too small” actually = defines what is too small.  The other bullet is shown below. =

 

WPD-2:  The IPv6 CE router MAY indicate as a = hint to the delegating

        &n= bsp;  router the size of the prefix it requires.  If so, it = MUST

        &n= bsp;  ask for a prefix large enough to assign one /64 for each = of

        &n= bsp;  its interfaces, rounded up to the nearest nibble, and = SHOULD

        &n= bsp;  be configurable to ask for more.

 

 

Thus we can leave the bullet with “too small” as is and = add the reference to RFC 6177 to the bullet above.  The bullet = numbers have shifted around.  Check either of rfc6204 or = RFC6204bis-07 at

 

http://to= ols.ietf.org/html/draft-ietf-v6ops-6204bis-07

 

Thanks,

 

Hemant

 

From: Ray Hunter [mailto:v6ops@globis.net]
Sent: Saturday, = March 17, 2012 3:25 PM
To: Hemant Singh = (shemant)
Cc: STARK, BARBARA H; v6ops@ietf.org WG; Wuyts = Carl
Subject: Re: [v6ops] = RFC6204bis-07

 

Hemant: your = suggested text works fine for me. Many thanks.


After reading = Carl's and Barbara's comments on this requirement carefully, I've also = tried to draft alternative text myself for further = consideration:         =

WPD-4:  The IPv6 CE router MUST be prepared to = accept a delegated =

         &= nbsp; prefix size different from that given in the = hint.  

      &n= bsp;    If the delegated prefix is too small to address = all of its =

         &= nbsp; interfaces, or the prefix is not shorter than a /64, the IPv6 CE = router =

        &nbs= p;  SHOULD assign a separate /64 from its delegated prefix(es) = to each of as many of its LAN interfaces as = possible,

       &nbs= p;   and SHOULD log a system management = error.

          = ; Best Current Practice for IPv6 Address Assignment to End Sites is = provided in BCP 157 (RFC6177) [RFC6177].

Idea being that the requirement defines some positive = behavior to perform to make the best of this situation (Barbara's = "just deal with it" comment), that can be tested for = compliance (Carl's comment that no behavior was defined that could be = compliance tested and thus this was a redundant requirement), still = deprecates single /64 (my concern) without over-stepping what is already = generally agreed in BCP157 (Barbara's "A normative reference for = the CE router to ensure that the access network always provides = something bigger than a /64  is meaningless and useless."), = prevents SLAAC being broken by assignment of longer than /64 prefixes on = the LAN or some other prefix sharing hack (a lot of people's concern), = and does raise an error (your suggestion to do something to alert a = human to the undesirable situation) .

Feel free to improve, or = keep your original proposed = text.

Thanks,
RayH


 = ;

 

------_=_NextPart_001_01CD0489.946A48E8-- From v6ops@globis.net Sat Mar 17 15:29:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F39221F85AA for ; Sat, 17 Mar 2012 15:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.047, 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 iSTIXQsBFme6 for ; Sat, 17 Mar 2012 15:29:31 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3B021F85A1 for ; Sat, 17 Mar 2012 15:29:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 4BB2387007A; Sat, 17 Mar 2012 23:29:29 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtkg8tnzDHok; Sat, 17 Mar 2012 23:29:23 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 03D26870021; Sat, 17 Mar 2012 23:29:23 +0100 (CET) Message-ID: <4F651042.5060909@globis.net> Date: Sat, 17 Mar 2012 23:29:22 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: "Hemant Singh (shemant)" References: <867F4B6A1672E541A94676D556793ACD0EB995043C@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C3042FEBDB@XMB-RCD-109.cisco.com><4F61E53D.4050904@globis.net><5B6B2B64C9FE2A489045EEEADDAFF2C3043A1C75@XMB-RCD-109.cisco.com><4F62F576.3070209@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1FB5@XMB-RCD-109.cisco.com> <2D09D61DDFA73D4C884805CC7865E6110724B2@GAALPA1MSGUSR9N.ITServices.sbc.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A2270@XMB-RCD-109.cisco.com> <4F64E50C.4010602@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A231A@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A231A@XMB-RCD-109.cisco.com> Content-Type: multipart/alternative; boundary="------------070009080603080004010300" Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 22:29:33 -0000 This is a multi-part message in MIME format. --------------070009080603080004010300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit OK to be clear, would that mean the following delta to 6204-07? WPD-2: The IPv6 CE router MAY indicate as a hint to the delegating router the size of the prefix it requires. If so, it MUST ask for a prefix large enough to assign one /64 for each of its interfaces, rounded up to the nearest nibble, and SHOULD be configurable to ask for more. >new Best Current Practice for IPv6 Address Assignment to End Sites is >new provided in BCP 157 (RFC6177) [RFC6177]. WPD-3: The IPv6 CE router MUST be prepared to accept a delegated prefix size different from what is given in the hint. If the delegated prefix is too small to address all of its interfaces, the IPv6 CE router >new SHOULD assign a separate /64 from its delegated prefix(es) to each of as many of its LAN interfaces as possible, >new and SHOULD log a system management error. Is the first SHOULD in WPD-3 strong enough, or would MUST be better? i.e. >new MUST assign a separate /64 from its delegated prefix(es) to each of as many of its LAN interfaces as possible, >new and Hemant Singh (shemant) wrote: > > Ray, > > A bullet above the bullet that includes "too small" actually defines > what is too small. The other bullet is shown below. > > WPD-2: The IPv6 CE router MAY indicate as a hint to the delegating > > router the size of the prefix it requires. If so, it MUST > > ask for a prefix large enough to assign one /64 for each of > > its interfaces, rounded up to the nearest nibble, and SHOULD > > be configurable to ask for more. > > Thus we can leave the bullet with "too small" as is and add the > reference to RFC 6177 to the bullet above. The bullet numbers have > shifted around. Check either of rfc6204 or RFC6204bis-07 at > > http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-07 > > Thanks, > > Hemant > > *From:* Ray Hunter [mailto:v6ops@globis.net] > *Sent:* Saturday, March 17, 2012 3:25 PM > *To:* Hemant Singh (shemant) > *Cc:* STARK, BARBARA H; v6ops@ietf.org WG; Wuyts Carl > *Subject:* Re: [v6ops] RFC6204bis-07 > > Hemant: your suggested text works fine for me. Many thanks. > > > After reading Carl's and Barbara's comments on this requirement > carefully, I've also tried to draft alternative text myself for > further consideration: > > WPD-4: The IPv6 CE router MUST be prepared to accept a delegated > > prefix size different from that given in the hint. > > If the delegated prefix is too small to address all of its > > interfaces, or the prefix is not shorter than a /64, the > IPv6 CE router > > * *SHOULD assign a separate /64 from its delegated prefix(es) to each > of as many of its LAN interfaces as possible, > > and SHOULD log a system management error. > > Best Current Practice for IPv6 Address Assignment to End > Sites is provided in BCP 157 (RFC6177) [RFC6177]. > > Idea being that the requirement defines some positive behavior to > perform to make the best of this situation (Barbara's "just deal with > it" comment), that can be tested for compliance (Carl's comment that > no behavior was defined that could be compliance tested and thus this > was a redundant requirement), still deprecates single /64 (my concern) > without over-stepping what is already generally agreed in BCP157 > (Barbara's "A normative reference for the CE router to ensure that the > access network always provides something bigger than a /64 is > meaningless and useless."), prevents SLAAC being broken by assignment > of longer than /64 prefixes on the LAN or some other prefix sharing > hack (a lot of people's concern), and does raise an error (your > suggestion to do something to alert a human to the undesirable > situation) . > > Feel free to improve, or keep your original proposed text. > > Thanks, > RayH > > --------------070009080603080004010300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit OK to be clear, would that mean the following delta to 6204-07?

 WPD-2:  The IPv6 CE router MAY indicate as a hint to the delegating
            router the size of the prefix it requires.  If so, it MUST
            ask for a prefix large enough to assign one /64 for each of
            its interfaces, rounded up to the nearest nibble, and SHOULD
            be configurable to ask for more.

>new   Best Current Practice for IPv6 Address Assignment to End Sites is
>new   provided in BCP 157 (RFC6177) [RFC6177].

 WPD-3:  The IPv6 CE router MUST be prepared to accept a delegated
            prefix size different from what is given in the hint.  If the
            delegated prefix is too small to address all of its
            interfaces, the IPv6 CE router

>new   SHOULD assign a separate /64 from its delegated prefix(es) to each of as many of its LAN interfaces as possible,
>new   and

            SHOULD log a system management error.


Is the first SHOULD in WPD-3 strong enough, or would MUST be better?
i.e.
>new   MUST assign a separate /64 from its delegated prefix(es) to each of as many of its LAN interfaces as possible,
>new   and


Hemant Singh (shemant) wrote:

Ray,

 

A bullet above the bullet that includes “too small” actually defines what is too small.  The other bullet is shown below.

 

WPD-2:  The IPv6 CE router MAY indicate as a hint to the delegating

           router the size of the prefix it requires.  If so, it MUST

           ask for a prefix large enough to assign one /64 for each of

           its interfaces, rounded up to the nearest nibble, and SHOULD

           be configurable to ask for more.

 

 

Thus we can leave the bullet with “too small” as is and add the reference to RFC 6177 to the bullet above.  The bullet numbers have shifted around.  Check either of rfc6204 or RFC6204bis-07 at

 

http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-07

 

Thanks,

 

Hemant

 

From: Ray Hunter [mailto:v6ops@globis.net]
Sent: Saturday, March 17, 2012 3:25 PM
To: Hemant Singh (shemant)
Cc: STARK, BARBARA H; v6ops@ietf.org WG; Wuyts Carl
Subject: Re: [v6ops] RFC6204bis-07

 

Hemant: your suggested text works fine for me. Many thanks.


After reading Carl's and Barbara's comments on this requirement carefully, I've also tried to draft alternative text myself for further consideration:        

WPD-4:  The IPv6 CE router MUST be prepared to accept a delegated

           prefix size different from that given in the hint.  

           If the delegated prefix is too small to address all of its

           interfaces, or the prefix is not shorter than a /64, the IPv6 CE router

           SHOULD assign a separate /64 from its delegated prefix(es) to each of as many of its LAN interfaces as possible,

           and SHOULD log a system management error.

           Best Current Practice for IPv6 Address Assignment to End Sites is provided in BCP 157 (RFC6177) [RFC6177].

Idea being that the requirement defines some positive behavior to perform to make the best of this situation (Barbara's "just deal with it" comment), that can be tested for compliance (Carl's comment that no behavior was defined that could be compliance tested and thus this was a redundant requirement), still deprecates single /64 (my concern) without over-stepping what is already generally agreed in BCP157 (Barbara's "A normative reference for the CE router to ensure that the access network always provides something bigger than a /64  is meaningless and useless."), prevents SLAAC being broken by assignment of longer than /64 prefixes on the LAN or some other prefix sharing hack (a lot of people's concern), and does raise an error (your suggestion to do something to alert a human to the undesirable situation) .

Feel free to improve, or keep your original proposed text.

Thanks,
RayH


 

 





--------------070009080603080004010300-- From tom.taylor.stds@gmail.com Sat Mar 17 16:29:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7D221F866B for ; Sat, 17 Mar 2012 16:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.209 X-Spam-Level: X-Spam-Status: No, score=-3.209 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 8c0R12QjLGoZ for ; Sat, 17 Mar 2012 16:29:52 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A34F021F864A for ; Sat, 17 Mar 2012 16:29:51 -0700 (PDT) Received: by iazz13 with SMTP id z13so8717737iaz.31 for ; Sat, 17 Mar 2012 16:29:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding:x-antivirus :x-antivirus-status; bh=Mt43ilpMJIadQPuF+rUh0nQ+cFpvdtMZ4225LzI9oJU=; b=Jc45eoTsapSc+VV08FdVEGBEQ7SjyWQ7MOhgGhSXKuobjo6e+QN6rkRZzVZdhfH967 b44l4nVtrjmGvk8nK5YVedlVP6IbWHPzhSIeMkLi4/CS47POBDCHPFK4ok3UM1LN6Vdg jtyhRVAgHUt8G0SFaufsY76NWi80NESPW/sJ5QFKN2orzBr3a/mCZjnbuWoiBUGM/GK3 +xCe8vc+Kn1KomN5d2pV8m2P8Q8t2lSt+QKmB7VFozNEx3gRpranlA5bladaSC1RBJUl cHGUE4obl7gw4gy2lSvD6UxYRjdNf58Ng/Yea8hwpsdmC0Uls02cyN+Hu8CpPx4Ocike q3LQ== Received: by 10.60.18.163 with SMTP id x3mr8168133oed.64.1332026991234; Sat, 17 Mar 2012 16:29:51 -0700 (PDT) Received: from [127.0.0.1] (dsl-173-206-3-29.tor.primus.ca. [173.206.3.29]) by mx.google.com with ESMTPS id il8sm8849301obc.18.2012.03.17.16.29.49 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 17 Mar 2012 16:29:50 -0700 (PDT) Message-ID: <4F651E6B.30604@gmail.com> Date: Sat, 17 Mar 2012 19:29:47 -0400 From: Tom Taylor User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: v6ops@ietf.org References: <201203171355.q2HDt0s29520@ftpeng-update.cisco.com> In-Reply-To: <201203171355.q2HDt0s29520@ftpeng-update.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 120317-1, 17/03/2012), Outbound message X-Antivirus-Status: Clean Subject: Re: [v6ops] new draft: draft-jiang-v6ops-v4v6mc-proxy X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 23:29:56 -0000 I wouldn't mind seeing this one in Mboned. It's a candidate for the Adaptation Function for mediation between IPv4 and IPv6 multicast that is being worked on there. On 17/03/2012 9:55 AM, fred@cisco.com wrote: > > A new draft has been posted, at http://tools.ietf.org/html/draft-jiang-v6ops-v4v6mc-proxy. Please take a look at it and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From joelja@bogus.com Sat Mar 17 16:43:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7504221F860B for ; Sat, 17 Mar 2012 16:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.233 X-Spam-Level: X-Spam-Status: No, score=-102.233 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 JZBZGe4miAaO for ; Sat, 17 Mar 2012 16:43:12 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id DCABB21F85F7 for ; Sat, 17 Mar 2012 16:43:11 -0700 (PDT) Received: from Joels-MacBook-Pro.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q2HNh7sJ094873 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Sat, 17 Mar 2012 23:43:08 GMT (envelope-from joelja@bogus.com) Message-ID: <4F65218B.4070907@bogus.com> Date: Sat, 17 Mar 2012 16:43:07 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: fred@cisco.com References: <201203171355.q2HDt0Q29532@ftpeng-update.cisco.com> In-Reply-To: <201203171355.q2HDt0Q29532@ftpeng-update.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Sat, 17 Mar 2012 23:43:09 +0000 (UTC) Cc: v6ops@ietf.org, draft-townsley-v6ops-6rd-sunsetting@tools.ietf.org Subject: Re: [v6ops] new draft: draft-townsley-v6ops-6rd-sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Mar 2012 23:43:12 -0000 I'd like to see it take a stand that being able to renumber is a highly desirable property of cpe devices employing transitional mechanisms. I don't think the prefix size selected for a 6rd deployment should compel you to continue using that prefix size at a later date. On 3/17/12 06:55 , fred@cisco.com wrote: > > A new draft has been posted, at http://tools.ietf.org/html/draft-townsley-v6ops-6rd-sunsetting. Please take a look at it and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From brian.e.carpenter@gmail.com Sat Mar 17 17:09:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 825FF21F85FF for ; Sat, 17 Mar 2012 17:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.205 X-Spam-Level: X-Spam-Status: No, score=-103.205 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, 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 xkhntVmr-OZ2 for ; Sat, 17 Mar 2012 17:09:52 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 41A5921F85D0 for ; Sat, 17 Mar 2012 17:09:52 -0700 (PDT) Received: by eaaq11 with SMTP id q11so2631190eaa.31 for ; Sat, 17 Mar 2012 17:09:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=XCg4znn3yA98xXH8yfyQdyFsHAZs/Zmy4JDLkdosFUA=; b=XJdZVRo0dv/7vQjCbCT5tB9T8wWeBUUiPLLMGdYFGNXK4GNt2UMUhl6Qqi8Vev47KV 4cRo1Z7f3wj93Yltd4GGH99sRrg6hxMeA3Mvr++bqGjYpT5TYboJD7pmUvBuTvH44SPf zAvbh5WjT7LeVzB7wpvNYqOagVHhLQMhmfQ3CgQtKuuQkP/wXJIm4lSnAKYG+Q3Q6Wtk AJFhG3KCP1nz8mr0SCDwYWSMN/lSTntGL0sCcxy5RuIfyDfyqUXPdRTIhUbudsTJdBqW C1xaseqz03cYhLP6Ns+JKBh+kCgnbQFEAsPEm2ZG0EXpZd5mtPF20VGtSCnXAJ0R1Rqv tOTQ== Received: by 10.213.28.66 with SMTP id l2mr437721ebc.8.1332029390169; Sat, 17 Mar 2012 17:09:50 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id r44sm33375656eef.2.2012.03.17.17.09.45 (version=SSLv3 cipher=OTHER); Sat, 17 Mar 2012 17:09:49 -0700 (PDT) Message-ID: <4F6527C3.3080607@gmail.com> Date: Sun, 18 Mar 2012 13:09:39 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Joel jaeggli References: <201203171355.q2HDt0Q29532@ftpeng-update.cisco.com> <4F65218B.4070907@bogus.com> In-Reply-To: <4F65218B.4070907@bogus.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org, draft-townsley-v6ops-6rd-sunsetting@tools.ietf.org Subject: Re: [v6ops] new draft: draft-townsley-v6ops-6rd-sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2012 00:09:53 -0000 On 2012-03-18 12:43, Joel jaeggli wrote: > I'd like to see it take a stand that being able to renumber is a highly > desirable property of cpe devices employing transitional mechanisms. I > don't think the prefix size selected for a 6rd deployment should compel > you to continue using that prefix size at a later date. Agreed. In a multihomed scenario or a renumbering scenario, you may have multiple prefixes with different lengths at the same time. This is mentioned in RFC 5887 and in draft-ietf-6renum-gap-analysis. 6rd must not constrain any non-6rd prefix length. Brian > > On 3/17/12 06:55 , fred@cisco.com wrote: >> A new draft has been posted, at http://tools.ietf.org/html/draft-townsley-v6ops-6rd-sunsetting. Please take a look at it and comment. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From shemant@cisco.com Sat Mar 17 17:50:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F8221F8599 for ; Sat, 17 Mar 2012 17:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.158 X-Spam-Level: X-Spam-Status: No, score=-10.158 tagged_above=-999 required=5 tests=[AWL=0.440, 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 BtdM3DJ7QCTQ for ; Sat, 17 Mar 2012 17:50:27 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 089E221F84CF for ; Sat, 17 Mar 2012 17:50:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7880; q=dns/txt; s=iport; t=1332031827; x=1333241427; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=NT34wIUGWIUQGK+2EwuTZ3exhOkpeZpQvOxT0szPmtc=; b=LhHT/FaWPX2v0O50DBajNWMOZXHST3gH6CpgHjoREQmMtHrKnriPMoKe iCt0RuFbLXpQYef0Mu/efMkJkhKi33xnjMm4w+1rqQfLLWgDxVNlwzWak h9j7c1lBiHidWOKtCZU0cHzu4sqPDI2h8p0rXZ7a+y6ttfcc5WAy3+AsK U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADcwZU+tJV2a/2dsb2JhbABCgkaze4EHggkBAQEEEgEJEQNJEAIBCA4DBAEBCwYXAQYBRQkIAQEEEwgah2ibBJ4ykBljBIhWm1KBaIME X-IronPort-AV: E=Sophos;i="4.73,604,1325462400"; d="scan'208,217";a="64294668" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 18 Mar 2012 00:50:26 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2I0oQXO000703; Sun, 18 Mar 2012 00:50:26 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 17 Mar 2012 19:50:26 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD04A1.1B747425" Date: Sat, 17 Mar 2012 19:50:25 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A232A@XMB-RCD-109.cisco.com> In-Reply-To: <4F651042.5060909@globis.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] RFC6204bis-07 Thread-Index: Ac0EjW3bSNPnFuomSeWDRfLHrG5f+AAEz8Sw References: <867F4B6A1672E541A94676D556793ACD0EB995043C@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C3042FEBDB@XMB-RCD-109.cisco.com><4F61E53D.4050904@globis.net><5B6B2B64C9FE2A489045EEEADDAFF2C3043A1C75@XMB-RCD-109.cisco.com><4F62F576.3070209@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1FB5@XMB-RCD-109.cisco.com> <2D09D61DDFA73D4C884805CC7865E6110724B2@GAALPA1MSGUSR9N.ITServices.sbc.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A2270@XMB-RCD-109.cisco.com> <4F64E50C.4010602@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A231A@XMB-RCD-109.cisco.com> <4F651042.5060909@globis.net> From: "Hemant Singh (shemant)" To: "Ray Hunter" X-OriginalArrivalTime: 18 Mar 2012 00:50:26.0481 (UTC) FILETIME=[1BB69A10:01CD04A1] Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2012 00:50:29 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD04A1.1B747425 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ray, =20 =20 From: Ray Hunter [mailto:v6ops@globis.net]=20 Sent: Saturday, March 17, 2012 6:29 PM To: Hemant Singh (shemant) Cc: STARK, BARBARA H; v6ops@ietf.org; Wuyts Carl Subject: Re: [v6ops] RFC6204bis-07 =20 >OK to be clear, would that mean the following delta to 6204-07? > > WPD-2: The IPv6 CE router MAY indicate as a hint to the delegating > router the size of the prefix it requires. If so, it MUST > ask for a prefix large enough to assign one /64 for each of > its interfaces, rounded up to the nearest nibble, and SHOULD > be configurable to ask for more. >>new Best Current Practice for IPv6 Address Assignment to End Sites is >>new provided in BCP 157 (RFC6177) [RFC6177].=20 If we can leave the two bullets as is except adding the above text to WPD-2 that works best. We'd like least text to be disturbed unless there imperative need to edit/add more text. =20 Thanks and regards, =20 Hemant ------_=_NextPart_001_01CD04A1.1B747425 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ray,

 

 

From: = Ray Hunter [mailto:v6ops@globis.net]
Sent: Saturday, March = 17, 2012 6:29 PM
To: Hemant Singh (shemant)
Cc: = STARK, BARBARA H; v6ops@ietf.org; Wuyts Carl
Subject: Re: = [v6ops] RFC6204bis-07

 

>OK to be clear, = would that mean the following delta to 6204-07?
>
> WPD-2:  = The IPv6 CE router MAY indicate as a hint to the = delegating
>            = router the size of the prefix it requires.  If so, it = MUST
>            ask = for a prefix large enough to assign one /64 for each of
>            its = interfaces, rounded up to the nearest nibble, and SHOULD
>            = be configurable to ask for more.

>>new   = Best Current Practice for IPv6 Address Assignment to End Sites = is
>>new   = provided in BCP 157 (RFC6177) [RFC6177].

If we can leave the two bullets as is except = adding the above text to WPD-2 that works best.  We’d like = least text to be disturbed unless there imperative need to edit/add more = text.

 

Thanks and regards,

 

Hemant

------_=_NextPart_001_01CD04A1.1B747425-- From v6ops@globis.net Sun Mar 18 01:54:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 887B421F85AA for ; Sun, 18 Mar 2012 01:54:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.045, 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 iIcOkeMFKjoM for ; Sun, 18 Mar 2012 01:54:05 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 304F921F8484 for ; Sun, 18 Mar 2012 01:53:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 9BF3C8700D9; Sun, 18 Mar 2012 09:53:53 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKOgnQ0cWTTX; Sun, 18 Mar 2012 09:53:48 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id F2A8487007A; Sun, 18 Mar 2012 09:53:47 +0100 (CET) Message-ID: <4F65A29B.6030207@globis.net> Date: Sun, 18 Mar 2012 09:53:47 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: "Hemant Singh (shemant)" References: <867F4B6A1672E541A94676D556793ACD0EB995043C@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C3042FEBDB@XMB-RCD-109.cisco.com><4F61E53D.4050904@globis.net><5B6B2B64C9FE2A489045EEEADDAFF2C3043A1C75@XMB-RCD-109.cisco.com><4F62F576.3070209@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1FB5@XMB-RCD-109.cisco.com> <2D09D61DDFA73D4C884805CC7865E6110724B2@GAALPA1MSGUSR9N.ITServices.sbc.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A2270@XMB-RCD-109.cisco.com> <4F64E50C.4010602@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A231A@XMB-RCD-109.cisco.com> <4F651042.5060909@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A232A@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A232A@XMB-RCD-109.cisco.com> Content-Type: multipart/alternative; boundary="------------050201090607030905040509" Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2012 08:54:06 -0000 This is a multi-part message in MIME format. --------------050201090607030905040509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I've checked back, and 6204bis-07 does not seem to be any worse than 6204 on this issue. My main concern, that end users cannot buy a replacement 6204bis compliant router and know "it will just work, all other things being equal" would not appear to be fixed with just the reference to RFC6177, because it seems PD prefix "too short" could still result in undefined/unexpected behavior on the LAN interfaces. Speaking purely as a consumer, I wouldn't have a lot of faith in such a standard. I haven't got a lot more to add to the discussion, except wait and see what others opine. We'll definitely hit this topic again in Homenet, and maybe that's where it will be solved. Best regards and thanks. RayH Hemant Singh (shemant) wrote: > > Ray, > > *From:* Ray Hunter [mailto:v6ops@globis.net] > *Sent:* Saturday, March 17, 2012 6:29 PM > *To:* Hemant Singh (shemant) > *Cc:* STARK, BARBARA H; v6ops@ietf.org; Wuyts Carl > *Subject:* Re: [v6ops] RFC6204bis-07 > > >OK to be clear, would that mean the following delta to 6204-07? > > > > WPD-2: The IPv6 CE router MAY indicate as a hint to the delegating > > router the size of the prefix it requires. If so, it MUST > > ask for a prefix large enough to assign one /64 for each of > > its interfaces, rounded up to the nearest nibble, and SHOULD > > be configurable to ask for more. > > >>new Best Current Practice for IPv6 Address Assignment to End Sites is > >>new provided in BCP 157 (RFC6177) [RFC6177]. > > If we can leave the two bullets as is except adding the above text to > WPD-2 that works best. We'd like least text to be disturbed unless > there imperative need to edit/add more text. > > Thanks and regards, > > Hemant > --------------050201090607030905040509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I've checked back, and 6204bis-07 does not seem to be any worse than 6204 on this issue. My main concern, that end users cannot buy a replacement 6204bis compliant router and know "it will just work, all other things being equal" would not appear to be fixed with just the reference to RFC6177, because it seems PD prefix "too short" could still result in undefined/unexpected behavior on the LAN interfaces. Speaking purely as a consumer, I wouldn't have a lot of faith in such a standard. I haven't got a lot more to add to the discussion, except wait and see what others opine. We'll definitely hit this topic again in Homenet, and maybe that's where it will be solved.

Best regards and thanks.
RayH

Hemant Singh (shemant) wrote:

Ray,

 

 

From: Ray Hunter [mailto:v6ops@globis.net]
Sent: Saturday, March 17, 2012 6:29 PM
To: Hemant Singh (shemant)
Cc: STARK, BARBARA H; v6ops@ietf.org; Wuyts Carl
Subject: Re: [v6ops] RFC6204bis-07

 

>OK to be clear, would that mean the following delta to 6204-07?
>
> WPD-2:  The IPv6 CE router MAY indicate as a hint to the delegating
>            router the size of the prefix it requires.  If so, it MUST
>            ask for a prefix large enough to assign one /64 for each of
>            its interfaces, rounded up to the nearest nibble, and SHOULD
>            be configurable to ask for more.

>>new   Best Current Practice for IPv6 Address Assignment to End Sites is
>>new   provided in BCP 157 (RFC6177) [RFC6177].

If we can leave the two bullets as is except adding the above text to WPD-2 that works best.  We’d like least text to be disturbed unless there imperative need to edit/add more text.

 

Thanks and regards,

 

Hemant


--------------050201090607030905040509-- From shemant@cisco.com Sun Mar 18 07:27:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8A2721F8597 for ; Sun, 18 Mar 2012 07:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.167 X-Spam-Level: X-Spam-Status: No, score=-10.167 tagged_above=-999 required=5 tests=[AWL=0.431, 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 vBdrV6e89+yq for ; Sun, 18 Mar 2012 07:27:30 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9AE8021F8595 for ; Sun, 18 Mar 2012 07:27:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8825; q=dns/txt; s=iport; t=1332080850; x=1333290450; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=a5yP5SuQ3EAJ08ZH80Ph1+jwkUA1Cyfibka6eAK64iM=; b=Y2dE6ye/IdA1kGNi2olkyldl7edlauxZU6JUofMMsXpsAruliirzMZXC 4o+l0GxI6Y5GK8VdGUWlj9ri0fNfzxG7sMnYZnS7frwEikmQ+1lbIZPdM Pb28gFHYM9RqJzjPWE3HMy/xK7WRvRBp9L/WnhmlrfjaZwjM0C36KKLXL 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABnwZU+tJV2c/2dsb2JhbABCgkazeoEHggoBAQQSAQkRA0kQAgEIDhQGGAYBVgEBBBsah2iaUp4kkBljBIhWm1KBaIME X-IronPort-AV: E=Sophos;i="4.73,607,1325462400"; d="scan'208,217";a="64358204" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 18 Mar 2012 14:27:30 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id q2IERU0U021505; Sun, 18 Mar 2012 14:27:30 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 18 Mar 2012 09:27:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD0513.3FEBC3AC" Date: Sun, 18 Mar 2012 09:27:28 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A233D@XMB-RCD-109.cisco.com> In-Reply-To: <4F65A29B.6030207@globis.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] RFC6204bis-07 Thread-Index: Ac0E5Ke3jSXy+/rJRK2ov0wa3CoqXgAJsobA References: <867F4B6A1672E541A94676D556793ACD0EB995043C@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C3042FEBDB@XMB-RCD-109.cisco.com><4F61E53D.4050904@globis.net><5B6B2B64C9FE2A489045EEEADDAFF2C3043A1C75@XMB-RCD-109.cisco.com><4F62F576.3070209@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1FB5@XMB-RCD-109.cisco.com> <2D09D61DDFA73D4C884805CC7865E6110724B2@GAALPA1MSGUSR9N.ITServices.sbc.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A2270@XMB-RCD-109.cisco.com> <4F64E50C.4010602@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A231A@XMB-RCD-109.cisco.com> <4F651042.5060909@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A232A@XMB-RCD-109.cisco.com> <4F65A29B.6030207@globis.net> From: "Hemant Singh (shemant)" To: "Ray Hunter" X-OriginalArrivalTime: 18 Mar 2012 14:27:30.0337 (UTC) FILETIME=[40356110:01CD0513] Cc: v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2012 14:27:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD0513.3FEBC3AC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ray, =20 Ok, I understand the extra important clarification New text in each bullet is highlighted in bold.=20 =20 WPD-2: The IPv6 CE router MAY indicate as a hint to the delegating router the size of the prefix it requires. If so, it MUST ask for a prefix large enough to assign one /64 for each of its interfaces, rounded up to the nearest nibble, and SHOULD be configurable to ask for more. Best Current Practice for=20 IPv6 Address Assignment to End Sites is provided in BCP 157=20 (RFC6177) [RFC6177].=20 =20 WPD-3: The IPv6 CE router MUST be prepared to accept a delegated prefix size different from what is given in the hint. If the delegated prefix is too small to address all of its interfaces,=20 the IPv6 CE router assigns a /64 to each interface until a /64=20 is not available to assign to another interface. Then the IPv6 CE router SHOULD log a system management error. =20 Thanks and regards, =20 Hemant ------_=_NextPart_001_01CD0513.3FEBC3AC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ray,

 

Ok, I understand the extra important = clarification  New text in each bullet is highlighted in bold. =

 

WPD-2:  The IPv6 CE router MAY indicate as a = hint to the delegating

        router = the size of the prefix it requires.  If so, it = MUST

        ask = for a prefix large enough to assign one /64 for each = of

        its = interfaces, rounded up to the nearest nibble, and = SHOULD

        be = configurable to ask for more.  Best Current Practice for =

        IP= v6 Address Assignment to End Sites is provided in BCP 157 =

        (R= FC6177) [RFC6177].

 

WPD-3:  The IPv6 CE router MUST be prepared = to accept a delegated

        prefix = size different from what is given in the hint.  If = the

        = delegated prefix is too small to address all of its interfaces, =

        th= e IPv6 CE router assigns a /64 to each interface until a /64 =

        is= not available to assign to another interface.  Then the = IPv6

        CE = router SHOULD log a system management = error.

 

Thanks and regards,

 

Hemant

------_=_NextPart_001_01CD0513.3FEBC3AC-- From shemant@cisco.com Sun Mar 18 10:01:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A0F421F865E for ; Sun, 18 Mar 2012 10:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.026 X-Spam-Level: X-Spam-Status: No, score=-10.026 tagged_above=-999 required=5 tests=[AWL=0.272, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 1llTnFzKLihN for ; Sun, 18 Mar 2012 10:01:42 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id CBF4621F8636 for ; Sun, 18 Mar 2012 10:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=6621; q=dns/txt; s=iport; t=1332090102; x=1333299702; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=wKhpYgDVfUE2bmCyOIUmowPhK/M/41fgGS3L0xoYhRE=; b=QkYQkoMDWO2G78PWsBx0IKSFDD5U+df8G7He6gfEyQKfgyGUT+5rIBJq jQ4fLXK4XzQMdahjXCj4sXK2QlBOFpaBzVFfOu7DmDwvmQ1EpWraudjzg rmsp5K/yphGxrKVvvt+kyWjeW0SIDG20CMwOotB9Yqhb8YBxzQoY0WA5u 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAEEUZk+tJXG//2dsb2JhbABCgkaze4EHggkBAQEDARIBCREDSQUHBAIBCBEEAQELBhcBBgFFCQgBAQQBEggah2MFmlaeKpAZYwSIIzObUoFogwQ X-IronPort-AV: E=Sophos;i="4.73,608,1325462400"; d="scan'208,217";a="67394717" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 18 Mar 2012 17:01:41 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2IH1fbR010771; Sun, 18 Mar 2012 17:01:41 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 18 Mar 2012 12:01:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD0528.CA06973C" Date: Sun, 18 Mar 2012 12:01:40 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A2349@XMB-RCD-109.cisco.com> In-Reply-To: <9B1C4EC1-50ED-436F-876A-1F2512BB54C9@employees.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6204bis WGLC Thread-Index: Acz96uXRwjprUWYLSC2XqBbkihlfsgHOkmsQ References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> <9B1C4EC1-50ED-436F-876A-1F2512BB54C9@employees.org> From: "Hemant Singh (shemant)" To: =?iso-8859-1?Q?Ole_Tr=F8an?= , X-OriginalArrivalTime: 18 Mar 2012 17:01:41.0535 (UTC) FILETIME=[CA5A2AF0:01CD0528] Cc: v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2012 17:01:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD0528.CA06973C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ole and Chris, =20 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Ole Tr=F8an Sent: Friday, March 09, 2012 6:51 AM To: v6ops@ietf.org WG Cc: v6ops-chairs@tools.ietf.org Chairs; Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC =20 >Minor: >=3D=3D=3D=3D=3D=3D =20 >7. WPD-4. I disagree with this requirement. It is also hard to test, = and becomes > meaningless, given that a CPE must do PD even if M=3D0, O=3D0. > Suggestion: revert back to RFC6204:WPD-4. =20 Note RFC 4861 says =20 [If neither M nor O flags are set, this indicates that no information is = available via DHCPv6.] =20 Since the PD is acquired using DHCPv6, why should the CE WAN initiate = DHCPv6 if no DHCPv6 services are available? So why not stick with = Chris' proposal of the changed WPD-4 in rfc6204bis? =20 I do have a question for Chris. Why is Ralph's MAX_SOLO_RT DHCPv6 draft = not sufficient to mitigate the pounding of the DHCPv6 server by a CE = router asking for PD when the SP hasn't enabled PD services on the = DHCPv6 server? =20 =20 Hemant ------_=_NextPart_001_01CD0528.CA06973C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Ole and = Chris,

 

-----Original Message-----
From: v6ops-bounces@ietf.org = [mailto:v6ops-bounces@ietf.org] On Behalf Of Ole Tr=F8an
Sent: = Friday, March 09, 2012 6:51 AM
To: v6ops@ietf.org WG
Cc: = v6ops-chairs@tools.ietf.org Chairs; Ron Bonica
Subject: Re: [v6ops] = draft-ietf-v6ops-6204bis WGLC

 

>Minor:

>=3D=3D=3D=3D=3D=3D

 

>7. WPD-4. I disagree with this = requirement. It is also hard to test, and = becomes

>=A0=A0 meaningless, given that a = CPE must do PD even if M=3D0, O=3D0.

>=A0=A0 Suggestion: revert back to = RFC6204:WPD-4.

 

Note RFC 4861 says

 

[If neither M nor O flags are set, this indicates that = no information is available via DHCPv6.]

 

Since the PD is acquired using DHCPv6, why should the = CE WAN initiate DHCPv6 if no DHCPv6 services are available?=A0 So why = not stick with Chris’ proposal of the changed WPD-4 in = rfc6204bis?

 

I do have a question for Chris.=A0 Why is = Ralph’s MAX_SOLO_RT DHCPv6 draft not sufficient to mitigate the = pounding of the DHCPv6 server by a CE router asking for PD when the SP = hasn’t enabled PD services on the DHCPv6 server?=A0 =

 

Hemant

------_=_NextPart_001_01CD0528.CA06973C-- From fred@cisco.com Sun Mar 18 16:39:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A066621F8546 for ; Sun, 18 Mar 2012 16:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[] 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 FmgF7VTUfRPy for ; Sun, 18 Mar 2012 16:39:16 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id E48BD21F84F6 for ; Sun, 18 Mar 2012 16:39:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=735918; q=dns/txt; s=iport; t=1332113956; x=1333323556; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=ZfK9wuq0VHmZyZWRcQYKy96vjOgLLpY5SuGYEL7vcDU=; b=KhwOZGSgTAsGikhHvRmzGXsuLlOVxmWNddrINvQJAFzjuIhtK0Bpa20P qZvFb5HuAU2TkSQabRgKRK4iU3I4UTdHTzIwDGCnuq1dWjkpIUJH7vMkk e9+7JldXJED3GbDSA2E8YeVRu5BqfeYusTq2voNQHKI+da7lvy1IF/J9l M=; X-IronPort-AV: E=Sophos;i="4.73,608,1325462400"; d="scan'208,217";a="34065219" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 18 Mar 2012 23:39:14 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2INdB8m019096; Sun, 18 Mar 2012 23:39:11 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Sun, 18 Mar 2012 16:39:12 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Sun, 18 Mar 2012 16:39:12 -0700 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1FF3@XMB-RCD-109.cisco.com> Date: Sun, 18 Mar 2012 16:38:47 -0700 Message-Id: References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> <9B1C4EC1-50ED-436F-876A-1F2512BB54C9@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1FF3@XMB-RCD-109.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1084) Content-Type: multipart/alternative; boundary=Apple-Mail-42--528074175 Cc: v6ops-chairs@tools.ietf.org, v6ops@ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2012 23:39:17 -0000 --Apple-Mail-42--528074175 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii THanks. I think there is room for discussion at IETF 83, and the = opportunity for anyone who hasn't made his case to make it. I'd like to = believe that we can send it to Ron after the meeting. On Mar 16, 2012, at 6:48 AM, Hemant Singh (shemant) wrote: > Folks, > =20 > Here is the delta between -07 that was sent out for LastCall and -08 = which has edits from review. Three minor items from Ole need closure = during this week. PCP needs closure between Med and Francis. Changes = from DanielR, RayH, and Ole have been incorporated. > =20 > Thanks, > =20 > Hemant > =20 > < draft-ietf-v6ops-6204bis-07.txt=20 > draft-ietf-v6ops-6204bis-08.txt > > =20 > Network Working Group H. = Singh > Network Working Group H. = Singh > =20 > Internet-Draft W. = Beebee > Internet-Draft W. = Beebee > =20 > Obsoletes: 6204 (if approved) Cisco Systems, = Inc. > Obsoletes: 6204 (if approved) Cisco Systems, = Inc. > =20 > Intended status: Informational C. = Donley > Intended status: Informational C. = Donley > =20 > =20 > Expires: September 9, 2012 = CableLabs > Expires: September 17, 2012 = CableLabs > =20 > B. = Stark > B. = Stark > =20 > = AT&T > = AT&T > =20 > O. Troan, = Ed. > O. Troan, = Ed. > =20 > Cisco Systems, = Inc. > Cisco Systems, = Inc. > =20 > =20 > March 8, = 2012 > March 16, = 2012 > =20 > =20 > Basic Requirements for IPv6 Customer Edge Routers > Basic Requirements for IPv6 Customer Edge Routers > =20 > =20 > draft-ietf-v6ops-6204bis-07 > draft-ietf-v6ops-6204bis-08 > =20 > =20 > Abstract > Abstract > =20 > =20 > This document specifies requirements for an IPv6 Customer Edge (CE) > This document specifies requirements for an IPv6 Customer Edge (CE) > =20 > router. Specifically, the current version of this document focuses > router. Specifically, the current version of this document focuses > =20 > on the basic provisioning of an IPv6 CE router and the provisioning > on the basic provisioning of an IPv6 CE router and the provisioning > =20 > of IPv6 hosts attached to it. The document also covers IP = transition > of IPv6 hosts attached to it. The document also covers IP = transition > =20 > technologies. Two transition technologies in RFC 5969's 6rd and = RFC > technologies. Two transition technologies in RFC 5969's 6rd and = RFC > =20 > 6333's DS-Lite. are covered in the document. The document = obsoletes > 6333's DS-Lite. are covered in the document. The document = obsoletes > =20 > RFC 6204, if approved. > RFC 6204, if approved. > =20 > =20 > =20 > skipping to change at page 1, line > 42 > =20 > skipping to change at page 1, line > 42 > =20 > Internet-Drafts are working documents of the Internet Engineering > Internet-Drafts are working documents of the Internet Engineering > =20 > Task Force (IETF). Note that other groups may also distribute > Task Force (IETF). Note that other groups may also distribute > =20 > working documents as Internet-Drafts. The list of current = Internet- > working documents as Internet-Drafts. The list of current = Internet- > =20 > Drafts is at http://datatracker.ietf.org/drafts/current/. > Drafts is at http://datatracker.ietf.org/drafts/current/. > =20 > =20 > Internet-Drafts are draft documents valid for a maximum of six = months > Internet-Drafts are draft documents valid for a maximum of six = months > =20 > and may be updated, replaced, or obsoleted by other documents at = any > and may be updated, replaced, or obsoleted by other documents at = any > =20 > time. It is inappropriate to use Internet-Drafts as reference > time. It is inappropriate to use Internet-Drafts as reference > =20 > material or to cite them other than as "work in progress." > material or to cite them other than as "work in progress." > =20 > =20 > =20 > This Internet-Draft will expire on September 9, 2012. > This Internet-Draft will expire on September 17, 2012. > =20 > =20 > Copyright Notice > Copyright Notice > =20 > =20 > Copyright (c) 2012 IETF Trust and the persons identified as the > Copyright (c) 2012 IETF Trust and the persons identified as the > =20 > document authors. All rights reserved. > document authors. All rights reserved. > =20 > =20 > This document is subject to BCP 78 and the IETF Trust's Legal > This document is subject to BCP 78 and the IETF Trust's Legal > =20 > Provisions Relating to IETF Documents > Provisions Relating to IETF Documents > =20 > (http://trustee.ietf.org/license-info) in effect on the date of > (http://trustee.ietf.org/license-info) in effect on the date of > =20 > publication of this document. Please review these documents > publication of this document. Please review these documents > =20 > =20 > =20 > skipping to change at page 3, line > 28 > =20 > skipping to change at page 3, line > 28 > =20 > of its LAN interfaces, and fetches other configuration information > of its LAN interfaces, and fetches other configuration information > =20 > from the service provider network. Automatic provisioning of more > from the service provider network. Automatic provisioning of more > =20 > complex topology than a single router with multiple LAN interfaces = is > complex topology than a single router with multiple LAN interfaces = is > =20 > out of scope for this document. > out of scope for this document. > =20 > =20 > See [RFC4779] for a discussion of options available for deploying > See [RFC4779] for a discussion of options available for deploying > =20 > IPv6 in service provider access networks. > IPv6 in service provider access networks. > =20 > =20 > The document also covers IP transition technologies. Two = transition > The document also covers IP transition technologies. Two = transition > =20 > technologies in 6rd [RFC5969] and DS-Lite [RFC6333] are covered in > technologies in 6rd [RFC5969] and DS-Lite [RFC6333] are covered in > =20 > =20 > the document. At the time of writing this document these were the > the document. > =20 > only two transition technologies available in RFC form to be = included > =20 > in this document. > =20 > =20 > 1.1. Requirements Language > 1.1. Requirements Language > =20 > =20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > =20 > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in = this > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in = this > =20 > document are to be interpreted as described in RFC 2119 [RFC2119]. > document are to be interpreted as described in RFC 2119 [RFC2119]. > =20 > =20 > 2. Terminology > 2. Terminology > =20 > =20 > End-User Network one or more links attached to the IPv6 CE > End-User Network one or more links attached to the IPv6 CE > =20 > =20 > =20 > skipping to change at page 9, line > 8 > =20 > skipping to change at page 9, line > 8 > =20 > router MUST support IPv6 over PPP [RFC5072]. > router MUST support IPv6 over PPP [RFC5072]. > =20 > =20 > WLL-3: If the WAN interface supports PPP encapsulation, in a dual- > WLL-3: If the WAN interface supports PPP encapsulation, in a dual- > =20 > stack environment with IPCP and IPV6CP running over one PPP > stack environment with IPCP and IPV6CP running over one PPP > =20 > logical channel, the Network Control Protocols (NCP's) MUST > logical channel, the Network Control Protocols (NCP's) MUST > =20 > be treated as independent of each other and start and > be treated as independent of each other and start and > =20 > terminate independently. > terminate independently. > =20 > =20 > Address assignment requirements: > Address assignment requirements: > =20 > =20 > =20 > WAA-1: The IPv6 CE router MUST support Stateless Address > WAA-1: The IPv6 CE router MUST support Stateless Address > =20 > Autoconfiguration (SLAAC) [RFC4862]. > Autoconfiguration (SLAAC) [RFC4862]. > =20 > =20 > =20 > WAA-2: The IPv6 CE router MUST follow the recommendations in = Section > WAA-2: The IPv6 CE router MUST follow the recommendations in > =20 > 4 of [RFC5942], and in particular the handling of the L = flag > Section 4 of [RFC5942], and in particular the handling of > =20 > in the Router Advertisement Prefix Information option. > the L flag in the Router Advertisement Prefix Information > =20 > option. > =20 > =20 > =20 > WAA-3: The IPv6 CE router MUST support DHCPv6 [RFC3315] client > WAA-3: The IPv6 CE router MUST support DHCPv6 [RFC3315] client > =20 > behavior. > behavior. > =20 > =20 > =20 > WAA-4: The IPv6 CE router MUST be able to support the following > WAA-4: The IPv6 CE router MUST be able to support the following > =20 > DHCPv6 options: IA_NA, Reconfigure Accept [RFC3315], and > DHCPv6 options: IA_NA, Reconfigure Accept [RFC3315], and > =20 > DNS_SERVERS [RFC3646]. The IPv6 CE router SHOULD be able = to > DNS_SERVERS [RFC3646]. The IPv6 CE router SHOULD be able = to > =20 > support the DNS Search List DNSSL option as specified in > support the DNS Search List DNSSL option as specified in > =20 > [RFC3646]. > [RFC3646]. > =20 > =20 > =20 > WAA-5: The IPv6 CE router SHOULD support the DHCPv6 Simple Network > WAA-5: The IPv6 CE router SHOULD implement the Simple Network = Time > =20 > Time Protocol (SNTP) option [RFC4075] and theInformation > Protocol (SNTP) as specified in [RFC2030]. If the CE = router > =20 > Refresh Time option [RFC4242]. > implements SNTP, it requests the SNTP option [RFC4075] and > =20 > uses the received list of servers as primary time = reference, > =20 > unless explicitly configured otherwise. > =20 > =20 > =20 > WAA-6: If the IPv6 CE router receives a Router Advertisement = message > WAA-6: The IPv6 CE router SHOULD implement the Information = Refresh > =20 > (described in [RFC4861]) with the M flag set to 1, the IPv6 > Time option and associated client behavior as specified in > =20 > CE router MUST do DHCPv6 address assignment (request an = IA_NA > [RFC4242]. > =20 > option). > =20 > =20 > =20 > WAA-7: If the IPv6 CE router does not acquire global IPv6 > WAA-7: If the IPv6 CE router receives a Router Advertisement > =20 > address(es) from either SLAAC or DHCPv6, then it MUST = create > message (described in [RFC4861]) with the M flag set to 1, > =20 > global IPv6 address(es) from its delegated prefix(es) and > the IPv6 CE router MUST do DHCPv6 address assignment > =20 > configure those on one of its internal virtual network > (request an IA_NA option). > =20 > interfaces, unless configured to require a global IPv6 > =20 > address on the WAN interface. > =20 > =20 > =20 > WAA-8: The CE Router MUST support the DHCPv6 SOL_MAX_RT option > WAA-8: If the IPv6 CE router does not acquire global IPv6 > =20 > [I-D.droms-dhc-dhcpv6-maxsolrt-update] in a received DHCPv6 > address(es) from either SLAAC or DHCPv6, then it MUST = create > =20 > Advertise or Reply message and set its internalSOL_MAX_RT > global IPv6 address(es) from its delegated prefix(es) and > =20 > parameter to the value contained in the SOL_MAX_RT option. > configure those on one of its internal virtual network > =20 > interfaces, unless configured to require a global IPv6 > =20 > address on the WAN interface. > =20 > =20 > =20 > WAA-9: As a router, the IPv6 CE router MUST follow the weak host > WAA-9: The CE Router MUST support the DHCPv6 SOL_MAX_RT option > =20 > (Weak ES) model [RFC1122]. When originating packets from = an > [I-D.droms-dhc-dhcpv6-maxsolrt-update] in a received = DHCPv6 > =20 > interface, it will use a source address from another one of > Advertise or Reply message and set its internal SOL_MAX_RT > =20 > its interfaces if the outgoing interface does not have an > parameter to the value contained in the SOL_MAX_RT option. > =20 > address of suitable scope. > =20 > WAA-10: As a router, the IPv6 CE router MUST follow the weak host > =20 > (Weak ES) model [RFC1122]. When originating packets from = an > =20 > interface, it will use a source address from another one = of > =20 > its interfaces if the outgoing interface does not have an > =20 > address of suitable scope. > =20 > =20 > Prefix delegation requirements: > Prefix delegation requirements: > =20 > =20 > WPD-1: The IPv6 CE router MUST support DHCPv6 prefix delegation > WPD-1: The IPv6 CE router MUST support DHCPv6 prefix delegation > =20 > requesting router behavior as specified in [RFC3633] (IA_PD > requesting router behavior as specified in [RFC3633] (IA_PD > =20 > =20 > option). The IPv6 CE Router SHOULD support the > option). > =20 > = =20 > =20 > WPD-2: The IPv6 CE Router SHOULD support the > =20 > [I-D.ietf-dhc-pd-exclude] PD-Exclude option. > [I-D.ietf-dhc-pd-exclude] PD-Exclude option. > =20 > =20 > =20 > WPD-2: The IPv6 CE router MAY indicate as a hint to the delegating > WPD-3: The IPv6 CE router MAY indicate as a hint to the delegating > =20 > router the size of the prefix it requires. If so, it MUST > router the size of the prefix it requires. If so, it MUST > =20 > ask for a prefix large enough to assign one /64 for each of > ask for a prefix large enough to assign one /64 for each of > =20 > its interfaces, rounded up to the nearest nibble, and = SHOULD > its interfaces, rounded up to the nearest nibble, and = SHOULD > =20 > be configurable to ask for more. > be configurable to ask for more. > =20 > =20 > =20 > WPD-3: The IPv6 CE router MUST be prepared to accept a delegated > WPD-4: The IPv6 CE router MUST be prepared to accept a delegated > =20 > prefix size different from what is given in the hint. If = the > prefix size different from what is given in the hint. If = the > =20 > delegated prefix is too small to address all of its > delegated prefix is too small to address all of its > =20 > interfaces, the IPv6 CE router SHOULD log a system = management > interfaces, the IPv6 CE router SHOULD log a system = management > =20 > =20 > error. > error. [RFC6177] covers the recommendations for service > =20 > providers for prefix allocation sizes. > =20 > =20 > =20 > WPD-4: By default, the IPv6 CE router MUST initiate DHCPv6 prefix > WPD-5: By default, the IPv6 CE router MUST initiate DHCPv6 prefix > =20 > delegation when either the M or O flags are set to 1 in a > delegation when either the M or O flags are set to 1 in a > =20 > received Router Advertisement message. > received Router Advertisement message. > =20 > =20 > =20 > WPD-5: If the delegated prefix(es) are aggregate route(s) of > WPD-6: If the delegated prefix(es) are aggregate route(s) of > =20 > multiple, more-specific routes, the IPv6 CE router MUST > multiple, more-specific routes, the IPv6 CE router MUST > =20 > discard packets that match the aggregate route(s), but not > discard packets that match the aggregate route(s), but not > =20 > any of the more-specific routes. In other words, the next > any of the more-specific routes. In other words, the next > =20 > hop for the aggregate route(s) should be the null > hop for the aggregate route(s) should be the null > =20 > destination. This is necessary to prevent forwarding loops > destination. This is necessary to prevent forwarding loops > =20 > when some addresses covered by the aggregate are not > when some addresses covered by the aggregate are not > =20 > reachable [RFC4632]. > reachable [RFC4632]. > =20 > =20 > (a) The IPv6 CE router SHOULD send an ICMPv6 Destination > (a) The IPv6 CE router SHOULD send an ICMPv6 Destination > =20 > Unreachable message in accordance with Section 3.1 of > Unreachable message in accordance with Section 3.1 of > =20 > [RFC4443] back to the source of the packet, if the > [RFC4443] back to the source of the packet, if the > =20 > packet is to be dropped due to this rule. > packet is to be dropped due to this rule. > =20 > =20 > =20 > WPD-6: If the IPv6 CE router requests both an IA_NA and an IA_PD > WPD-7: If the IPv6 CE router requests both an IA_NA and an IA_PD > =20 > option in DHCPv6, it MUST accept an IA_PD option in DHCPv6 > option in DHCPv6, it MUST accept an IA_PD option in DHCPv6 > =20 > Advertise/Reply messages, even if the message does not > Advertise/Reply messages, even if the message does not > =20 > contain any addresses, unless configured to only obtain its > contain any addresses, unless configured to only obtain its > =20 > WAN IPv6 address via DHCPv6. > WAN IPv6 address via DHCPv6. > =20 > =20 > =20 > WPD-7: By default, an IPv6 CE router MUST NOT initiate any dynamic > WPD-8: By default, an IPv6 CE router MUST NOT initiate any dynamic > =20 > routing protocol on its WAN interface. > routing protocol on its WAN interface. > =20 > =20 > 4.3. LAN-Side Configuration > 4.3. LAN-Side Configuration > =20 > =20 > The IPv6 CE router distributes configuration information obtained > The IPv6 CE router distributes configuration information obtained > =20 > during WAN interface provisioning to IPv6 hosts and assists IPv6 > during WAN interface provisioning to IPv6 hosts and assists IPv6 > =20 > hosts in obtaining IPv6 addresses. It also supports connectivity = of > hosts in obtaining IPv6 addresses. It also supports connectivity = of > =20 > these devices in the absence of any working WAN interface. > these devices in the absence of any working WAN interface. > =20 > =20 > An IPv6 CE router is expected to support an IPv6 end-user network = and > An IPv6 CE router is expected to support an IPv6 end-user network = and > =20 > =20 > =20 > skipping to change at page 16, line > 28 > =20 > skipping to change at page 16, line > 29 > =20 > draft-droms-dhc-dhcpv6-maxsolrt-update-00 (work in > draft-droms-dhc-dhcpv6-maxsolrt-update-00 (work in > =20 > progress), November 2011. > progress), November 2011. > =20 > =20 > [I-D.ietf-dhc-pd-exclude] > [I-D.ietf-dhc-pd-exclude] > =20 > Korhonen, J., Savolainen, T., Krishnan, S., and O. = Troan, > Korhonen, J., Savolainen, T., Krishnan, S., and O. = Troan, > =20 > "Prefix Exclude Option for DHCPv6-based Prefix > "Prefix Exclude Option for DHCPv6-based Prefix > =20 > Delegation", draft-ietf-dhc-pd-exclude-04 (work in > Delegation", draft-ietf-dhc-pd-exclude-04 (work in > =20 > progress), December 2011. > progress), December 2011. > =20 > =20 > [I-D.ietf-pcp-base] > [I-D.ietf-pcp-base] > =20 > =20 > Cheshire, S., Boucadair, M., Selkirk, P., Wing, D., and = R. > Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. > =20 > Penno, "Port Control Protocol (PCP)", > Selkirk, "Port Control Protocol (PCP)", > =20 > draft-ietf-pcp-base-23 (work in progress), February2012. > draft-ietf-pcp-base-24 (work in progress), March 2012. > =20 > =20 > [RFC1122] Braden, R., "Requirements for Internet Hosts - > [RFC1122] Braden, R., "Requirements for Internet Hosts - > =20 > Communication Layers", STD 3, RFC 1122, October 1989. > Communication Layers", STD 3, RFC 1122, October 1989. > =20 > =20 > =20 > [RFC2030] Mills, D., "Simple Network Time Protocol (SNTP) Version = 4 > =20 > for IPv4, IPv6 and OSI", RFC 2030, October 1996. > =20 > = =20 > =20 > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > =20 > Requirement Levels", BCP 14, RFC 2119, March 1997. > Requirement Levels", BCP 14, RFC 2119, March 1997. > =20 > =20 > [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", > [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", > =20 > RFC 2131, March 1997. > RFC 2131, March 1997. > =20 > =20 > [RFC2464] Crawford, M., "Transmission of IPv6 Packets over = Ethernet > [RFC2464] Crawford, M., "Transmission of IPv6 Packets over = Ethernet > =20 > Networks", RFC 2464, December 1998. > Networks", RFC 2464, December 1998. > =20 > =20 > [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: > [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: > =20 > =20 > =20 > skipping to change at page 18, line > 25 > =20 > skipping to change at page 18, line > 30 > =20 > =20 > [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on = IPv4 > [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on = IPv4 > =20 > Infrastructures (6rd) -- Protocol Specification", > Infrastructures (6rd) -- Protocol Specification", > =20 > RFC 5969, August 2010. > RFC 5969, August 2010. > =20 > =20 > [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities = in > [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities = in > =20 > Customer Premises Equipment (CPE) for Providing > Customer Premises Equipment (CPE) for Providing > =20 > Residential IPv6 Internet Service", RFC 6092, > Residential IPv6 Internet Service", RFC 6092, > =20 > January 2011. > January 2011. > =20 > =20 > =20 > [RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address > =20 > Assignment to End Sites", BCP 157, RFC 6177, March 2011. > =20 > = =20 > =20 > [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- > [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- > =20 > Stack Lite Broadband Deployments Following IPv4 > Stack Lite Broadband Deployments Following IPv4 > =20 > Exhaustion", RFC 6333, August 2011. > Exhaustion", RFC 6333, August 2011. > =20 > =20 > [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host = Configuration > [RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host = Configuration > =20 > Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", > Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", > =20 > RFC 6334, August 2011. > RFC 6334, August 2011. > =20 > =20 > [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node > [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node > =20 > Requirements", RFC 6434, December 2011. > Requirements", RFC 6434, December 2011. > =20 > =20 > =20 > End of changes. 25 change > blocks.=20 > =20 > 52 lines changed or deleted > =20 > 66 lines changed or added > =20 >=20 > This html diff was produced by rfcdiff 1.39p1. The latest version is = available from http://tools.ietf.org/tools/rfcdiff/ > =20 > =20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-42--528074175 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii THanks. I think there is room for discussion at = IETF 83, and the opportunity for anyone who hasn't made his case to make = it. I'd like to believe that we can send it to Ron after the = meeting.

On Mar 16, 2012, at 6:48 AM, Hemant Singh = (shemant) wrote:

Folks,
 
Here is the delta between -07 = that was sent out for LastCall and -08 which has edits from = review.  Three minor items from Ole need closure during this = week.   PCP needs closure between Med and Francis. =   Changes from DanielR, RayH, and Ole have been = incorporated.
 
Thanks,
 
Hemant
 
< 
Network Working = Group           &nb= sp;            = ;            &= nbsp;      H. = Singh
Network Working = Group           &nb= sp;            = ;            &= nbsp;      H. = Singh
Obsoletes: 6204 = (if = approved)           = ;             = Cisco Systems, Inc.
Obsoletes: 6204 (if = approved)           = ;             = Cisco Systems, Inc.
Intended status: = Informational          &= nbsp;           &nb= sp;          C. = Donley
Intended status: = Informational          &= nbsp;           &nb= sp;          C. = Donley
Expires: = September 9, = 2012          &nb= sp;            = ;            &= nbsp;CableLabs
Expires: = September 17, = 2012          &nb= sp;            = ;             = CableLabs
 
  March 8, = 2012
March 16, 2012
 
8
Abstract
 
   This = document specifies requirements for an IPv6 Customer Edge = (CE)
   This document specifies = requirements for an IPv6 Customer Edge = (CE)
   = router.  Specifically, the current version of this document = focuses
   router.  = Specifically, the current version of this document = focuses
   on = the basic provisioning of an IPv6 CE router and the = provisioning
   on the basic = provisioning of an IPv6 CE router and the = provisioning
   of = IPv6 hosts attached to it.  The document also covers IP = transition
   of IPv6 hosts attached = to it.  The document also covers IP = transition
   = technologies.  Two transition technologies in RFC 5969's 6rd and = RFC
   technologies.  Two = transition technologies in RFC 5969's 6rd and = RFC
   = 6333's DS-Lite. are covered in the document.  The document = obsoletes
   6333's DS-Lite. are = covered in the document.  The document = obsoletes
   RFC = 6204, if approved.
   RFC 6204, if = approved.
 
 
   = Internet-Drafts are working documents of the Internet = Engineering
   Internet-Drafts are = working documents of the Internet = Engineering
   Task = Force (IETF).  Note that other groups may also = distribute
   Task Force (IETF).  = Note that other groups may also = distribute
   = working documents as Internet-Drafts.  The list of current = Internet-
   working documents as = Internet-Drafts.  The list of current = Internet-
   = Drafts is at 
   Drafts is at 
 
   = Internet-Drafts are draft documents valid for a maximum of six = months
   Internet-Drafts are = draft documents valid for a maximum of six = months
   and = may be updated, replaced, or obsoleted by other documents at = any
   and may be updated, = replaced, or obsoleted by other documents at = any
   = time.  It is inappropriate to use Internet-Drafts as = reference
   time.  It is = inappropriate to use Internet-Drafts as = reference
   = material or to cite them other than as "work in = progress."
   material or to cite them = other than as "work in progress."
 
   This = Internet-Draft will expire on September 9, = 2012.
 17, = 2012.
Copyright = Notice
Copyright = Notice
   = Copyright (c) 2012 IETF Trust and the persons identified as = the
   Copyright (c) 2012 IETF = Trust and the persons identified as the
 
   document authors.  All rights = reserved.
   document authors.  = All rights reserved.
   This = document is subject to BCP 78 and the IETF Trust's = Legal
   This document is subject = to BCP 78 and the IETF Trust's Legal
 
   Provisions Relating to IETF = Documents
   Provisions Relating to = IETF Documents
   (http://trustee.ietf.org/license-info) = in effect on the date of
   (http://trustee.ietf.org/license-info) = in effect on the date of
   = publication of this document.  Please review these = documents
   publication of this = document.  Please review these = documents
 
 
   of = its LAN interfaces, and fetches other configuration = information
   of its LAN interfaces, = and fetches other configuration = information
   from = the service provider network.  Automatic provisioning of = more
   from the service = provider network.  Automatic provisioning of = more
   = complex topology than a single router with multiple LAN interfaces = is
   complex topology than a = single router with multiple LAN interfaces = is
   out = of scope for this document.
   out of scope for this = document.
   See = [RFC4779] for a discussion of options available for = deploying
   See [RFC4779] for a = discussion of options available for = deploying
   IPv6 = in service provider access networks.
   IPv6 in service provider access = networks.
   The = document also covers IP transition technologies.  Two = transition
   The document also covers = IP transition technologies.  Two = transition
   = technologies in 6rd [RFC5969] and DS-Lite [RFC6333] are covered = in
   technologies in 6rd = [RFC5969] and DS-Lite [RFC6333] are covered = in
   the = document.  At the time of writing this document these were = the
 
 
1.1.  = Requirements Language
1.1.  Requirements = Language
   The = key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL = NOT",
   The key words "MUST", = "MUST NOT", "REQUIRED", "SHALL", "SHALL = NOT",
   = "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in = this
   "SHOULD", "SHOULD NOT", = "RECOMMENDED", "MAY", and "OPTIONAL" in = this
   = document are to be interpreted as described in RFC 2119 = [RFC2119].
   document are to be = interpreted as described in RFC 2119 = [RFC2119].
2.  = Terminology
2.  = Terminology
   = End-User Network          = one or more links attached to the IPv6 = CE
   End-User = Network          one or = more links attached to the IPv6 CE
 
 
 
 
   = WLL-3:  If the WAN interface supports PPP encapsulation, in a = dual-
   WLL-3:  If the WAN = interface supports PPP encapsulation, in a = dual-
   = Address assignment requirements:
   Address assignment = requirements:
   = WAA-1:  The IPv6 CE router MUST support Stateless = Address
 
   = WAA-2:  The IPv6 CE router MUST follow the recommendations in = Section
   = WAA-3:  The IPv6 CE router MUST support DHCPv6 [RFC3315] = client
   = WAA-4:  The IPv6 CE router MUST be able to support the = following
   = WAA-5:  The IPv6 CE router SHOULD support the DHCPv6 Simple = Network
 implement the Simple Network = Time
 as specified in [RFC2030].  If the CE = router
 option [RFC4075] = and
uses the received list of servers as = primary time reference,
 
   = WAA-6:  If the IPv6 CE router receives a Router Advertisement = message
 The IPv6 CE router SHOULD implement the Information = Refresh
 the M flag set to 1, the = IPv6
   = WAA-7:  If the IPv6 CE router does not acquire global = IPv6
 receives a Router = Advertisement
 IPv6 CE router MUST do = DHCPv6 address 
 
 a global IPv6
<= /td>
 
 on the WAN interface.
 
   = WAA-8:  The CE Router MUST support the DHCPv6 SOL_MAX_RT = option
 If the IPv6 CE router does not acquire = global IPv6
 or DHCPv6, then it MUST = create
 or Reply message and set its internalSOL_MAX_RT
 and
 
 to = the value contained in the SOL_MAX_RT = option.
configure those on one of its internal virtual = network
 to require a global = IPv6
 the WAN = interface.
   = WAA-9:  As a router, the IPv6 CE router MUST follow the weak = host
 The CE Router MUST support the = DHCPv6 SOL_MAX_RT option
 
  As a router, the IPv6 CE router = MUST follow the weak host
   = Prefix delegation requirements:
   Prefix delegation = requirements:
   = WPD-1:  The IPv6 CE router MUST support DHCPv6 prefix = delegation
   WPD-1:  The IPv6 CE = router MUST support DHCPv6 prefix = delegation
 
WPD-2:  The IPv6 CE Router SHOULD support = the
 
   = WPD-2:  The IPv6 CE router MAY indicate as a hint to = the delegating
3:  The IPv6 CE router MAY indicate as a hint to = the delegating
 
   = WPD-3:  The IPv6 CE router MUST be prepared to accept = a delegated
4:  The IPv6 CE router MUST be prepared to accept = a delegated
 [RFC6177] covers the recommendations for = service
 
   = WPD-4:  By default, the IPv6 CE router MUST initiate = DHCPv6 prefix
5:  By default, the IPv6 CE router MUST initiate = DHCPv6 prefix
 
   = WPD-5:  If the delegated prefix(es) are aggregate = route(s) of
6:  If the delegated prefix(es) are aggregate = route(s) of
   = WPD-6:  If the IPv6 CE router requests both an IA_NA = and an IA_PD
7:  If the IPv6 CE router requests both an IA_NA = and an IA_PD
   = WPD-7:  By default, an IPv6 CE router MUST NOT = initiate any dynamic
8:  By default, an IPv6 CE router MUST NOT = initiate any dynamic
 
4.3.  = LAN-Side Configuration
4.3.  LAN-Side = Configuration
   The = IPv6 CE router distributes configuration information = obtained
   The IPv6 CE router = distributes configuration information = obtained
   = during WAN interface provisioning to IPv6 hosts and assists = IPv6
   during WAN interface = provisioning to IPv6 hosts and assists = IPv6
   = hosts in obtaining IPv6 addresses.  It also supports connectivity = of
   hosts in obtaining IPv6 = addresses.  It also supports connectivity = of
   = these devices in the absence of any working WAN = interface.
   these devices in the = absence of any working WAN interface.
 
   An = IPv6 CE router is expected to support an IPv6 end-user network = and
   An IPv6 CE router is = expected to support an IPv6 end-user network = and
 
 
 
   = [I-D.ietf-dhc-pd-exclude]
 
 
   = [I-D.ietf-pcp-base]
 
 Selkirk, P., Wing, D., and = R.
Wing, D., Cheshire, S., Boucadair, = M., Penno, R., and P.
 
 "Port Control Protocol = (PCP)",
 draft-ietf-pcp-base-23 (work in progress), 
draft-ietf-pcp-base-24 (work in progress), March 2012.
=
 
   = [RFC1122]  Braden, R., "Requirements for Internet Hosts = -
   [RFC1122]  Braden, = R., "Requirements for Internet Hosts -
 
[RFC2030]  Mills, D., "Simple Network Time Protocol = (SNTP) Version 4
 
   [RFC2119]  Bradner, S., "Key words = for use in RFCs to Indicate
   [RFC2119]  Bradner, = S., "Key words for use in RFCs to = Indicate
   = [RFC2131]  Droms, R., "Dynamic Host Configuration = Protocol",
   [RFC2131]  Droms, = R., "Dynamic Host Configuration = Protocol",
 
   = [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over = Ethernet
   [RFC2464]  = Crawford, M., "Transmission of IPv6 Packets over = Ethernet
   = [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress = Filtering:
   [RFC2827]  = Ferguson, P. and D. Senie, "Network Ingress = Filtering:
 
 
   = [RFC5969]  Townsley, W. and O. Troan, "IPv6 Rapid Deployment on = IPv4
   [RFC5969]  = Townsley, W. and O. Troan, "IPv6 Rapid Deployment on = IPv4
 
   = [RFC6092]  Woodyatt, J., "Recommended Simple Security Capabilities = in
   [RFC6092]  = Woodyatt, J., "Recommended Simple Security Capabilities = in
[RFC6177]  Narten, T., Huston, G., and L. Roberts, "IPv6 = Address
 
   [RFC6333]  Durand, A., Droms, R., = Woodyatt, J., and Y. Lee, "Dual-
   [RFC6333]  Durand, A., Droms, = R., Woodyatt, J., and Y. Lee, "Dual-
 
        =       Stack Lite Broadband Deployments = Following IPv4
   = [RFC6334]  Hankins, D. and T. Mrugalski, "Dynamic Host = Configuration
   [RFC6334]  Hankins, = D. and T. Mrugalski, "Dynamic Host = Configuration
 
   = [RFC6434]  Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 = Node
   [RFC6434]  = Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 = Node
 
blocks. 
52 lines changed or = deleted
66 = lines changed or added

This html = diff was produced by rfcdiff 1.39p1. The latest version is available = from  
X-Mailer: Apple Mail (2.1257) Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 04:01:15 -0000 Hemant, > >Minor: > >=3D=3D=3D=3D=3D=3D > =20 > >7. WPD-4. I disagree with this requirement. It is also hard to test, = and becomes > > meaningless, given that a CPE must do PD even if M=3D0, O=3D0. > > Suggestion: revert back to RFC6204:WPD-4. > =20 > Note RFC 4861 says > =20 > [If neither M nor O flags are set, this indicates that no information = is available via DHCPv6.] fur the purpose of _address assignment_. > Since the PD is acquired using DHCPv6, why should the CE WAN initiate = DHCPv6 if no DHCPv6 services are available? So why not stick with = Chris=92 proposal of the changed WPD-4 in rfc6204bis? DHCPv6 PD does not use the M/O flags. neither should it, they are = overloaded as it is. DHCPv6 PD is a protocol between _routers_ from a pure DHCPv6 sense, a = requesting router is not required to do any of the host functions = specified in 6204. in addition we still want to allow for the Router = discovery and DHCP PD processing to be done in parallel. > I do have a question for Chris. Why is Ralph=92s MAX_SOLO_RT DHCPv6 = draft not sufficient to mitigate the pounding of the DHCPv6 server by a = CE router asking for PD when the SP hasn=92t enabled PD services on the = DHCPv6 server?=20 Ole From ichiroumakino@gmail.com Sun Mar 18 21:06:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE7F21F85A2 for ; Sun, 18 Mar 2012 21:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 BhVs68d8mE5w for ; Sun, 18 Mar 2012 21:06:01 -0700 (PDT) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3A96721F851D for ; Sun, 18 Mar 2012 21:06:01 -0700 (PDT) Received: by dald2 with SMTP id d2so12387507dal.27 for ; Sun, 18 Mar 2012 21:06:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=idATsDh+5LN8AakmyoSvHxQYQHKxuukb/q+XNxtRnHQ=; b=IxDDQjYc1x7HTzy5AGN+sMRvi2+HC3rcgaUWIFaDcd2dHNIpj0jlC5cSAu847toh5a 60sSow6rQxl554dbDvho6zcI/K/xdjAP3ItxcNO7ip+s5Xlh45fgkEP+I6MCt1Ekld99 gcKpaZm2DeYggtaukM9XwWHWccwigkC2SWL9mvLDgwzduMYNZc1LkC1ccuycJmw8gs51 FHG9Ylrn7rfX4M52Ss2kjqIc4cgJcM6LrgJ86Gh1H2knFfdxraazQ4hoDFXxYu5KU9Zm xOhodmLOKPHlbvYaT2cTqR30jzD8AGTG/j6uql3mXGKK7wxa9/t2hqbA5OJV4mFaKSk/ RVPw== Received: by 10.68.193.170 with SMTP id hp10mr36532741pbc.159.1332129961087; Sun, 18 Mar 2012 21:06:01 -0700 (PDT) Received: from sjc-vpn5-261.cisco.com (128-107-239-233.cisco.com. [128.107.239.233]) by mx.google.com with ESMTPS id vy2sm10326923pbb.48.2012.03.18.21.05.59 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 18 Mar 2012 21:06:00 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A233D@XMB-RCD-109.cisco.com> Date: Sun, 18 Mar 2012 21:06:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <867F4B6A1672E541A94676D556793ACD0EB995043C@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C3042FEBDB@XMB-RCD-109.cisco.com><4F61E53D.4050904@globis.net><5B6B2B64C9FE2A489045EEEADDAFF2C3043A1C75@XMB-RCD-109.cisco.com><4F62F576.3070209@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1FB5@XMB-RCD-109.cisco.com> <2D09D61DDFA73D4C884805CC7865E6110724B2@GAALPA1MSGUSR9N.ITServices.sbc.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A2270@XMB-RCD-109.cisco.com> <4F64E50C.4010602@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A231A@XMB-RCD-109.cisco.com> <4F651042.5060909@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A232A@XMB-RCD-109.cisco.com> <4F65A29B.6030207@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A233D@XMB-RCD-109.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1257) Cc: Ray Hunter , v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 04:06:06 -0000 Hemant, > Ok, I understand the extra important clarification New text in each = bullet is highlighted in bold. > =20 > WPD-2: The IPv6 CE router MAY indicate as a hint to the delegating > router the size of the prefix it requires. If so, it MUST > ask for a prefix large enough to assign one /64 for each of > its interfaces, rounded up to the nearest nibble, and SHOULD > be configurable to ask for more. Best Current Practice for > IPv6 Address Assignment to End Sites is provided in BCP 157 > (RFC6177) [RFC6177]. >=20 > =20 > WPD-3: The IPv6 CE router MUST be prepared to accept a delegated > prefix size different from what is given in the hint. If the > delegated prefix is too small to address all of its = interfaces, > the IPv6 CE router assigns a /64 to each interface until a /64 > is not available to assign to another interface. Then the = IPv6 > CE router SHOULD log a system management error. I'd rather see the added text in the descriptive section instead of as a = requirement. this isn't a requirement for the CE router. cheers, Ole= From mohamed.boucadair@orange.com Mon Mar 19 00:44:51 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F298A21F85A0 for ; Mon, 19 Mar 2012 00:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.177 X-Spam-Level: X-Spam-Status: No, score=-2.177 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 TYTnAv98npVz for ; Mon, 19 Mar 2012 00:44:50 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 2617821F84F2 for ; Mon, 19 Mar 2012 00:44:50 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 2281A264240; Mon, 19 Mar 2012 08:44:49 +0100 (CET) Received: from puexch91.nanterre.francetelecom.fr (unknown [10.101.44.48]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 042F4238124; Mon, 19 Mar 2012 08:44:49 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by puexch91.nanterre.francetelecom.fr ([10.101.44.48]) with mapi; Mon, 19 Mar 2012 08:44:48 +0100 From: To: Francis Dupont , "Hemant Singh (shemant)" Date: Mon, 19 Mar 2012 08:44:46 +0100 Thread-Topic: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) Thread-Index: Ac0DvmeBipTuywMkT5uqbcsZ7Wpy+wB5G8fQ Message-ID: <94C682931C08B048B7A8645303FDC9F36E28557C68@PUEXCB1B.nanterre.francetelecom.fr> References: Your message of Thu, 15 Mar 2012 18:44:56 EST. <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1F3E@XMB-RCD-109.cisco.com> <201203162147.q2GLlFcU073499@givry.fdupont.fr> In-Reply-To: <201203162147.q2GLlFcU073499@givry.fdupont.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.19.63316 Cc: "v6ops@ietf.org" , Alain Durand , "Dan Wang \(danwan\)" , Dave Thaler Subject: Re: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 07:44:51 -0000 Hi Francis, Please see inline. Cheers, Med=20 >-----Message d'origine----- >De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De=20 >la part de Francis Dupont >Envoy=E9 : vendredi 16 mars 2012 22:47 >=C0 : Hemant Singh (shemant) >Cc : v6ops@ietf.org; Alain Durand; Dan Wang (danwan); Dave Thaler >Objet : Re: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) > > In your previous mail you wrote: > >> >=3D> as it is in a SHOULD body you can't keep it so loose. >> =20 >> Could you please provide tighter text? >> =20 >> >=3D> I can't see where this level of details will go (*), IMHO if you >> >want to keep a SHOULD for PCP (and I am strongly opposed=20 >to this) you >> >need to cite the base spec, the ds-lite application and the server >> >discovery documents. >> =20 >> Pcp-base is cited. Please point us to documents for=20 >ds-lite application >> and the server discovery. Since you had trouble reading the new PCP >> text because the text was combined with review comments, I=20 >have shown >> the new text for PCP in rfc6204bis below. Please review. >> =20 >> The WAN interface of the CE router SHOULD support a PCP client > >=3D> I am still strongly opposed to this SHOULD for PCP. >For the other comments I'll consider this is nevertheless kept. Med: The requirement is coherent with the requriement in the server's side = specified in draft-behave-lsn-*.=20 > >> as specified in [I-D.ietf-pcp-base] for use by=20 >applications on the CE >> Router. This document takes no position on whether such >> functionality is enabled by default or mechanisms by which users >> would configure the functionality. >> =20 >> The PCP client SHOULD follow the procedure specified in Section >> 8.1 of [I-D.ietf-pcp-base] to discover its PCP server. > >=3D> I am not convinced 8.1 is enough but if the PCP WG doesn't propose >something better for a CPE we could keep this. Med: This is the better we can do. > >> In DS-Lite context, if PCP messages are exchanged using native >> IPv6 (i.e., IPv4-in-IPv6 is not used) and no PCP server is >> configured, the PCP client MUST use the address of the AFTR as >> its PCP server. > >=3D> it is bad, I propose: Med: The text is generic on purpose and it applies to both PCP encapsulatio= n mode and IPv6 plain mode. Selecting between these two modes is deployment= -specific. I don't see a reason to cite your draft here.=20 > >> In DS-Lite context, the procedure of [I-D.dupont-pcp-dslite] MUST >> be applied. > >> Handling PCP requests from PCP clients in the LAN side of the CE >> Router is out of scope. > >=3D> again there is no reason to restrict this to PCP: we should describe >the function we want and give PCP (or better PCP and UPnP IGD) as >examples of protocols providing it. Med: Including PCP client in the LAN side would require having a PCP proxy = in the CPE. Since the PCP WG didn't much progress in that spec, I vote for = keeping this out of scope. > >Regards > >Francis.Dupont@fdupont.fr >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops >= From Carl.Wuyts@technicolor.com Mon Mar 19 00:52:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1FF21F854E for ; Mon, 19 Mar 2012 00:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.256 X-Spam-Level: X-Spam-Status: No, score=-6.256 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 7LgpkJNQ-vAA for ; Mon, 19 Mar 2012 00:52:27 -0700 (PDT) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by ietfa.amsl.com (Postfix) with ESMTP id AC4E521F8550 for ; Mon, 19 Mar 2012 00:52:23 -0700 (PDT) Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKT2bltWnsWgmKcGB88AsbV0zfDSPCJhRR@postini.com; Mon, 19 Mar 2012 00:52:27 PDT 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.192.1; Mon, 19 Mar 2012 08:47:23 +0100 Received: from MOPESMBX01.eu.thmulti.com ([169.254.155.121]) by MOPESMAILHC02.eu.thmulti.com ([141.11.100.29]) with mapi; Mon, 19 Mar 2012 08:47:24 +0100 From: Wuyts Carl To: "Hemant Singh (shemant)" , Ray Hunter Date: Mon, 19 Mar 2012 08:47:22 +0100 Thread-Topic: [v6ops] RFC6204bis-07 Thread-Index: Ac0E5Ke3jSXy+/rJRK2ov0wa3CoqXgAJsobAACYCXMA= Message-ID: <867F4B6A1672E541A94676D556793ACD0EB9950A19@MOPESMBX01.eu.thmulti.com> References: <867F4B6A1672E541A94676D556793ACD0EB995043C@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C3042FEBDB@XMB-RCD-109.cisco.com><4F61E53D.4050904@globis.net><5B6B2B64C9FE2A489045EEEADDAFF2C3043A1C75@XMB-RCD-109.cisco.com><4F62F576.3070209@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1FB5@XMB-RCD-109.cisco.com> <2D09D61DDFA73D4C884805CC7865E6110724B2@GAALPA1MSGUSR9N.ITServices.sbc.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A2270@XMB-RCD-109.cisco.com> <4F64E50C.4010602@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A231A@XMB-RCD-109.cisco.com> <4F651042.5060909@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A232A@XMB-RCD-109.cisco.com> <4F65A29B.6030207@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A233D@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A233D@XMB-RCD-109.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_867F4B6A1672E541A94676D556793ACD0EB9950A19MOPESMBX01eut_" MIME-Version: 1.0 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] RFC6204bis-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 07:52:29 -0000 --_000_867F4B6A1672E541A94676D556793ACD0EB9950A19MOPESMBX01eut_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm ok with the new things added in bold, still find it a bit odd that the = CPE "MUST" ask for a prefix large enough, as large enough is first of all h= ard to define + you should, in next req, log a system error if you run out = of /64's on handing them out, so in fact meaning that you asked a "too smal= l" prefix. Moreover, "one should be able to configure a different hint", b= ut the hint is '"just" a hint + one MAY do this, not mandatory, hence this = does not deliver any added value. Please note that lots of people will not= be able to configure anything in this area, for the simple reason that the= y should not even know how it works. The avg home user is interested in ..= . connectivity, not in size of prefixes, not in IPv6 vs IPv4, etc. Anyway, to conclude: For the below WPD-3 for sure is ok. You hand out /64s and possibly log a message when yo= u "run out". WPD-2 is ok wrt hinting the prefix size, ok wrt adding a ref to RFC6177 (to= highlight the importance of prefix sizes), but the configurable part shoul= d be left out, as it doesn't bring any real added value (apart from extra c= onfig possibility to be added to the CPE). Regs Carl From: Hemant Singh (shemant) [mailto:shemant@cisco.com] Sent: zondag 18 maart 2012 15:27 To: Ray Hunter Cc: STARK, BARBARA H; v6ops@ietf.org; Wuyts Carl Subject: RE: [v6ops] RFC6204bis-07 Ray, Ok, I understand the extra important clarification New text in each bullet= is highlighted in bold. WPD-2: The IPv6 CE router MAY indicate as a hint to the delegating router the size of the prefix it requires. If so, it MUST ask for a prefix large enough to assign one /64 for each of its interfaces, rounded up to the nearest nibble, and SHOULD be configurable to ask for more. Best Current Practice for IPv6 Address Assignment to End Sites is provided in BCP 157 (RFC6177) [RFC6177]. WPD-3: The IPv6 CE router MUST be prepared to accept a delegated prefix size different from what is given in the hint. If the delegated prefix is too small to address all of its interfaces, the IPv6 CE router assigns a /64 to each interface until a /64 is not available to assign to another interface. Then the IPv6 CE router SHOULD log a system management error. Thanks and regards, Hemant --_000_867F4B6A1672E541A94676D556793ACD0EB9950A19MOPESMBX01eut_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= I’m ok with the new things added in bold, still find it a bit = odd that the CPE “MUST” ask for a prefix large enough, as large= enough is first of all hard to define + you should, in next req, log a sys= tem error if you run out of /64’s on handing them out, so in fact mea= ning that you asked a “too small” prefix.  Moreover, ̶= 0;one should be able to configure a different hint”, but the hint is = ‘”just” a hint + one MAY do this, not mandatory, hence th= is does not deliver any added value.  Please note that lots of people = will not be able to configure anything in this area, for the simple reason = that they should not even know how it works.  The avg home user is int= erested in … connectivity, not in size of prefixes, not in IPv6 vs IP= v4, etc.

 =

Anyway, to conclude:

For the below

WPD-3 for sure is ok.  You hand out /64s and pos= sibly log a message when you “run out”.

WPD-2 is ok wrt hinting the prefix size, ok wrt a= dding a ref to RFC6177 (to highlight the importance of prefix sizes), but t= he configurable part should be left out, as it doesn’t bring any real= added value (apart from extra config possibility to be added to the CPE).<= o:p>

 

Regs

Carl

 <= /o:p>

From:= Hemant Singh (shemant) [mailto:shemant@cisco.com]
Sent= : zondag 18 maart 2012 15:27
To: Ray Hunter
Cc: STA= RK, BARBARA H; v6ops@ietf.org; Wuyts Carl
Subject: RE: [v6ops] RF= C6204bis-07

&nbs= p;

Ray,

 

Ok, I understand t= he extra important clarification  New text in each bullet is highlight= ed in bold.

 

WPD-2:  The IPv6 CE router MAY indicate= as a hint to the delegating

&nb= sp;       router the size of the prefix it re= quires.  If so, it MUST

&nb= sp;       ask for a prefix large enough to as= sign one /64 for each of

 &= nbsp;      its interfaces, rounded up to the neare= st nibble, and SHOULD

 &nbs= p;      be configurable to ask for more.  = Best Current Practice for

     &nb= sp;  (RFC6177) [RFC6177].

 

WPD-3:&n= bsp; The IPv6 CE router MUST be prepared to accept a delegated

        p= refix size different from what is given in the hint.  If the

       = ; delegated prefix is too small to address all of its interfaces,

      &nbs= p; the IPv6 CE router assigns a /64 to each interface until a /64 <= o:p>

    &= nbsp;   is not available to assign to another interface. &nb= sp;Then the IPv6

 &n= bsp;      CE router SHOULD log a syste= m management error.

 = ;

Thanks and regards,

 

Hemant

= --_000_867F4B6A1672E541A94676D556793ACD0EB9950A19MOPESMBX01eut_-- From Francis.Dupont@fdupont.fr Mon Mar 19 01:16:38 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D6521F8615 for ; Mon, 19 Mar 2012 01:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=-0.275, BAYES_00=-2.599, J_CHICKENPOX_13=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 oChQkVKariVv for ; Mon, 19 Mar 2012 01:16:38 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEE321F8601 for ; Mon, 19 Mar 2012 01:16:37 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2J8GXsi097549; Mon, 19 Mar 2012 09:16:33 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203190816.q2J8GXsi097549@givry.fdupont.fr> From: Francis Dupont To: mohamed.boucadair@orange.com In-reply-to: Your message of Mon, 19 Mar 2012 08:44:46 +0100. <94C682931C08B048B7A8645303FDC9F36E28557C68@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 19 Mar 2012 09:16:33 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "v6ops@ietf.org" , Alain Durand , "Dan Wang \(danwan\)" , Dave Thaler Subject: Re: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 08:16:38 -0000 In your previous mail you wrote: > >=> I am still strongly opposed to this SHOULD for PCP. > >For the other comments I'll consider this is nevertheless kept. > > Med: The requirement is coherent with the requriement in the > server's side specified in draft-behave-lsn-*. => the v6ops spec is supposed to be used in the real world so has more constraints than draft-behave*. > >> In DS-Lite context, if PCP messages are exchanged using native > >> IPv6 (i.e., IPv4-in-IPv6 is not used) and no PCP server is > >> configured, the PCP client MUST use the address of the AFTR as > >> its PCP server. > > > >=> it is bad, I propose: > > Med: The text is generic on purpose and it applies to both PCP > encapsulation mode and IPv6 plain mode. Selecting between these two > modes is deployment-specific. I don't see a reason to cite your > draft here. => for me it looks like an attempt to overrule a choice which is in the scope of the PCP WG and this WG only. Note without a particular requirement for PCP none of the details about how to use PCP is needed. Regards Francis.Dupont@fdupont.fr From shemant@cisco.com Mon Mar 19 04:20:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72FB21F85F6 for ; Mon, 19 Mar 2012 04:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.032 X-Spam-Level: X-Spam-Status: No, score=-10.032 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 LGaAe42le9CQ for ; Mon, 19 Mar 2012 04:20:06 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 213FA21F856A for ; Mon, 19 Mar 2012 04:20:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=1854; q=dns/txt; s=iport; t=1332156006; x=1333365606; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=0f1hS8CT87eTZytWh6w2k1e7dI9KaAtUnqoTidM9yWw=; b=mP0rsJchJO/m7U9EOTLPu3SU/w/rgVYItGgsOypOXFZAol7l7rzdct3N iWLDuZNkVh8v/PSG3k2F49gmAAMg7G4R+x5j7lrGGN6M4quq6iuiqCoW0 LKwocMMaoqygbPrY73iSNVLRQ+RohtEpnRchfh+W5h7roDSUfHUghCnN+ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAL8VZ0+tJXG//2dsb2JhbABCtkmBB4IJAQEBBBIBHUkMBAIBCBEEAQELBhcBBgEgJQkIAQEEEwgah2ibFp5EiVWGRGMEiCMzmEGDEYFogwSBNgc X-IronPort-AV: E=Sophos;i="4.73,611,1325462400"; d="scan'208";a="67529896" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 19 Mar 2012 11:20:05 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2JBK57H022971; Mon, 19 Mar 2012 11:20:05 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Mar 2012 06:20:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Mar 2012 06:20:04 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A239F@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6204bis WGLC Thread-Index: Ac0FhPOkrgIiuLT5SgiJQso2A0V05QAOkCnA References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> <9B1C4EC1-50ED-436F-876A-1F2512BB54C9@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A2349@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-OriginalArrivalTime: 19 Mar 2012 11:20:05.0488 (UTC) FILETIME=[3C2B5700:01CD05C2] Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 11:20:07 -0000 Ole, -----Original Message----- From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole = Tr=F8an Sent: Monday, March 19, 2012 12:01 AM To: Hemant Singh (shemant) Cc: v6ops@ietf.org; v6ops-chairs@tools.ietf.org; Ron Bonica; = C.Donley@cablelabs.com Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC >DHCPv6 PD does not use the M/O flags. neither should it, they are = overloaded as it is. There is no IETF document that says DHCPv6 PD does not use the M flags. = I am not sold on the overloading just yet. M=3D0, O=3D0 in RFC 4861 = indicates no DHCPv6 services are available. >DHCPv6 PD is a protocol between _routers_ from a pure DHCPv6 sense, a = requesting router is not required to do any of the host functions = specified in >6204.=20 The requesting router sent a DHCPv6 SOLICIT asking for an address (IA_NA = IA_Address) and also an IA_PD. The requesting router just performed a = host addressing function with the IA_NA option in the SOLICIT. The most = common protocol running between two routers is routing. Just because = IA_PD acquisition runs between two routers doesn't mean the M and the O = bits can be so blatantly ignored because DHCPv6 is used to acquire the = IA_PD. Specifically, the DHCPv6 client in the requesting router is = served by the DHCPv6 server in the delegating router.=20 >in addition we still want to allow for the Router discovery and DHCP PD = processing to be done in parallel. Router discovery fails. Does it now even make sense to initiate DHCPv6 = PD processing because DHCPv6 processing is likely to fail too. If = DHCPv6 does not fail and a PD is acquired, the requesting router does = not have a default router which is learnt from the ND RA. Now the = requesting router cannot send packets upstream. What good is such a = setup? Hemant From Francis.Dupont@fdupont.fr Mon Mar 19 06:28:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 743D421F84DC for ; Mon, 19 Mar 2012 06:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 FuRfAMHBWqNY for ; Mon, 19 Mar 2012 06:28:24 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id B23C021F84C5 for ; Mon, 19 Mar 2012 06:28:23 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2JDSMP7016923 for ; Mon, 19 Mar 2012 14:28:22 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203191328.q2JDSMP7016923@givry.fdupont.fr> From: Francis Dupont To: v6ops@ietf.org Date: Mon, 19 Mar 2012 14:28:22 +0100 Sender: Francis.Dupont@fdupont.fr Subject: [v6ops] 6204bis W-6 new text proposal X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 13:28:24 -0000 Current text (from draft-ietf-v6ops-6204bis-07.txt as it is in the IETF repository) is: OLD W-6: The WAN interface of the CE router SHOULD support an IPv4 PCP client as specified in [I-D.ietf-pcp-base] for use by applications on the CE Router. This document takes no position on whether such functionality is enabled by default or mechanisms by which users would configure the functionality. I propose following Tim Chown's wording in draft-ietf-homenet-arch-02.txt: NEW W-6: For applications on the CE router which want to accept IPv4 inbound connections from the WAN side, the WAN interface of the CE router SHOULD support a protocol such as UPnP IGD [UPnP-IGD] or PCP [I-D.ietf-pcp-base]. This document takes no position on whether such functionality is enabled by default or mechanisms by which users would configure the functionality. Note there is already an informative reference for UPnP IGD (with a 2001 date?). The I-D.ietf-pcp-base must be to the informative section (and be updated as current I-D version is 24 if not done automagically). Thanks Francis.Dupont@fdupont.fr PS: of course there is no need of DS-Lite consideration for PCP (nor UPnP IGD). From simon.perreault@viagenie.ca Mon Mar 19 06:37:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9419221F8643 for ; Mon, 19 Mar 2012 06:37:34 -0700 (PDT) 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 k3SzcGNVtijD for ; Mon, 19 Mar 2012 06:37:33 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id CE47B21F862B for ; Mon, 19 Mar 2012 06:37:33 -0700 (PDT) Received: from ringo.viagenie.ca (unknown [IPv6:2620:0:230:c000:746b:1b19:a71f:72a2]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 554A940110 for ; Mon, 19 Mar 2012 09:37:33 -0400 (EDT) Message-ID: <4F67369C.1070402@viagenie.ca> Date: Mon, 19 Mar 2012 09:37:32 -0400 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: v6ops@ietf.org References: <201203191328.q2JDSMP7016923@givry.fdupont.fr> In-Reply-To: <201203191328.q2JDSMP7016923@givry.fdupont.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] 6204bis W-6 new text proposal X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 13:37:34 -0000 On 2012-03-19 09:28, Francis Dupont wrote: > NEW > > W-6: For applications on the CE router which want to accept IPv4 > inbound connections from the WAN side, the WAN interface of > the CE router SHOULD support a protocol such as UPnP IGD > [UPnP-IGD] or PCP [I-D.ietf-pcp-base]. This document takes > no position on whether such functionality is enabled by > default or mechanisms by which users would configure the > functionality. Disagree. We already require a PCP server in draft-ietf-behave-lsn-requirements. It is only logical that we require a PCP client at the other end of the wire, isn't it? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From mohamed.boucadair@orange.com Mon Mar 19 06:40:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D26B21F86AF for ; Mon, 19 Mar 2012 06:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 9uRIqg6jEHVr for ; Mon, 19 Mar 2012 06:40:30 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3E01B21F85F9 for ; Mon, 19 Mar 2012 06:40:30 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id A79083243A7; Mon, 19 Mar 2012 14:40:28 +0100 (CET) Received: from PUEXCH21.nanterre.francetelecom.fr (unknown [10.101.44.28]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 8F72C27C06E; Mon, 19 Mar 2012 14:40:28 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH21.nanterre.francetelecom.fr ([10.101.44.28]) with mapi; Mon, 19 Mar 2012 14:40:28 +0100 From: To: Simon Perreault , "v6ops@ietf.org" Date: Mon, 19 Mar 2012 14:40:27 +0100 Thread-Topic: [v6ops] 6204bis W-6 new text proposal Thread-Index: Ac0F1Xfz61tZo/eDSpy4kbmhe+pi7QAABKKg Message-ID: <94C682931C08B048B7A8645303FDC9F36E28557EB2@PUEXCB1B.nanterre.francetelecom.fr> References: <201203191328.q2JDSMP7016923@givry.fdupont.fr> <4F67369C.1070402@viagenie.ca> In-Reply-To: <4F67369C.1070402@viagenie.ca> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.19.130327 Subject: Re: [v6ops] 6204bis W-6 new text proposal X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 13:40:31 -0000 Re- +1. Cheers, Med=20 >-----Message d'origine----- >De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De=20 >la part de Simon Perreault >Envoy=E9 : lundi 19 mars 2012 14:38 >=C0 : v6ops@ietf.org >Objet : Re: [v6ops] 6204bis W-6 new text proposal > >On 2012-03-19 09:28, Francis Dupont wrote: >> NEW >> >> W-6: For applications on the CE router which want to accept IPv4 >> inbound connections from the WAN side, the WAN interface of >> the CE router SHOULD support a protocol such as UPnP IGD >> [UPnP-IGD] or PCP [I-D.ietf-pcp-base]. This document takes >> no position on whether such functionality is enabled by >> default or mechanisms by which users would configure the >> functionality. > >Disagree. > >We already require a PCP server in draft-ietf-behave-lsn-requirements.=20 >It is only logical that we require a PCP client at the other=20 >end of the=20 >wire, isn't it? > >Simon >--=20 >DTN made easy, lean, and smart --> http://postellation.viagenie.ca >NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca >STUN/TURN server --> http://numb.viagenie.ca >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops >= From mohamed.boucadair@orange.com Mon Mar 19 06:43:16 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9121B21F864C for ; Mon, 19 Mar 2012 06:43:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 EIfSlyOt1Eyf for ; Mon, 19 Mar 2012 06:43:10 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 78A3A21F85F9 for ; Mon, 19 Mar 2012 06:43:10 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id B6EF022C0F6; Mon, 19 Mar 2012 14:43:09 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 9B3994C066; Mon, 19 Mar 2012 14:43:09 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Mon, 19 Mar 2012 14:43:09 +0100 From: To: Francis Dupont , "v6ops@ietf.org" Date: Mon, 19 Mar 2012 14:43:08 +0100 Thread-Topic: [v6ops] 6204bis W-6 new text proposal Thread-Index: Ac0F1C/2SPSCkhIjTqy9UXhJ311bawAAbC/w Message-ID: <94C682931C08B048B7A8645303FDC9F36E28557EB9@PUEXCB1B.nanterre.francetelecom.fr> References: <201203191328.q2JDSMP7016923@givry.fdupont.fr> In-Reply-To: <201203191328.q2JDSMP7016923@givry.fdupont.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.19.130327 Subject: Re: [v6ops] 6204bis W-6 new text proposal X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 13:43:16 -0000 Re-, I don't see how you can get rid of the DS-Lite considerations and answer to= the comments from O. Troan: see http://www.ietf.org/mail-archive/web/v6ops= /current/msg12293.html: * PCP Server discovery * PCP Clients in the LAN side. Cheers, Med >-----Message d'origine----- >De : v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] De=20 >la part de Francis Dupont >Envoy=E9 : lundi 19 mars 2012 14:28 >=C0 : v6ops@ietf.org >Objet : [v6ops] 6204bis W-6 new text proposal > >Current text (from draft-ietf-v6ops-6204bis-07.txt as it is in the >IETF repository) is: > >OLD > > W-6: The WAN interface of the CE router SHOULD support an IPv4 PCP > client as specified in [I-D.ietf-pcp-base] for use by > applications on the CE Router. This document takes=20 >no position > on whether such functionality is enabled by default or > mechanisms by which users would configure the functionality. > >I propose following Tim Chown's wording in >draft-ietf-homenet-arch-02.txt: > >NEW > > W-6: For applications on the CE router which want to accept IPv4 > inbound connections from the WAN side, the WAN interface of > the CE router SHOULD support a protocol such as UPnP IGD > [UPnP-IGD] or PCP [I-D.ietf-pcp-base]. This document takes > no position on whether such functionality is enabled by > default or mechanisms by which users would configure the > functionality. > >Note there is already an informative reference for UPnP IGD >(with a 2001 date?). The I-D.ietf-pcp-base must be to the informative >section (and be updated as current I-D version is 24 if not done >automagically). > >Thanks > >Francis.Dupont@fdupont.fr > >PS: of course there is no need of DS-Lite consideration for PCP >(nor UPnP IGD). >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops >= From shemant@cisco.com Mon Mar 19 06:58:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB47121F84D7 for ; Mon, 19 Mar 2012 06:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.887 X-Spam-Level: X-Spam-Status: No, score=-9.887 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 qJkbUNP7o+DV for ; Mon, 19 Mar 2012 06:58:03 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 7141521F854A for ; Mon, 19 Mar 2012 06:58:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=2406; q=dns/txt; s=iport; t=1332165483; x=1333375083; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=fajZZOiOb5GPW2gJuE4VD6z4FYACNzbNFK6kTunvxbk=; b=MXmjncQn+GHpdF616ClrWKDqqjfqMMaPBIqlQ8xM/6YYl1xT98dt8mNx /WrVvda5wWli8xXjRwftMi6RrhLTppyTGp9T6ejIvPXGMYNsBf5ioRu5O N58+V3xXcIsoas0fZDt3byw3WucOSKddo4eY+3bIFvaUYDD66LM52kzmP Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJQ6Z0+tJV2b/2dsb2JhbABCtkqBB4IJAQEBBAEBAQ8BHQo0CwwEAgEIEAEEAQELBhcBBgEmHwkIAQEEARIIGodoC5ssnlsEkBljBIhWm1KBaIME X-IronPort-AV: E=Sophos;i="4.73,611,1325462400"; d="scan'208";a="67536817" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 19 Mar 2012 13:58:03 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2JDw2Um005516; Mon, 19 Mar 2012 13:58:02 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Mar 2012 08:58:02 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 19 Mar 2012 08:58:01 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A2413@XMB-RCD-109.cisco.com> In-Reply-To: <201203191328.q2JDSMP7016923@givry.fdupont.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6204bis W-6 new text proposal Thread-Index: Ac0F1DBhUUGnkrHMS4q8kyXC/Xk5lAAAQbbA References: <201203191328.q2JDSMP7016923@givry.fdupont.fr> From: "Hemant Singh (shemant)" To: "Francis Dupont" , X-OriginalArrivalTime: 19 Mar 2012 13:58:02.0765 (UTC) FILETIME=[4D110BD0:01CD05D8] Subject: Re: [v6ops] 6204bis W-6 new text proposal X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 13:58:04 -0000 Francis, Thanks much. Say, since UPnP-IGD is already in a descriptive section of rfc6204bis, we have no need to included UPnP also in the W-6 PCP requirement. Let's keep the PCP requirement separate from UPnP. UPnP won't be easy to get consensus on in the IETF to add to the CE router. Further, the W-6 bullet is ONLY about PCP and please let's stick to that. Now, back to some extra text that Med proposed with the address of the AFTR. It makes sense to add that text to clear confusion for DS-Lite tunneled vs. native IPv6 traffic. Maybe we can add an extra bullet for the extra Text that Med proposed for DS-Lite and thus keep the PCP req separate from the DS-Lite nuance and PCP? Thanks and Regards, Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Francis Dupont Sent: Monday, March 19, 2012 9:28 AM To: v6ops@ietf.org Subject: [v6ops] 6204bis W-6 new text proposal Current text (from draft-ietf-v6ops-6204bis-07.txt as it is in the IETF repository) is: OLD W-6: The WAN interface of the CE router SHOULD support an IPv4 PCP client as specified in [I-D.ietf-pcp-base] for use by applications on the CE Router. This document takes no position on whether such functionality is enabled by default or mechanisms by which users would configure the functionality. I propose following Tim Chown's wording in draft-ietf-homenet-arch-02.txt: NEW W-6: For applications on the CE router which want to accept IPv4 inbound connections from the WAN side, the WAN interface of the CE router SHOULD support a protocol such as UPnP IGD [UPnP-IGD] or PCP [I-D.ietf-pcp-base]. This document takes no position on whether such functionality is enabled by default or mechanisms by which users would configure the functionality. Note there is already an informative reference for UPnP IGD (with a 2001 date?). The I-D.ietf-pcp-base must be to the informative section (and be updated as current I-D version is 24 if not done automagically). Thanks Francis.Dupont@fdupont.fr PS: of course there is no need of DS-Lite consideration for PCP (nor UPnP IGD). _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From shemant@cisco.com Mon Mar 19 07:15:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6BC921F866C for ; Mon, 19 Mar 2012 07:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.189 X-Spam-Level: X-Spam-Status: No, score=-10.189 tagged_above=-999 required=5 tests=[AWL=0.409, 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 dCknp6lEmL1m for ; Mon, 19 Mar 2012 07:15:52 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC5121F865C for ; Mon, 19 Mar 2012 07:15:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=12302; q=dns/txt; s=iport; t=1332166552; x=1333376152; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=oqVVRl2Gpgsxh+SBqfS67cgUM0ljQ49oeZqGDIe8NmE=; b=QFBy63kkH+BorerMpuI5nmnGYHo5f9vL+7erH0uOm5qa7AAPb2QUoj0c ru3bJFaylDeynOG27xtKCfxiEPIfx+aOG7M+sXnaPaZF4EUYIoQs3gRx1 yn/o+xOZj/flqMDNNrqtzlIffhNVC9a+mHqZCQcbMEcJoHx2qxJM7qjC7 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAEQ/Z0+tJV2Y/2dsb2JhbABCgka0BIEHggkBAQEEEgEJEQNVBAIBCBABBAEBCwYXAQYBRQkIAQEEARIIARmHaAubLp5fikmFUGMEiFaJW5F3gWiDBIE+ X-IronPort-AV: E=Sophos;i="4.73,611,1325462400"; d="scan'208,217";a="67563199" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-6.cisco.com with ESMTP; 19 Mar 2012 14:15:52 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2JEFpKV029790; Mon, 19 Mar 2012 14:15:52 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Mar 2012 09:15:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD05DA.C7517980" Date: Mon, 19 Mar 2012 09:15:46 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A2434@XMB-RCD-109.cisco.com> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E28557EB9@PUEXCB1B.nanterre.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6204bis W-6 new text proposal Thread-Index: Ac0F1C/2SPSCkhIjTqy9UXhJ311bawAAbC/wAAElPNA= References: <201203191328.q2JDSMP7016923@givry.fdupont.fr> <94C682931C08B048B7A8645303FDC9F36E28557EB9@PUEXCB1B.nanterre.francetelecom.fr> From: "Hemant Singh (shemant)" To: , "Francis Dupont" , X-OriginalArrivalTime: 19 Mar 2012 14:15:47.0306 (UTC) FILETIME=[C7951CA0:01CD05DA] Subject: Re: [v6ops] 6204bis W-6 new text proposal X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 14:15:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD05DA.C7517980 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Med, =20 I combined all generic PCP related requirements into W-6 and just kept the DS-Lite nuance in a new W-7. =20 W-6: The WAN interface of the CE router SHOULD support an IPv4 PCP client as specified in [I-D.ietf-pcp-base] for use by applications on the CE Router. The PCP client SHOULD follow the procedure specified in Section 8.1 of [I-D.ietf-pcp-base] to discover its PCP server. This document takes no position on whether such functionality is enabled by default or mechanisms by which users would configure the functionality. Handling PCP requests from PCP clients in the LAN side of the CE Router is out of scope. =20 W-7: In DS-Lite context, if PCP messages are exchanged using native IPv6 (i.e., IPv4-in-IPv6 is not used) and no PCP server is configured, the PCP client MUST use the address of the AFTR as its PCP server. =20 Thanks for the great DS-Lite PCP text and all your help in working with Francis. =20 Hemant =20 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of mohamed.boucadair@orange.com Sent: Monday, March 19, 2012 9:43 AM To: Francis Dupont; v6ops@ietf.org Subject: Re: [v6ops] 6204bis W-6 new text proposal =20 =20 Re-, =20 I don't see how you can get rid of the DS-Lite considerations and answer to the comments from O. Troan: see http://www.ietf.org/mail-archive/web/v6ops/current/msg12293.html: =20 * PCP Server discovery * PCP Clients in the LAN side. =20 Cheers, Med =20 ------_=_NextPart_001_01CD05DA.C7517980 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Med,

 

I combined all generic PCP related = requirements into W-6 and just kept the DS-Lite nuance in a new = W-7.

 

   W-6:  The WAN interface of the CE router SHOULD = support an IPv4 PCP

         client as = specified in [I-D.ietf-pcp-base] for use by

         applications on = the CE Router.  The PCP client SHOULD = follow

         the procedure = specified in Section 8.1 of [I-D.ietf-pcp-base]

         to discover its = PCP server.  This document takes no position = on

         whether such = functionality is enabled by default or = mechanisms

         by which users = would configure the functionality.  Handling = PCP

         requests from PCP = clients in the LAN side of the CE Router is

         out of = scope.

 

   W-7:  In DS-Lite context, if PCP messages are = exchanged using native

         IPv6 (i.e., = IPv4-in-IPv6 is not used) and no PCP server is

         configured, the = PCP client MUST use the address of the AFTR as

         its PCP = server.

 

Thanks = for the great DS-Lite PCP text and all your help in working with = Francis.

 

Hemant

 

-----Original Message-----
From: v6ops-bounces@ietf.org = [mailto:v6ops-bounces@ietf.org] On Behalf Of = mohamed.boucadair@orange.com
Sent: Monday, March 19, 2012 9:43 = AM
To: Francis Dupont; v6ops@ietf.org
Subject: Re: [v6ops] 6204bis = W-6 new text proposal

 

 

Re-,

 

I don't see how you can get rid of = the DS-Lite considerations and answer to the comments from O. Troan: see = http://www.ietf.org/mail-archive/web/v6ops/current/msg12293.html:

 

* PCP = Server discovery

* PCP Clients in the LAN = side.

 

Cheers,

Med

 

------_=_NextPart_001_01CD05DA.C7517980-- From Francis.Dupont@fdupont.fr Mon Mar 19 07:22:59 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35DE321F8739 for ; Mon, 19 Mar 2012 07:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 PS0ZEfG+X-Zd for ; Mon, 19 Mar 2012 07:22:58 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 585DD21F8735 for ; Mon, 19 Mar 2012 07:22:58 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2JEMvkQ020298; Mon, 19 Mar 2012 15:22:57 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203191422.q2JEMvkQ020298@givry.fdupont.fr> From: Francis Dupont To: Simon Perreault In-reply-to: Your message of Mon, 19 Mar 2012 09:37:32 -0400. <4F67369C.1070402@viagenie.ca> Date: Mon, 19 Mar 2012 15:22:57 +0100 Sender: Francis.Dupont@fdupont.fr Cc: v6ops@ietf.org Subject: Re: [v6ops] 6204bis W-6 new text proposal X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 14:22:59 -0000 In your previous mail you wrote: > We already require a PCP server in draft-ietf-behave-lsn-requirements. => this is where is the mistake IMHO but I gave up to fix behave documents (and behave people to see behave documents to have any impact in the real world :-). Regards Francis.Dupont@fdupont.fr From shemant@cisco.com Mon Mar 19 07:23:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2010121F877E for ; Mon, 19 Mar 2012 07:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.196 X-Spam-Level: X-Spam-Status: No, score=-10.196 tagged_above=-999 required=5 tests=[AWL=0.402, 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 Mga-atdAJA3c for ; Mon, 19 Mar 2012 07:23:41 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1C36821F876E for ; Mon, 19 Mar 2012 07:23:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6843; q=dns/txt; s=iport; t=1332167021; x=1333376621; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=RzIbHaCQlX9gW7IkkMt6GqGhmo0AYtjJ1Wz2ceqrJwg=; b=UvJXeUibWilWrB3dxitEgdlffxQdskmmAcWqh0yZ4NGE33qoFu1Y+F+d RgpBEX1X/2aZg6iFYvRuFXHBJ8r/wCvBiwg0ydCqpXJnhG9exsdBixWWt NkUsZmmEwOCr0q7pOK3MKUrfcEkhe0sWNml3pY5dTT+6HytmT4f7Z7XLQ g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIBAZ0+tJXHA/2dsb2JhbABCgka0BIEHggoBAQQSAQkRA1kCAQgiBhgGAVYBAQQBGhqHaJs+nmSQGWMEiFabUoFogwQ X-IronPort-AV: E=Sophos;i="4.73,611,1325462400"; d="scan'208,217";a="64556483" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 19 Mar 2012 14:23:40 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q2JENe88010624; Mon, 19 Mar 2012 14:23:40 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Mar 2012 09:23:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD05DB.E15F772C" Date: Mon, 19 Mar 2012 09:23:39 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A243F@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A2434@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6204bis W-6 new text proposal Thread-Index: Ac0F1C/2SPSCkhIjTqy9UXhJ311bawAAbC/wAAElPNAAAE8jwA== References: <201203191328.q2JDSMP7016923@givry.fdupont.fr><94C682931C08B048B7A8645303FDC9F36E28557EB9@PUEXCB1B.nanterre.francetelecom.fr> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A2434@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Hemant Singh (shemant)" , , "Francis Dupont" , X-OriginalArrivalTime: 19 Mar 2012 14:23:40.0667 (UTC) FILETIME=[E1BA44B0:01CD05DB] Subject: Re: [v6ops] 6204bis W-6 new text proposal X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 14:23:42 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD05DB.E15F772C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, =20 In bullet W-6, here is the minor change. =20 =20 s/"IPv4 PCP client"/"PCP client". =20 Thanks to Med for reminding me of this one. =20 Hemant =20 ------_=_NextPart_001_01CD05DB.E15F772C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

In bullet W-6, here is the minor change.  =

 

 s/"IPv4 PCP client"/"PCP = client".

 

Thanks to Med for reminding me of this = one.

 

Hemant

 

------_=_NextPart_001_01CD05DB.E15F772C-- From Francis.Dupont@fdupont.fr Mon Mar 19 07:25:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD4121F8782 for ; Mon, 19 Mar 2012 07:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, J_CHICKENPOX_13=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 5n1ocgDflGNK for ; Mon, 19 Mar 2012 07:25:42 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id E818721F8781 for ; Mon, 19 Mar 2012 07:25:40 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2JEPeev020498; Mon, 19 Mar 2012 15:25:40 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203191425.q2JEPeev020498@givry.fdupont.fr> From: Francis Dupont To: mohamed.boucadair@orange.com In-reply-to: Your message of Mon, 19 Mar 2012 14:43:08 +0100. <94C682931C08B048B7A8645303FDC9F36E28557EB9@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 19 Mar 2012 15:25:40 +0100 Sender: Francis.Dupont@fdupont.fr Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 6204bis W-6 new text proposal X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 14:25:42 -0000 In your previous mail you wrote: > I don't see how you can get rid of the DS-Lite considerations and answer to > the comments from O. Troan > > * PCP Server discovery => This is in the "This document takes no position..." I didn't change BTW. > * PCP Clients in the LAN side. => we already agreed this is not in the v6ops scope. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Mon Mar 19 07:38:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99AC221F8851 for ; Mon, 19 Mar 2012 07:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.262 X-Spam-Level: X-Spam-Status: No, score=-2.262 tagged_above=-999 required=5 tests=[AWL=-0.263, BAYES_00=-2.599, J_CHICKENPOX_13=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 nsxRb0+QWdpY for ; Mon, 19 Mar 2012 07:38:01 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id E4A9621F87E0 for ; Mon, 19 Mar 2012 07:38:00 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2JEbw51021231; Mon, 19 Mar 2012 15:37:58 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203191437.q2JEbw51021231@givry.fdupont.fr> From: Francis Dupont To: "Hemant Singh (shemant)" In-reply-to: Your message of Mon, 19 Mar 2012 08:58:01 EST. <5B6B2B64C9FE2A489045EEEADDAFF2C3043A2413@XMB-RCD-109.cisco.com> Date: Mon, 19 Mar 2012 15:37:58 +0100 Sender: Francis.Dupont@fdupont.fr Cc: v6ops@ietf.org Subject: Re: [v6ops] 6204bis W-6 new text proposal X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 14:38:01 -0000 In your previous mail you wrote: > Thanks much. Say, since UPnP-IGD is already in a descriptive section of > rfc6204bis, we have no need to included UPnP also in the W-6 PCP > requirement. Let's keep the PCP requirement separate from UPnP. UPnP > won't be easy to get consensus on in the IETF to add to the CE router. > Further, the W-6 bullet is ONLY about PCP and please let's stick to > that. => in this case I have a strong concern about the SHOULD and I'd like to get a MAY. > Now, back to some extra text that Med proposed with the address of the > AFTR. It makes sense to add that text to clear confusion for DS-Lite > tunneled vs. native IPv6 traffic. => but this is NOT in the scope of the v6ops WG and badly interferes with what the PCP WG decided about this issue. > Maybe we can add an extra bullet for the extra Text that Med > proposed for DS-Lite and thus keep the PCP req separate from the > DS-Lite nuance and PCP? => no, IMHO there is already too much about PCP in the document. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Mon Mar 19 07:45:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC5E121F85FF for ; Mon, 19 Mar 2012 07:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 HJscJmhFWWtr for ; Mon, 19 Mar 2012 07:45:24 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 73EDE21F8585 for ; Mon, 19 Mar 2012 07:45:23 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2JEjD8p021766; Mon, 19 Mar 2012 15:45:13 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203191445.q2JEjD8p021766@givry.fdupont.fr> From: Francis Dupont To: "Hemant Singh (shemant)" In-reply-to: Your message of Mon, 19 Mar 2012 09:15:46 EST. <5B6B2B64C9FE2A489045EEEADDAFF2C3043A2434@XMB-RCD-109.cisco.com> Date: Mon, 19 Mar 2012 15:45:13 +0100 Sender: Francis.Dupont@fdupont.fr Cc: v6ops@ietf.org Subject: Re: [v6ops] 6204bis W-6 new text proposal X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 14:45:25 -0000 In your previous mail you wrote: > W-7: In DS-Lite context, if PCP messages are exchanged using native > IPv6 (i.e., IPv4-in-IPv6 is not used) and no PCP server is > configured, the PCP client MUST use the address of the AFTR as > its PCP server. => strongly disagree: please remove the W-7 Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Mon Mar 19 07:48:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70FCE21F8692 for ; Mon, 19 Mar 2012 07:48:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 iL-TjQhwN5eU for ; Mon, 19 Mar 2012 07:48:33 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id A215221F8680 for ; Mon, 19 Mar 2012 07:48:32 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2JEmUjD021985; Mon, 19 Mar 2012 15:48:30 +0100 (CET) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203191448.q2JEmUjD021985@givry.fdupont.fr> From: Francis Dupont To: "Hemant Singh (shemant)" In-reply-to: Your message of Mon, 19 Mar 2012 09:23:39 EST. <5B6B2B64C9FE2A489045EEEADDAFF2C3043A243F@XMB-RCD-109.cisco.com> Date: Mon, 19 Mar 2012 15:48:30 +0100 Sender: Francis.Dupont@fdupont.fr Cc: v6ops@ietf.org Subject: Re: [v6ops] 6204bis W-6 new text proposal X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 14:48:33 -0000 In your previous mail you wrote: > In bullet W-6, here is the minor change. > > s/"IPv4 PCP client"/"PCP client". => but IPv4 must be in the text, I propose to put it before the word "applications". Regards Francis.Dupont@fdupont.fr PS: BTW have we good examples of such applications? In fact I can't see an use for the W-6... From mohamed.boucadair@orange.com Mon Mar 19 07:53:20 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5036821F884C for ; Mon, 19 Mar 2012 07:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.182 X-Spam-Level: X-Spam-Status: No, score=-2.182 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 LJ8U5uWbvNDs for ; Mon, 19 Mar 2012 07:53:19 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 5F31D21F8844 for ; Mon, 19 Mar 2012 07:53:18 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 376F83240E5; Mon, 19 Mar 2012 15:53:17 +0100 (CET) Received: from PUEXCH81.nanterre.francetelecom.fr (unknown [10.101.44.34]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 1D31F4C135; Mon, 19 Mar 2012 15:53:17 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH81.nanterre.francetelecom.fr ([10.101.44.34]) with mapi; Mon, 19 Mar 2012 15:53:17 +0100 From: To: "Francis.Dupont@fdupont.fr" , "Hemant Singh (shemant)" Date: Mon, 19 Mar 2012 15:53:16 +0100 Thread-Topic: [v6ops] 6204bis W-6 new text proposal Thread-Index: Ac0F3ut7dKDo9lhQTEGzjtqEZgxOGQAAQjhw Message-ID: <94C682931C08B048B7A8645303FDC9F36E28557F30@PUEXCB1B.nanterre.francetelecom.fr> References: Your message of Mon, 19 Mar 2012 09:15:46 EST. <5B6B2B64C9FE2A489045EEEADDAFF2C3043A2434@XMB-RCD-109.cisco.com> <201203191445.q2JEjD8p021766@givry.fdupont.fr> In-Reply-To: <201203191445.q2JEjD8p021766@givry.fdupont.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.19.130327 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 6204bis W-6 new text proposal X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 14:53:20 -0000 Re-, Could you please explain why? Thanks. Cheers, Med=20 >-----Message d'origine----- >De : Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]=20 >Envoy=E9 : lundi 19 mars 2012 15:45 >=C0 : Hemant Singh (shemant) >Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; v6ops@ietf.org >Objet : Re: [v6ops] 6204bis W-6 new text proposal=20 > > In your previous mail you wrote: > >> W-7: In DS-Lite context, if PCP messages are exchanged=20 >using native >> IPv6 (i.e., IPv4-in-IPv6 is not used) and no PCP server is >> configured, the PCP client MUST use the address of=20 >the AFTR as >> its PCP server. > >=3D> strongly disagree: please remove the W-7 > >Regards > >Francis.Dupont@fdupont.fr >= From mohamed.boucadair@orange.com Mon Mar 19 07:57:00 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D9021F87A0 for ; Mon, 19 Mar 2012 07:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.184 X-Spam-Level: X-Spam-Status: No, score=-2.184 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=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 3dZqFGGbDxKW for ; Mon, 19 Mar 2012 07:57:00 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id E5FCD21F879A for ; Mon, 19 Mar 2012 07:56:59 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 544C318C294; Mon, 19 Mar 2012 15:56:59 +0100 (CET) Received: from PUEXCH61.nanterre.francetelecom.fr (unknown [10.101.44.32]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 3993E27C0DD; Mon, 19 Mar 2012 15:56:59 +0100 (CET) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.233.200.25]) by PUEXCH61.nanterre.francetelecom.fr ([10.101.44.32]) with mapi; Mon, 19 Mar 2012 15:56:59 +0100 From: To: "Francis.Dupont@fdupont.fr" , "Hemant Singh (shemant)" Date: Mon, 19 Mar 2012 15:56:58 +0100 Thread-Topic: [v6ops] 6204bis W-6 new text proposal Thread-Index: Ac0F31vnBqwlOJQBSXqSyrA/anRpdwAAB+Tw Message-ID: <94C682931C08B048B7A8645303FDC9F36E28557F35@PUEXCB1B.nanterre.francetelecom.fr> References: Your message of Mon, 19 Mar 2012 09:23:39 EST. <5B6B2B64C9FE2A489045EEEADDAFF2C3043A243F@XMB-RCD-109.cisco.com> <201203191448.q2JEmUjD021985@givry.fdupont.fr> In-Reply-To: <201203191448.q2JEmUjD021985@givry.fdupont.fr> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.3.19.120321 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 6204bis W-6 new text proposal X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 14:57:00 -0000 Re-, A concrete example is a user-interface (application) to configure mappings = (e.g., for a webcam, a local server) or even an IGD-PCP IWF... Cheers, Med=20 >-----Message d'origine----- >De : Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr]=20 >Envoy=E9 : lundi 19 mars 2012 15:49 >=C0 : Hemant Singh (shemant) >Cc : BOUCADAIR Mohamed OLNC/NAD/TIP; v6ops@ietf.org >Objet : Re: [v6ops] 6204bis W-6 new text proposal=20 > > In your previous mail you wrote: > >> In bullet W-6, here is the minor change. >> =20 >> s/"IPv4 PCP client"/"PCP client". > >=3D> but IPv4 must be in the text, I propose to put it before >the word "applications". > >Regards > >Francis.Dupont@fdupont.fr > >PS: BTW have we good examples of such applications? In fact >I can't see an use for the W-6... > >= From v6ops@globis.net Mon Mar 19 09:52:41 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA97521F8870 for ; Mon, 19 Mar 2012 09:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 Bkev0+IEDfkM for ; Mon, 19 Mar 2012 09:52:35 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id CD78121F886F for ; Mon, 19 Mar 2012 09:52:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 612E68700CA; Mon, 19 Mar 2012 17:52:33 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rt3bHg5MOQ6v; Mon, 19 Mar 2012 17:52:28 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id 5C1B58700BA; Mon, 19 Mar 2012 17:52:28 +0100 (CET) Message-ID: <4F67644C.3070007@globis.net> Date: Mon, 19 Mar 2012 17:52:28 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: Simon Perreault References: <201203191328.q2JDSMP7016923@givry.fdupont.fr> <4F67369C.1070402@viagenie.ca> In-Reply-To: <4F67369C.1070402@viagenie.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] 6204bis W-6 new text proposal X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 16:52:41 -0000 +1 on disagreeing proposed W-6 text. IMHO An LSN will likely be a shared resource located deep within the Internet infrastructure, so no individual end user nor single organization will likely have sufficient power to unilaterally specify which control protocol is preferred for both client and server. Inbound access is also a function that should be available to all Internet users. Any specification stating "client MAY support X OR Y" effectively implies in practice that the server (in this case the client is clearly targeted for future use with LSN) "MUST support X AND Y" in order for the desired functionality (inbound access) to be available to all users. Proposed text, which includes the wording "such as", would also not rule out having to support protocol Z (or anything else similar to X or Y) on the server side. I'm neutral on the choice of protocol(s), but having too many protocols covering the same function would likely be harmful in this case. regards, RayH Simon Perreault wrote: >
On 2012-03-19 09:28, Francis Dupont wrote: >> NEW >> >> W-6: For applications on the CE router which want to accept IPv4 >> inbound connections from the WAN side, the WAN interface of >> the CE router SHOULD support a protocol such as UPnP IGD >> [UPnP-IGD] or PCP [I-D.ietf-pcp-base]. This document takes >> no position on whether such functionality is enabled by >> default or mechanisms by which users would configure the >> functionality. > > Disagree. > > We already require a PCP server in draft-ietf-behave-lsn-requirements. > It is only logical that we require a PCP client at the other end of > the wire, isn't it? > > Simon From shemant@cisco.com Mon Mar 19 10:36:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0B721F8894 for ; Mon, 19 Mar 2012 10:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.204 X-Spam-Level: X-Spam-Status: No, score=-10.204 tagged_above=-999 required=5 tests=[AWL=0.394, 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 H+YYDZ3jkebp for ; Mon, 19 Mar 2012 10:36:55 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A428621F888C for ; Mon, 19 Mar 2012 10:36:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=6603; q=dns/txt; s=iport; t=1332178615; x=1333388215; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=84U7MhH/Ul4mJQ1nbXwjLp2E47/juuAjDvANAXFMj8E=; b=FzMRCXog68bX1cnagvtujIm6ZpSQFOEOr0TPMe46dFHGA13YEUOJtG2I 8ro4jlZ0EhSGmpMRycvEdMARzV6PiPgkpaKkSGsQJ0KcAkPG5RsJRqEml pdmdNwths69V8vKMkkTHKmGiaZBz4xk28XH1UtRpkqKYTiBSUWNbamH4U 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEZTZ0+tJXG9/2dsb2JhbABCgka0BIEHggoBAQQSAQkRA0kQAgEIDhQGGAYBVgEBBAEaGodom0KeaZAZYwSIVptSgWiDBA X-IronPort-AV: E=Sophos;i="4.73,611,1325462400"; d="scan'208,217";a="67656941" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-4.cisco.com with ESMTP; 19 Mar 2012 17:36:55 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2JHat7d018159; Mon, 19 Mar 2012 17:36:55 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Mar 2012 12:36:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD05F6.E04D72A4" Date: Mon, 19 Mar 2012 12:36:54 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A25B9@XMB-RCD-109.cisco.com> In-Reply-To: <4F67644C.3070007@globis.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6204bis W-6 new text proposal Thread-Index: Ac0F8LtApYU1nGuPQ9WT6HrOkhbHDwABe9jw References: <201203191328.q2JDSMP7016923@givry.fdupont.fr><4F67369C.1070402@viagenie.ca> <4F67644C.3070007@globis.net> From: "Hemant Singh (shemant)" To: "Ray Hunter" , "Simon Perreault" X-OriginalArrivalTime: 19 Mar 2012 17:36:55.0118 (UTC) FILETIME=[E08F16E0:01CD05F6] Cc: v6ops@ietf.org Subject: Re: [v6ops] 6204bis W-6 new text proposal X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 17:36:56 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD05F6.E04D72A4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ray, =20 Med and I agree on this text below. Does that work for you? =20 =20 W-6: The WAN interface of the CE router SHOULD support an PCP client as specified in [I-D.ietf-pcp-base] for use by applications on the CE Router. The PCP client SHOULD follow the procedure specified in Section 8.1 of [I-D.ietf-pcp-base] to discover its PCP server. This document takes no position on whether such functionality is enabled by default or mechanisms by which users would configure the functionality. Handling PCP requests from PCP clients in the LAN side of the CE Router is out of scope. =20 W-7: In DS-Lite context, if PCP messages are exchanged using native IPv6 (i.e., IPv4-in-IPv6 is not used) and no PCP server is configured, the PCP client MUST use the address of the AFTR as its PCP server. =20 Hemant =20 ------_=_NextPart_001_01CD05F6.E04D72A4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ray,

 

Med and I agree on this text = below.  Does that work for you? 

 

   W-6:  The WAN = interface of the CE router SHOULD support an PCP

         client as = specified in [I-D.ietf-pcp-base] for use by

         applications on = the CE Router.  The PCP client SHOULD = follow

         the procedure = specified in Section 8.1 of [I-D.ietf-pcp-base]

         to discover its = PCP server.  This document takes no position = on

         whether such = functionality is enabled by default or = mechanisms

         by which users = would configure the functionality.  Handling = PCP

         requests from PCP = clients in the LAN side of the CE Router is

         out of = scope.

 

   W-7:  In DS-Lite context, if PCP messages are = exchanged using native

         IPv6 (i.e., = IPv4-in-IPv6 is not used) and no PCP server is

         configured, the = PCP client MUST use the address of the AFTR as

         its PCP = server.

 

Hemant

 

------_=_NextPart_001_01CD05F6.E04D72A4-- From v6ops@globis.net Mon Mar 19 11:00:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06FAE21F87C9 for ; Mon, 19 Mar 2012 11:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.041, 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 r+N0pelwKuA3 for ; Mon, 19 Mar 2012 11:00:36 -0700 (PDT) Received: from globis01.globis.net (RayH-1-pt.tunnel.tserv11.ams1.ipv6.he.net [IPv6:2001:470:1f14:62e::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1753921F8569 for ; Mon, 19 Mar 2012 11:00:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by globis01.globis.net (Postfix) with ESMTP id 0F9878700D8; Mon, 19 Mar 2012 19:00:35 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at globis01.globis.net Received: from globis01.globis.net ([127.0.0.1]) by localhost (mail.globis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8etrMuuKnJI; Mon, 19 Mar 2012 19:00:30 +0100 (CET) Received: from Rays-iMac.local (unknown [192.168.0.3]) (Authenticated sender: Ray.Hunter@globis.net) by globis01.globis.net (Postfix) with ESMTPA id E9DC88700B9; Mon, 19 Mar 2012 19:00:29 +0100 (CET) Message-ID: <4F67743D.1050104@globis.net> Date: Mon, 19 Mar 2012 19:00:29 +0100 From: Ray Hunter User-Agent: Postbox Express 1.0.1 (Macintosh/20100705) MIME-Version: 1.0 To: "Hemant Singh (shemant)" References: <201203191328.q2JDSMP7016923@givry.fdupont.fr><4F67369C.1070402@viagenie.ca> <4F67644C.3070007@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A25B9@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A25B9@XMB-RCD-109.cisco.com> Content-Type: multipart/alternative; boundary="------------030104060206050102050306" Cc: v6ops@ietf.org Subject: Re: [v6ops] 6204bis W-6 new text proposal X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 18:00:37 -0000 This is a multi-part message in MIME format. --------------030104060206050102050306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit No objections from me. Hemant Singh (shemant) wrote: > > Ray, > > Med and I agree on this text below. Does that work for you? > > W-6: The WAN interface of the CE router SHOULD support an PCP > > client as specified in [I-D.ietf-pcp-base] for use by > > applications on the CE Router. The PCP client SHOULD follow > > the procedure specified in Section 8.1 of [I-D.ietf-pcp-base] > > to discover its PCP server. This document takes no position on > > whether such functionality is enabled by default or mechanisms > > by which users would configure the functionality. Handling PCP > > requests from PCP clients in the LAN side of the CE Router is > > out of scope. > > W-7: In DS-Lite context, if PCP messages are exchanged using native > > IPv6 (i.e., IPv4-in-IPv6 is not used) and no PCP server is > > configured, the PCP client MUST use the address of the AFTR as > > its PCP server. > > Hemant > --------------030104060206050102050306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit No objections from me.

Hemant Singh (shemant) wrote:

Ray,

 

Med and I agree on this text below.  Does that work for you? 

 

   W-6:  The WAN interface of the CE router SHOULD support an PCP

         client as specified in [I-D.ietf-pcp-base] for use by

         applications on the CE Router.  The PCP client SHOULD follow

         the procedure specified in Section 8.1 of [I-D.ietf-pcp-base]

         to discover its PCP server.  This document takes no position on

         whether such functionality is enabled by default or mechanisms

         by which users would configure the functionality.  Handling PCP

         requests from PCP clients in the LAN side of the CE Router is

         out of scope.

 

   W-7:  In DS-Lite context, if PCP messages are exchanged using native

         IPv6 (i.e., IPv4-in-IPv6 is not used) and no PCP server is

         configured, the PCP client MUST use the address of the AFTR as

         its PCP server.

 

Hemant

 


--------------030104060206050102050306-- From shemant@cisco.com Mon Mar 19 11:04:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809BF21F884F for ; Mon, 19 Mar 2012 11:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.211 X-Spam-Level: X-Spam-Status: No, score=-10.211 tagged_above=-999 required=5 tests=[AWL=0.387, 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 xl7i98Ltflf3 for ; Mon, 19 Mar 2012 11:04:49 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8084721F884C for ; Mon, 19 Mar 2012 11:04:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=7160; q=dns/txt; s=iport; t=1332180289; x=1333389889; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=81SsQRbWsOOUVKPudpJhwjrrkhVH7blz6gQD6FJg3C4=; b=iyEPdlOlvtf4kxCXHrOdKfAp8Ubgh1XUENNLHR1g+8VaCxpcU/rVXbCw MdO/BjSXiCetQO8CgOhT7k0EoYvv/ErZQ2yvj6Efu8eKh0OOGioW78O5A Tstt2wYscNXzaQ01BJH6cJVXPXIkfHbCRqbl1/aV0/PUlfW10kuH8i0bU I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFANhTZ0+tJV2d/2dsb2JhbABCgka0BYEHggkBAQEEEgEJEQNJEAIBCA4DBAEBCwYXAQYBRQkIAQEEEwgah2ibQp5pkBljBIhWm1KBaIME X-IronPort-AV: E=Sophos;i="4.73,611,1325462400"; d="scan'208,217";a="67441089" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 19 Mar 2012 18:04:45 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q2JI4iFb030762; Mon, 19 Mar 2012 18:04:44 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Mar 2012 13:04:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD05FA.C330F884" Date: Mon, 19 Mar 2012 13:04:43 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A25FE@XMB-RCD-109.cisco.com> In-Reply-To: <4F67743D.1050104@globis.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] 6204bis W-6 new text proposal Thread-Index: Ac0F+jDqmvUJHiF3TmSwkTG2xwaZjwAAI0qA References: <201203191328.q2JDSMP7016923@givry.fdupont.fr><4F67369C.1070402@viagenie.ca> <4F67644C.3070007@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A25B9@XMB-RCD-109.cisco.com> <4F67743D.1050104@globis.net> From: "Hemant Singh (shemant)" To: "Ray Hunter" X-OriginalArrivalTime: 19 Mar 2012 18:04:44.0197 (UTC) FILETIME=[C3685550:01CD05FA] Cc: v6ops@ietf.org Subject: Re: [v6ops] 6204bis W-6 new text proposal X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 18:04:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD05FA.C330F884 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ray, =20 Thanks much! =20 Hemant =20 From: Ray Hunter [mailto:v6ops@globis.net]=20 Sent: Monday, March 19, 2012 2:00 PM To: Hemant Singh (shemant) Cc: Simon Perreault; v6ops@ietf.org Subject: Re: [v6ops] 6204bis W-6 new text proposal =20 No objections from me. Hemant Singh (shemant) wrote:=20 Ray,=20 =20 Med and I agree on this text below. Does that work for you? =20 =20 W-6: The WAN interface of the CE router SHOULD support an PCP=20 client as specified in [I-D.ietf-pcp-base] for use by=20 applications on the CE Router. The PCP client SHOULD follow=20 the procedure specified in Section 8.1 of [I-D.ietf-pcp-base]=20 to discover its PCP server. This document takes no position on whether such functionality is enabled by default or mechanisms=20 by which users would configure the functionality. Handling PCP requests from PCP clients in the LAN side of the CE Router is=20 out of scope.=20 =20 W-7: In DS-Lite context, if PCP messages are exchanged using native=20 IPv6 (i.e., IPv4-in-IPv6 is not used) and no PCP server is=20 configured, the PCP client MUST use the address of the AFTR as=20 its PCP server.=20 =20 Hemant=20 =20 =20 ------_=_NextPart_001_01CD05FA.C330F884 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ray,

 

Thanks much!

 

Hemant

 

From: Ray Hunter [mailto:v6ops@globis.net]
Sent: Monday, = March 19, 2012 2:00 PM
To: Hemant Singh = (shemant)
Cc: Simon Perreault; = v6ops@ietf.org
Subject: Re: [v6ops] 6204bis W-6 new text = proposal

 

No = objections from me.

Hemant Singh (shemant) wrote: =

Ray,

  =

Med and I agree on this text below.  Does that = work for you? 

  =

   W-6:  The WAN interface of the CE = router SHOULD support an PCP =

         = client as specified in [I-D.ietf-pcp-base] for use by =

         = applications on the CE Router.  The PCP client SHOULD follow =

         the = procedure specified in Section 8.1 of [I-D.ietf-pcp-base] =

         to = discover its PCP server.  This document takes no position on =

         = whether such functionality is enabled by default or mechanisms =

         by = which users would configure the functionality.  Handling PCP =

         = requests from PCP clients in the LAN side of the CE Router is =

         out = of scope.

 

   = W-7:  In DS-Lite context, if PCP messages are exchanged using = native =

         IPv6 = (i.e., IPv4-in-IPv6 is not used) and no PCP server is =

         = configured, the PCP client MUST use the address of the AFTR as =

         its = PCP server.

 

Hemant =

 

 

------_=_NextPart_001_01CD05FA.C330F884-- From jiangsheng@huawei.com Mon Mar 19 18:23:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E0821F881C for ; Mon, 19 Mar 2012 18:23:47 -0700 (PDT) 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 SOkVbtE9OWWc for ; Mon, 19 Mar 2012 18:23:46 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 456E321F880E for ; Mon, 19 Mar 2012 18:23:46 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEF40765; Mon, 19 Mar 2012 21:23:46 -0400 (EDT) Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Mar 2012 18:22:41 -0700 Received: from SZXEML437-HUB.china.huawei.com (10.72.61.72) by dfweml406-hub.china.huawei.com (10.193.5.131) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 19 Mar 2012 18:22:40 -0700 Received: from SZXEML506-MBS.china.huawei.com ([169.254.3.15]) by szxeml437-hub.china.huawei.com ([10.72.61.72]) with mapi id 14.01.0323.003; Tue, 20 Mar 2012 09:22:34 +0800 From: Sheng Jiang To: "v6ops@ietf.org WG" Thread-Topic: ULA usage recommendations Thread-Index: AQHNBjftq8xsy5BUX0SBb8HAWntBuA== Date: Tue, 20 Mar 2012 01:22:34 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B92191C2193@SZXEML506-MBS.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.88] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [v6ops] ULA usage recommendations X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 01:23:47 -0000 SGksIGFsbCwNCg0KV2l0aCBhIG5ld2x5IHVwZGF0ZSB2ZXJzaW9uLCB0aGUgYXV0aG9ycyBoYXZl IGRyYXduIHNvbWUgcmVjb21tZW5kYXRpb25zIGZvciBVTEEgdXNhZ2UsIHdoaWxlIHRoZXJlIGlz IHN0aWxsIGNvbnRyb3ZlcnN5IGZvciBVTEErUEEuIFdlIHN1bW1hcnkgdGhlc2UgcmVjb21tZW5k YXRpb25zIGJlbG93LiBXZSB3b3VsZCBsaWtlIHRvIGhlYXIgdGhlIFdHIG9waW5pb25zLCBwYXJ0 aWN1bGFybHksIG9uIHdoZXRoZXIgdGhlIGJlbmVmaXRzIG9mIFVMQStQQSBtb2RlbCBhcmUgd29y dGh5IGl0cyBjb21wbGV4aXR5Lg0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1s aXUtdjZvcHMtdWxhLXVzYWdlLWFuYWx5c2lzLTAyDQoNCjEuIFVMQSBvbmx5IGlzIGdvb2Qgc29s dXRpb24gZm9yIGlzb2xhdGVkIG5ldHdvcmtzLg0KMi4gVUxBK1BBIGNhbiBlbnN1cmUgc3RhYmxl IGFuZCBzcGVjaWZpYyBsb2NhbCBjb21tdW5pY2F0aW9uIHJlZ2FyZGxlc3Mgb2YgdGhlIElTUCB1 cGxpbmsgZmFpbHVyZSwgYnV0IGludHJvZHVjZSB0aGUgY29tcGxleGl0eSBvZiBydW5uaW5nIG11 bHRpcGxlIHByZWZpeGVzLg0KMy4gVUxBIGNhbiBiZSB1c2VkIHRvIHNlcGFyYXRlIHNwZWNpZmlj IHJvdXRpbmcvcHJlZml4IGxvY2FsbHksIHRoZSBwcmVmNjQgaXMgYSBnb29kIGV4YW1wbGUgb2Yg VUxBIHVzYWdlLg0KNC4gQXMgaW4gUkZDNjI4MSwgVUxBIGNhbiBiZSB1c2VkIGFzIHVwcGVyLWxh eWVyIGlkZW50aWZpZXJzLg0KDQpZb3VyIG9waW5pb25zIGFuZCBjb21tZW50cyBhcmUgYXBwcmVj aWF0ZWQuDQoNCkJlc3QgcmVnYXJkcywNCg0KU2hlbmcNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IE1vbmRheSwgTWFyY2ggMTIsIDIwMTIgODozOCBQ TQ0KPiBUbzogTGVvIExpdShiaW5nKQ0KPiBDYzogY2FtZXJvbi5ieXJuZUB0LW1vYmlsZS5jb207 IFNoZW5nIEppYW5nDQo+IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJh ZnQtbGl1LXY2b3BzLXVsYS11c2FnZS0NCj4gYW5hbHlzaXMtMDIudHh0DQo+IA0KPiBBIG5ldyB2 ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGl1LXY2b3BzLXVsYS11c2FnZS1hbmFseXNpcy0wMi50eHQg aGFzDQo+IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBCaW5nIExpdSBhbmQgcG9zdGVk IHRvIHRoZSBJRVRGDQo+IHJlcG9zaXRvcnkuDQo+IA0KPiBGaWxlbmFtZToJIGRyYWZ0LWxpdS12 Nm9wcy11bGEtdXNhZ2UtYW5hbHlzaXMNCj4gUmV2aXNpb246CSAwMg0KPiBUaXRsZToJCSBBbmFs eXNpcyBhbmQgcmVjb21tZW5kYXRpb24gZm9yIHRoZSBVTEEgdXNhZ2UNCj4gQ3JlYXRpb24gZGF0 ZToJIDIwMTItMDMtMTINCj4gV0cgSUQ6CQkgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IE51bWJl ciBvZiBwYWdlczogOQ0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIFRoaXMgZG9jdW1lbnQgZGVzY3Jp YmVzIHVzZSBjYXNlcyB3aGVyZSBVTEEgYWRkcmVzcyBtYXkgYmUNCj4gICAgYmVuZWZpY2lhbGx5 IHVzZWQuDQo+IA0KPiANCj4gDQo+IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0K From ichiroumakino@gmail.com Tue Mar 20 04:36:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9A321F86A6 for ; Tue, 20 Mar 2012 04:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 LnQPjL9w+KcQ for ; Tue, 20 Mar 2012 04:36:55 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id B4B7521F8677 for ; Tue, 20 Mar 2012 04:36:54 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so4025619wib.13 for ; Tue, 20 Mar 2012 04:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=7/4sLWPk5XqKuCbA/dscRhYdhnGkndeNE6diMvu0zOg=; b=kWVF+qjmU1HrWtLSHGY6NUEw8lGUcz+U2LIqDvpx4qBHed+mW6nsvC8e2HbwXKlcd6 AI6Qt40mPmc+1WyYNUYWnjPZVSCA1gnMp/z6rOQJZ4seDV4cWfQR/aeFYbsrzZCLjU6g Nro0RfEirlQCl4T/KuvEVnpuDRi4TSeb7cghMRSW4Mefle/ug3Wn71ZT1FQ0DphUP7UD OTPDnqYWNii1R4DiEVEQRLy1md1zNxo29eI0uyqHorHt22OEg77OXT7i9pO2NPHiE4Op 4f4qPcd9qDLEUWpk8uUBSskwBZ/aG35Dm9yWj1O3sndr/4C+g8yJ2C6+5sqWokDaWVXC YrXQ== Received: by 10.216.134.233 with SMTP id s83mr9118126wei.104.1332243413976; Tue, 20 Mar 2012 04:36:53 -0700 (PDT) Received: from [10.147.13.124] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id fl2sm5604458wib.4.2012.03.20.04.36.52 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Mar 2012 04:36:53 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A239F@XMB-RCD-109.cisco.com> Date: Tue, 20 Mar 2012 12:36:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <702415E0-2849-4AB9-BA8E-BD312A7EE8EE@employees.org> References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> <9B1C4EC1-50ED-436F-876A-1F2512BB54C9@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A2349@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A239F@XMB-RCD-109.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1257) Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 11:36:56 -0000 >> DHCPv6 PD does not use the M/O flags. neither should it, they are = overloaded as it is. >=20 > There is no IETF document that says DHCPv6 PD does not use the M = flags. I am not sold on the overloading just yet. M=3D0, O=3D0 in RFC = 4861 indicates no DHCPv6 services are available. more correctly there is no document that says PD uses the M flag. the M = flag is the "Managed address configuration " flag. >> DHCPv6 PD is a protocol between _routers_ from a pure DHCPv6 sense, a = requesting router is not required to do any of the host functions = specified in >6204.=20 >=20 > The requesting router sent a DHCPv6 SOLICIT asking for an address = (IA_NA IA_Address) and also an IA_PD. The requesting router just = performed a host addressing function with the IA_NA option in the = SOLICIT. The most common protocol running between two routers is = routing. Just because IA_PD acquisition runs between two routers = doesn't mean the M and the O bits can be so blatantly ignored because = DHCPv6 is used to acquire the IA_PD. Specifically, the DHCPv6 client in = the requesting router is served by the DHCPv6 server in the delegating = router.=20 they serve as hints, I doubt that can be considered "blatantly ignored". >> in addition we still want to allow for the Router discovery and DHCP = PD processing to be done in parallel. >=20 > Router discovery fails. Does it now even make sense to initiate = DHCPv6 PD processing because DHCPv6 processing is likely to fail too. = If DHCPv6 does not fail and a PD is acquired, the requesting router does = not have a default router which is learnt from the ND RA. Now the = requesting router cannot send packets upstream. What good is such a = setup? router discovery is only one of many ways of doing router discovery. = imagine a PPP link, where there isn't a need for router discovery at = all. Ole From shemant@cisco.com Tue Mar 20 05:34:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0DE21F8685 for ; Tue, 20 Mar 2012 05:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.068 X-Spam-Level: X-Spam-Status: No, score=-10.068 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 Au3LPtQn8czP for ; Tue, 20 Mar 2012 05:34:24 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id B6FF021F8649 for ; Tue, 20 Mar 2012 05:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=7979; q=dns/txt; s=iport; t=1332246864; x=1333456464; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=cHl+sV9y3tpzeSKZSj1Q6v+wZusHjtdg6gtBnbb3A04=; b=a6D2o8IVidrNFaH6Yt5sM4LkaIlTjYCMMWIv+IxlFWqLMlv00JUxtFTT s11lXKmZW6IAHHcXx8gt9JAjo5N94EhIQxi/RXzFIumBZcn2mKRDnw2S3 /xSEuA8x3WZwZB1YIJCgsUTd4eMr43nxdc+TBbwlxBGoJWJrimzHDfwe3 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAEF4aE+tJXG//2dsb2JhbABBgkarGgGIboEHggkBAQEEEgEJEQNJDAQCAQgRBAEBCwYXAQYBICUJCAEBBBMIGodoC5gFnyiJbIYvYwSIIzOYN4MRgWiDBQ X-IronPort-AV: E=Sophos;i="4.73,618,1325462400"; d="scan'208,217";a="67870296" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 20 Mar 2012 12:34:24 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2KCYONY016498; Tue, 20 Mar 2012 12:34:24 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Mar 2012 07:34:24 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD0695.C7E484D4" Date: Tue, 20 Mar 2012 07:34:23 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C3043A2859@XMB-RCD-109.cisco.com> In-Reply-To: <702415E0-2849-4AB9-BA8E-BD312A7EE8EE@employees.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6204bis WGLC Thread-Index: Ac0GjcNHIosulAfPRjayXX4nfuA3GQABqxrw References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> <9B1C4EC1-50ED-436F-876A-1F2512BB54C9@employees.org> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A2349@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A239F@XMB-RCD-109.cisco.com> <702415E0-2849-4AB9-BA8E-BD312A7EE8EE@employees.org> From: "Hemant Singh (shemant)" To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-OriginalArrivalTime: 20 Mar 2012 12:34:24.0024 (UTC) FILETIME=[C813B180:01CD0695] Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 12:34:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD0695.C7E484D4 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 -----Original Message----- From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole = Tr=F8an Sent: Tuesday, March 20, 2012 7:37 AM To: Hemant Singh (shemant) Cc: v6ops@ietf.org; v6ops-chairs@tools.ietf.org; Ron Bonica; = C.Donley@cablelabs.com Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC =20 >router discovery is only one of many ways of doing router discovery. = imagine a PPP link, where there isn't a need for router discovery at = >all. =20 What specific deployment is the PPP link in? Cellular, DSL broadband, = backbone routers? More details on L2/L3 topology, addressing of CE = routers and details deployment would help. A pointer to an IETF = document describing the deployment would be even better. For example = PPP does use an RA in Softwire Hub and Spoke. =20 http://tools.ietf.org/html/rfc5571 =20 Hemant ------_=_NextPart_001_01CD0695.C7E484D4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

-----Original Message-----
From: = Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole = Tr=F8an
Sent: Tuesday, March 20, 2012 7:37 AM
To: Hemant Singh = (shemant)
Cc: v6ops@ietf.org; v6ops-chairs@tools.ietf.org; Ron = Bonica; C.Donley@cablelabs.com
Subject: Re: [v6ops] = draft-ietf-v6ops-6204bis WGLC

 

>router discovery is only one of many = ways of doing router discovery. imagine a PPP link, where there isn't a = need for router discovery at >all.

 

What specific deployment = is the PPP link in?=A0 Cellular, DSL broadband, backbone routers? = =A0More details on L2/L3 topology, addressing of CE routers and details = deployment would help.=A0 A pointer to an IETF document describing the = deployment would be even better.=A0 For example PPP does use an RA in = Softwire Hub and Spoke.

 

http://tools.ietf.org/html/rf= c5571

 

Hemant

------_=_NextPart_001_01CD0695.C7E484D4-- From furry13@gmail.com Tue Mar 20 05:47:04 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2551421F8655 for ; Tue, 20 Mar 2012 05:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 3-fzY7GGYFQE for ; Tue, 20 Mar 2012 05:47:03 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6B5BC21F8627 for ; Tue, 20 Mar 2012 05:47:03 -0700 (PDT) Received: by werb10 with SMTP id b10so8290200wer.31 for ; Tue, 20 Mar 2012 05:47:02 -0700 (PDT) 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=4em2iynDEXT3oHVeL5Z7LT2VgRgQw74jQmjzRjy2dLU=; b=wH8tozG8tWPpjPgjstCks3jFuVZG0H+yBcm64QY/sloFcB3i1xDqwFtjrpX0teuv2s qxc84UPMw9znQjVPTjROD0jNUptH0KZdZWisJFOgjh9h5HO9UG0Bofqq4LlJyR+BYYOw NEDX6x+Z/46P9VwaJ0F8M43YkLyjHutrPdpO1zrobxFlGHqoMI8Rk3gcNr/2zfC5XdK1 v0CiAhfCWz1QpeQHmHcC7Kwk63wAD4dKzdelhgoe+tOprfRXEs0QqVonqqqcUohju1zL /M+tJCSJ8XhIKPHwXMqO3SGwc5tpKdJ0gAMHQIvGHPEDQsUa4HdDmLJBnAeyTEOwAvjB NeKQ== MIME-Version: 1.0 Received: by 10.216.136.72 with SMTP id v50mr9399237wei.73.1332247622614; Tue, 20 Mar 2012 05:47:02 -0700 (PDT) Received: by 10.223.60.207 with HTTP; Tue, 20 Mar 2012 05:47:02 -0700 (PDT) In-Reply-To: <51865E1A72F61D48A247348DCCBA5CFB05B9154C@XMB-AMS-105.cisco.com> References: <51865E1A72F61D48A247348DCCBA5CFB05B9154C@XMB-AMS-105.cisco.com> Date: Tue, 20 Mar 2012 23:47:02 +1100 Message-ID: From: Jen Linkova To: "Michael Behringer (mbehring)" Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 12:47:04 -0000 Hi Michael, On Thu, Mar 8, 2012 at 8:56 PM, Michael Behringer (mbehring) wrote: > V6ops WG, > Eric and myself published a new draft, which is in the context of v6ops. > We'd like to solicit feedback. > > We feel there are substantial advantages to only using link-local > addresses on core links, and propose this model as a "best common > practice". However, there are some caveats. > > Our draft lists advantages and disadvantages to allow network operators > to make a factual decision on whether this model fits their needs. The suggested design does look very elegant, it does work but I have a few comments: - as it has been mentioned before, troubleshooting/diagnostic tools could get broken (unless we are 100% sure that address selection works as expected which isn't a case currently :(( - one of caveats not mentioned in the doc: let's say I have two links between two routers and I need to construct a *strict* ERO for an LSP to control which link is used. Speaking of advantages: "If a network only uses loopback addresses for the routers, only those loopback addresses need to be protected from outside the network." - if loopbacks are addressed from the same block as core links, I don't believe using LLA only would simplify your filters significantly. You'd probably have the same policy for loopbacks as for core links anyway. --- SY, Jen Linkova aka Furry From C.Grundemann@cablelabs.com Tue Mar 20 13:36:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38CF921F8639 for ; Tue, 20 Mar 2012 13:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.141 X-Spam-Level: X-Spam-Status: No, score=0.141 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, MIME_8BIT_HEADER=0.3] 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 2rLWki6GETQf for ; Tue, 20 Mar 2012 13:36:31 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id C961921F8584 for ; Tue, 20 Mar 2012 13:36:30 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q2KKaMMG024204; Tue, 20 Mar 2012 14:36:22 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 20 Mar 2012 14:36:22 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Tue, 20 Mar 2012 14:36:22 -0600 From: Chris Grundemann To: =?iso-8859-1?Q?Ole_Tr=F8an?= , Hemant Singh Date: Tue, 20 Mar 2012 14:36:18 -0600 Thread-Topic: [v6ops] draft-ietf-v6ops-6204bis WGLC Thread-Index: Ac0G2RxKlB6clMQXR960EG0tX6YgZA== Message-ID: In-Reply-To: <702415E0-2849-4AB9-BA8E-BD312A7EE8EE@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" , Ronald Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 20:36:32 -0000 On 3/20/12 5:36 AM, "Ole Tr=F8an" wrote: >>> DHCPv6 PD does not use the M/O flags. neither should it, they are >>>overloaded as it is. >>=20 >> There is no IETF document that says DHCPv6 PD does not use the M flags. >> I am not sold on the overloading just yet. M=3D0, O=3D0 in RFC 4861 >>indicates no DHCPv6 services are available. > >more correctly there is no document that says PD uses the M flag. the M >flag is the "Managed address configuration " flag. Yes, and the O flag is the "Other configuration" flag. PD is certainly other DHCPv6 configuration information. In fact, RFC 4861 is quite clear on this point, it states: "If neither M nor O flags are set, this indicates that no information is available via DHCPv6." (emphasis on 'NO information') Cheers, ~Chris >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From C.Grundemann@cablelabs.com Tue Mar 20 14:59:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62FC921F8582 for ; Tue, 20 Mar 2012 14:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.047 X-Spam-Level: X-Spam-Status: No, score=-0.047 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 lxfNVqGvusnd for ; Tue, 20 Mar 2012 14:59:34 -0700 (PDT) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id E098321F854A for ; Tue, 20 Mar 2012 14:59:33 -0700 (PDT) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id q2KLxVj3002155; Tue, 20 Mar 2012 15:59:31 -0600 Received: from srvxchg.cablelabs.com (10.5.0.15) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Tue, 20 Mar 2012 15:59:31 -0600 (MDT) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from srvxchg.cablelabs.com ([10.5.0.15]) by srvxchg ([10.5.0.15]) with mapi; Tue, 20 Mar 2012 15:59:31 -0600 From: Chris Grundemann To: Fred Baker , "v6ops@ietf.org" Date: Tue, 20 Mar 2012 15:59:29 -0600 Thread-Topic: [v6ops] draft-ietf-v6ops-6204bis WGLC Thread-Index: Ac0G5LpucpTGe0qOTn2ZtKn7pCADGA== Message-ID: In-Reply-To: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Cc: "v6ops-chairs@tools.ietf.org" , Ronald Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 21:59:34 -0000 The current versions (-07 and -08 alike) of this document contain much needed updates to the IPv6 customer edge router requirements, especially considering the impending World IPv6 Launch event. This is certainly an important document and its content is ready to move forward. As others have already noted, there are potential issues in this space which will likely need to be addressed in the future but our best course of action is to move the current changes in 6204bis forward and circle back when appropriate with a 6204ter to address them. In addition to the items already mentioned, it is possible that Homenet will produce new requirements in the future that will need to be incorporated into a 6204ter as well. Holding up 6204bis at this stage is counter productive. Cheers, ~Chris On 3/8/12 2:30 PM, "Fred Baker" wrote: >This is to initiate a two week working group last call of >draft-ietf-v6ops-6204bis. Please read it now. If you find nits (spelling >errors, minor suggested wording changes, etc), comment to the authors; if >you find greater issues, such as disagreeing with a statement or finding >additional issues that need to be addressed, please post your comments to >the list. The draft will be on the agenda at IETF 83, and I would like to >send the authors home with a work plan to complete it if it is not to the >WG's liking. > >We are looking specifically for comments on the importance of the >document as well as its content. If you have read the document and >believe it to be of operational utility, that is also an important >comment to make. >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From tjc@ecs.soton.ac.uk Tue Mar 20 15:07:50 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 221E921F8594 for ; Tue, 20 Mar 2012 15:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.181 X-Spam-Level: X-Spam-Status: No, score=-2.181 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=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 WkZ-dPFcpFsH for ; Tue, 20 Mar 2012 15:07:49 -0700 (PDT) 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 B123721F8581 for ; Tue, 20 Mar 2012 15:07:47 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q2KM7g5L026180 for ; Tue, 20 Mar 2012 22:07:42 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q2KM7g5L026180 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1332281262; bh=D615bY/nl2SQI1bSqSZ4EzVeMhM=; h=From:Mime-Version:Subject:Date:In-Reply-To:To:References; b=EgnfqzG2/XMAKvZpyk4L4cPtYO+lxlCyPFSS4YH7qpAUDoLg5Wgz7oDf4J1E1RKHW L7LbYL2Cqh19ZCDN+UWz/omAVHtDiB2NO4ztQMAqw37qP1Nbrp/3g6ChheuU25n4Pd tLc5N9H4Js5EQ3jHCI/4Rx+rXCM8h0CcKvynf3Y0= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id o2JM7g05437375715S ret-id none; Tue, 20 Mar 2012 22:07:42 +0000 Received: from [192.168.1.102] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q2KM7YsC023799 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 20 Mar 2012 22:07:34 GMT From: Tim Chown Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_E33F41B1-D10D-4AF7-B7D5-63C1FDB0944F" Date: Tue, 20 Mar 2012 22:07:34 +0000 In-Reply-To: <867F4B6A1672E541A94676D556793ACD0EB9950A19@MOPESMBX01.eu.thmulti.com> To: IPv6 Operations References: <867F4B6A1672E541A94676D556793ACD0EB995043C@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C3042FEBDB@XMB-RCD-109.cisco.com><4F61E53D.4050904@globis.net><5B6B2B64C9FE2A489045EEEADDAFF2C3043A1C75@XMB-RCD-109.cisco.com><4F62F576.3070209@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1FB5@XMB-RCD-109.cisco.com> <2D09D61DDFA73D4C884805CC7865E6110724B2@GAALPA1MSGUSR9N.ITServices.sbc.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A2270@XMB-RCD-109.cisco.com> <4F64E50C.4010602@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A231A@XMB-RCD-109.cisco.com> <4F651042.5060909@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A232A@XMB-RCD-109.cisco.com> <4F65A29B.6030207@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A233D@XMB-RCD-109.cisco.com> <867F4B6A1672E541A94676D556793ACD0EB9950A19@MOPESMBX01.eu.thmulti.com> <6EC024F7-B3C9-4527-960A-769B35BD6AD5@ecs.soton.ac.uk> Message-ID: X-Mailer: Apple Mail (2.1257) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o2JM7g054373757100; tid=o2JM7g05437375715S; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q2KM7g5L026180 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [v6ops] RFC6204bis-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Mar 2012 22:07:50 -0000 --Apple-Mail=_E33F41B1-D10D-4AF7-B7D5-63C1FDB0944F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 19 Mar 2012, at 07:47, Wuyts Carl wrote: > I=92m ok with the new things added in bold, still find it a bit odd = that the CPE =93MUST=94 ask for a prefix large enough, as large enough = is first of all hard to define + you should, in next req, log a system = error if you run out of /64=92s on handing them out, so in fact meaning = that you asked a =93too small=94 prefix. Moreover, =93one should be = able to configure a different hint=94, but the hint is =91=94just=94 a = hint + one MAY do this, not mandatory, hence this does not deliver any = added value. Please note that lots of people will not be able to = configure anything in this area, for the simple reason that they should = not even know how it works. The avg home user is interested in =85 = connectivity, not in size of prefixes, not in IPv6 vs IPv4, etc. Indeed, the current homenet architecture draft says the homenet must be = self-organising as far as possible, to not expose details to users. We = say it should support arbitrary topologies, which means there may be = internal routers. I think if 6204bis is talking about internal = interface behaviour, it should if possible be in sync with what's agreed = in homenet. Though I appreciate Hemant's desire to put the 6204bis = text to bed. > Anyway, to conclude: > For the below > WPD-3 for sure is ok. You hand out /64s and possibly log a message = when you =93run out=94. So if you look at draft-ietf-homenet-arch-02, then section 3.4.7 = includes requirement PD6 that talks about prefix pool exhaustion (though = it can't say much; if you run out, you're hosed in some way, unless you = can ask for and get a bigger prefix). > WPD-2 is ok wrt hinting the prefix size, ok wrt adding a ref to = RFC6177 (to highlight the importance of prefix sizes), but the = configurable part should be left out, as it doesn=92t bring any real = added value (apart from extra config possibility to be added to the = CPE). So the text on prefix delegation in section 3.4.7 of the homenet draft = also applies here, and we also talk about adapting to ISP constraints in = 3.4.11. We note there that ISPs may allocate arbitrary sized prefixes, = e.g. /56 or /60, and the homenet should make no assumption about the = size of prefix offered. We cite rfc6177 also. WPD-2 says "large enough for a /64 per interface", but the homenet may = also have internal routers. While some routing principles/requirements = have been documented, the routing protocol for homenet is not yet = determined; it may or may not be aware of the homenet topology. Tim > From: Hemant Singh (shemant) [mailto:shemant@cisco.com]=20 > Sent: zondag 18 maart 2012 15:27 > To: Ray Hunter > Cc: STARK, BARBARA H; v6ops@ietf.org; Wuyts Carl > Subject: RE: [v6ops] RFC6204bis-07 > =20 > Ray, > =20 > Ok, I understand the extra important clarification New text in each = bullet is highlighted in bold. > =20 > WPD-2: The IPv6 CE router MAY indicate as a hint to the delegating > router the size of the prefix it requires. If so, it MUST > ask for a prefix large enough to assign one /64 for each of > its interfaces, rounded up to the nearest nibble, and SHOULD > be configurable to ask for more. Best Current Practice for > IPv6 Address Assignment to End Sites is provided in BCP 157 > (RFC6177) [RFC6177]. >=20 > =20 > WPD-3: The IPv6 CE router MUST be prepared to accept a delegated > prefix size different from what is given in the hint. If the > delegated prefix is too small to address all of its = interfaces, > the IPv6 CE router assigns a /64 to each interface until a /64 > is not available to assign to another interface. Then the = IPv6 > CE router SHOULD log a system management error. > =20 > Thanks and regards, > =20 > Hemant > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail=_E33F41B1-D10D-4AF7-B7D5-63C1FDB0944F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 19 Mar 2012, at 07:47, Wuyts Carl = wrote:

I=92m ok with the new = things added in bold, still find it a bit odd that the CPE =93MUST=94 = ask for a prefix large enough, as large enough is first of all hard to = define + you should, in next req, log a system error if you run out of = /64=92s on handing them out, so in fact meaning that you asked a =93too = small=94 prefix.  Moreover, =93one should be able to configure a = different hint=94, but the hint is =91=94just=94 a hint + one MAY do = this, not mandatory, hence this does not deliver any added value.  = Please note that lots of people will not be able to configure anything = in this area, for the simple reason that they should not even know how = it works.  The avg home user is interested in =85 connectivity, not = in size of prefixes, not in IPv6 vs IPv4, = etc.

Indeed, = the current homenet architecture draft says the homenet must be = self-organising as far as possible, to not expose details to users. =  We say it should support arbitrary topologies, which means there = may be internal routers.  I think if 6204bis is talking about = internal interface behaviour, it should if possible be in sync with = what's agreed in homenet.   Though I appreciate Hemant's desire to = put the 6204bis text to bed.

Anyway, to conclude:
For the = below
WPD-3 for sure is ok.  You hand out /64s and = possibly log a message when you =93run = out=94.

So= if you look at draft-ietf-homenet-arch-02, then section 3.4.7 = includes requirement PD6 that talks about prefix pool exhaustion (though = it can't say much; if you run out, you're hosed in some way, unless you = can ask for and get a bigger prefix).

WPD-2 is ok wrt hinting the prefix size, ok wrt = adding a ref to RFC6177 (to highlight the importance of prefix sizes), = but the configurable part should be left out, as it doesn=92t bring any = real added value (apart from extra config possibility to be added to the = CPE).

So the = text on prefix delegation in section 3.4.7 of the homenet = draft also applies here, and we also talk about adapting to ISP = constraints in 3.4.11.  We note there that ISPs may allocate = arbitrary sized prefixes, e.g. /56 or /60, and the homenet should make = no assumption about the size of prefix offered.  We cite rfc6177 = also.

WPD-2 says "large enough for a /64 per = interface", but the homenet may also have internal routers. While some = routing principles/requirements have been documented, the routing = protocol for homenet is not yet determined; it may or may not be aware = of the homenet = topology.

Tim


 Hemant Singh (shemant) = [mailto:shemant@cisco.com] 
Sent: zondag 18 maart 2012 = 15:27
To: Ray = Hunter
Cc: STARK, BARBARA H; v6ops@ietf.org; Wuyts = Carl
Subject: RE: [v6ops] = RFC6204bis-07
 
Ray,
 
Ok, I understand the extra important = clarification  New text in each bullet is highlighted in = bold.
 Best = Current Practice for

 
WPD-3:  The IPv6 CE router MUST = be prepared to accept a delegated
 assigns a = /64 to each interface until a /64
        CE = router SHOULD log a system = management error.
v6ops@ietf.org
https://www.ietf.org/= mailman/listinfo/v6ops

= --Apple-Mail=_E33F41B1-D10D-4AF7-B7D5-63C1FDB0944F-- From denghui02@gmail.com Wed Mar 21 01:18:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 928DB21F857F for ; Wed, 21 Mar 2012 01:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.077 X-Spam-Level: X-Spam-Status: No, score=-103.077 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, 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 TTvIjJhxyoSM for ; Wed, 21 Mar 2012 01:18:10 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7140021F857D for ; Wed, 21 Mar 2012 01:17:57 -0700 (PDT) Received: by ggmi1 with SMTP id i1so787918ggm.31 for ; Wed, 21 Mar 2012 01:17:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Q47OeZ3cBSFnvSyLZteXjgt97Q0lB461hEGbHRSCctA=; b=j3Qe6vrBpYYLEMG8kt6PEGq7UWw2Fq1FKqnhJjGwOE7+uJ6sdITbW3+j3E3aXHisj4 gNAxflZy6U6f7zul4/hz2mdIoDZc40RxzMoNsjmKuic1f6YW/VZO5oswUPFQLIIpUeKb 5XXbkITy0O18XZ5iOsvQcgz+hcLBOvEts59xLW+lnSCZ+t7MpAkA+KcKEmVjrzQorLqM 64Zwjwe2PBFd/T7oSrkheMHgj8PfQTGVkHi4Ln/XAYIL67JvnqtvILJFMGXq2Qw0apLs 4yhyS1hkakIg1Lmo6ggBmep/HzqBAgg1PeK7RVupqBgEiD/vg4MnJrOsLeJA0Ae7fPvn ujVg== MIME-Version: 1.0 Received: by 10.236.138.110 with SMTP id z74mr2739921yhi.114.1332317876816; Wed, 21 Mar 2012 01:17:56 -0700 (PDT) Received: by 10.147.112.1 with HTTP; Wed, 21 Mar 2012 01:17:56 -0700 (PDT) Date: Wed, 21 Mar 2012 16:17:56 +0800 Message-ID: From: Hui Deng To: v6ops@ietf.org Content-Type: multipart/alternative; boundary=20cf303a3271c689dc04bbbc6ddf Subject: [v6ops] Comments on draft-gundavelli-v6ops-community-wifi-svcs-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 08:18:12 -0000 --20cf303a3271c689dc04bbbc6ddf Content-Type: text/plain; charset=ISO-8859-1 Hello authors, Thanks for writing this draft, I have several comments below: 1) I searched the whole document, only 2,3 place have mentioned IPv6, don't know whether it is related to v6ops, considering Intarea? 2) It is a good tutorial for people who start to work on wifi. would that be possible to describe each section related to IETF work such as mentioning capwap, EAP, pmip6/GTP,diameter et al. 3) Recent wifi authentication work mostly is based on portal, but guess future would be based on EAP to have some disucssion on this would be helpful? Best, -Hui --20cf303a3271c689dc04bbbc6ddf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello authors,
=A0
Thanks for writing this draft, I have several comments below:
1) I searched the whole document, only 2,3 place have mentioned IPv6, =
don't know whether it is related to v6ops, considering Intarea?
=A0
2) It is a good tutorial for people who start to work on wifi. would t= hat be possible
to describe each section related to IETF work such as mentioning capwa= p, EAP, pmip6/GTP,diameter et al.
=A0
3) Recent wifi authentication=A0work mostly is based on portal, but gu= ess future would be based on EAP
to have some disucssion on this would be helpful?
=A0
Best,
=A0
-Hui
=A0
=A0
--20cf303a3271c689dc04bbbc6ddf-- From shemant@cisco.com Wed Mar 21 07:50:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6EE21F8711 for ; Wed, 21 Mar 2012 07:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.072 X-Spam-Level: X-Spam-Status: No, score=-10.072 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 OUrCWk2E1WCW for ; Wed, 21 Mar 2012 07:50:51 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id C653821F870A for ; Wed, 21 Mar 2012 07:50:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=473; q=dns/txt; s=iport; t=1332341451; x=1333551051; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=hqmxQFfCeYvt5gc9T4+29d9BLqj+YnDSxSIwsNX2LBU=; b=Uaw3/bKSupZ1fXqtSVSnUfiBwSuMuVzUJaYmlNRTglsYT/7wipTT/yNF 7Orhz7NTFufj3AGLnKT3sDsyrFot6kQOitHJkT9HUf0KPatNTTzm6DHLt ZWf98vzQ6NisohrKvHMJMSH8g36PwVQ7bgCDb/BiKC4e//rjc7103n5yJ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAL3paU+rRDoG/2dsb2JhbABDtwSBB4IJAQEBBBIBHUkMBAIBCBEEAQELBhcBBgEgJQkIAQEEEwgah2cBnz2XMYlshjJjBIgjM5g3gxGBaIMF X-IronPort-AV: E=Sophos;i="4.73,623,1325462400"; d="scan'208";a="36973736" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 21 Mar 2012 14:50:49 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2LEonak023930; Wed, 21 Mar 2012 14:50:49 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Mar 2012 09:50:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Mar 2012 09:50:48 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30444A7B1@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] RFC6204bis-07 Thread-Index: Ac0FhZ8EOmxleCKyR6SLWpjgzw5uVgB7Eu+g References: <867F4B6A1672E541A94676D556793ACD0EB995043C@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C3042FEBDB@XMB-RCD-109.cisco.com><4F61E53D.4050904@globis.net><5B6B2B64C9FE2A489045EEEADDAFF2C3043A1C75@XMB-RCD-109.cisco.com><4F62F576.3070209@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A1FB5@XMB-RCD-109.cisco.com> <2D09D61DDFA73D4C884805CC7865E6110724B2@GAALPA1MSGUSR9N.ITServices.sbc.com> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A2270@XMB-RCD-109.cisco.com> <4F64E50C.4010602@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A231A@XMB-RCD-109.cisco.com> <4F651042.5060909@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A232A@XMB-RCD-109.cisco.com> <4F65A29B.6030207@globis.net> <5B6B2B64C9FE2A489045EEEADDAFF2C3043A233D@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: =?iso-8859-1?Q?Ole_Tr=F8an?= X-OriginalArrivalTime: 21 Mar 2012 14:50:49.0299 (UTC) FILETIME=[014B4A30:01CD0772] Cc: Ray Hunter , v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 14:50:52 -0000 Ole, -----Original Message----- From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole = Tr=F8an Sent: Monday, March 19, 2012 12:06 AM To: Hemant Singh (shemant) Cc: Ray Hunter; v6ops@ietf.org Subject: Re: [v6ops] RFC6204bis-07 >I'd rather see the added text in the descriptive section instead of as = a requirement. >this isn't a requirement for the CE router. Agree. I will move some text to a descriptive section. Cheers back, Hemant From shemant@cisco.com Wed Mar 21 08:28:33 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D4921E8012 for ; Wed, 21 Mar 2012 08:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.926 X-Spam-Level: X-Spam-Status: No, score=-9.926 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 AIcLVI6sB64l for ; Wed, 21 Mar 2012 08:28:31 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 49A3621E800E for ; Wed, 21 Mar 2012 08:28:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=14259; q=dns/txt; s=iport; t=1332343711; x=1333553311; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=qzBpv5mbP8ok1MBDhJ5JMIPbbtO0NmUB/F47rqHQCFk=; b=JAFGcs0VJnrP4Ws5LF0bNHkoTVdvdHJ1ojEMCwzFPTxSRRbiCDIkz/7m SaAERHRpe0U9Y8TFlcxISOfkBVNvHo52vOQSwr1UukSIOcesbiKBFnmRK sSjPuGsAYqdV7Xlughb48prGIt2rNF+UKXP20pYZyEJvL5EJv0hGgjTj2 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAPbyaU+rRDoG/2dsb2JhbABEDoI4tDWBB4IJAQEBBAEBAQ8BCREDPgsQAgEIDgMEAQELBhcBBgEmHwkIAQEEARIIGodnAQuYcp8QBJAeYwSIVptIgWiCMFU X-IronPort-AV: E=Sophos;i="4.73,623,1325462400"; d="scan'208,217";a="37071927" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-2.cisco.com with ESMTP; 21 Mar 2012 15:28:30 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2LFSTTd007886; Wed, 21 Mar 2012 15:28:30 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Mar 2012 10:28:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD0777.445DD5FC" Date: Wed, 21 Mar 2012 10:28:28 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30444A808@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] RFC6204bis-07 Thread-Index: Ac0G5euD2XRj/nHBQo+7t2dvUQZ+cQAkIljw References: <867F4B6A1672E541A94676D556793ACD0EB995043C@MOPESMBX01.eu.thmulti.com><5B6B2B64C9FE2A489045EEEADDAFF2C3042FEBDB@XMB-RCD-109.cisco.com><4F61E53D.4050904@globis.net><5B6B2B64C9FE2A489045EEEADDAFF2C3043A1C75@XMB-RCD-109.cisco.com><4F62F576.3070209@globis.net><5B6B2B64C9FE2A489045EEEADDAFF2C3043A1FB5@XMB-RCD-109.cisco.com><2D09D61DDFA73D4C884805CC7865E6110724B2@GAALPA1MSGUSR9N.ITServices.sbc.com><5B6B2B64C9FE2A489045EEEADDAFF2C3043A2270@XMB-RCD-109.cisco.com><4F64E50C.4010602@globis.net><5B6B2B64C9FE2A489045EEEADDAFF2C3043A231A@XMB-RCD-109.cisco.com><4F651042.5060909@globis.net><5B6B2B64C9FE2A489045EEEADDAFF2C3043A232A@XMB-RCD-109.cisco.com><4F65A29B.6030207@globis.net><5B6B2B64C9FE2A489045EEEADDAFF2C3043A233D@XMB-RCD-109.cisco.com><867F4B6A1672E541A94676D556793ACD0EB9950A19@MOPESMBX01.eu.thmulti.com><6EC024F7-B3C9-4527-960A-769B35BD6AD5@ecs.soton.ac.uk> From: "Hemant Singh (shemant)" To: "Tim Chown" , "IPv6 Operations" X-OriginalArrivalTime: 21 Mar 2012 15:28:29.0809 (UTC) FILETIME=[44A9BE10:01CD0777] Subject: Re: [v6ops] RFC6204bis-07 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 15:28:33 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD0777.445DD5FC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Tim, =20 From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Tim Chown Sent: Tuesday, March 20, 2012 6:08 PM To: IPv6 Operations Subject: Re: [v6ops] RFC6204bis-07 =20 =20 >WPD-2 says "large enough for a /64 per interface", but the homenet may also have internal routers. While some routing >principles/requirements have been documented, the routing protocol for homenet is >not yet determined; it may or may not be aware of >the homenet topology. =20 There is a difference between a /64 assigned to a network interface and a delegated prefix that may be shorter than that. The text in rfc6204bis is designed to cover at least a /64 assigned to a network interface. The WPD-2 clause in "large enough" is designed to be vague enough to cover the sub-delegated case if and only if the CE router supports prefix sub-delegation. Rfc6204bis can't do any better for text in these two bullets because rfc6204bis does not cover the specification for prefix sub-delegation in the home LAN - that is part of the homenet work.=20 =20 Hemant & Wes =20 From: Hemant Singh (shemant) [mailto:shemant@cisco.com]=20 Sent: zondag 18 maart 2012 15:27 To: Ray Hunter Cc: STARK, BARBARA H; v6ops@ietf.org; Wuyts Carl Subject: RE: [v6ops] RFC6204bis-07 =20 Ray, =20 Ok, I understand the extra important clarification New text in each bullet is highlighted in bold. =20 WPD-2: The IPv6 CE router MAY indicate as a hint to the delegating router the size of the prefix it requires. If so, it MUST ask for a prefix large enough to assign one /64 for each of its interfaces, rounded up to the nearest nibble, and SHOULD be configurable to ask for more. Best Current Practice for IPv6 Address Assignment to End Sites is provided in BCP 157 (RFC6177) [RFC6177]. =20 WPD-3: The IPv6 CE router MUST be prepared to accept a delegated prefix size different from what is given in the hint. If the delegated prefix is too small to address all of its interfaces, the IPv6 CE router assigns a /64 to each interface until a /64 is not available to assign to another interface. Then the IPv6 CE router SHOULD log a system management error. =20 Thanks and regards, =20 Hemant _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops =20 ------_=_NextPart_001_01CD0777.445DD5FC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Tim,

 

From: = v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of = Tim Chown
Sent: Tuesday, March 20, 2012 6:08 = PM
To: IPv6 Operations
Subject: Re: [v6ops] = RFC6204bis-07

 

 

>WPD-2 says "large enough for a = /64 per interface", but the homenet may also have internal routers. = While some routing >principles/requirements have been = documented, the routing protocol for homenet is >not yet determined; it may or may not = be aware of >the homenet = topology.

 

There is a difference = between a /64 assigned to a network interface and a delegated prefix = that may be shorter than that.   The text in rfc6204bis is = designed to cover at least a /64 assigned to a network interface. =  The WPD-2 clause in “large enough” is designed to be = vague enough to cover the sub-delegated case if and only if the CE = router supports prefix sub-delegation.  Rfc6204bis can’t do = any better for text in these two bullets because rfc6204bis does not = cover the specification for prefix sub-delegation in the home LAN = – that is part of the homenet work.

 

Hemant & Wes

 



From:=  Hemant = Singh (shemant) [mailto:shemant@cisco.com] 
Sent: zondag 18 maart 2012 = 15:27
To: Ray = Hunter
Cc: STARK, BARBARA H; v6ops@ietf.org; Wuyts = Carl
Subject: RE: [v6ops] = RFC6204bis-07

 

Ray,

 

Ok, I understand the extra important clarification  New text = in each bullet is highlighted in bold.

 

WPD-2:  The IPv6 CE router MAY indicate as a hint to the = delegating

        router the size of the = prefix it requires.  If so, it MUST

        ask for a prefix large = enough to assign one /64 for each of

        its interfaces, rounded = up to the nearest nibble, and SHOULD

        be configurable to ask = for more.  Best = Current Practice for

        IPv6 Address = Assignment to End Sites is provided in BCP 157

        (RFC6177) = [RFC6177].

 

WPD-3:  The IPv6 CE router MUST be prepared to accept a = delegated

        prefix size different = from what is given in the hint.  If the

        delegated prefix is too = small to address all of its interfaces,

        the IPv6 CE = router assigns a /64 = to each interface until a /64

        is not available = to assign to another interface.  Then the IPv6

        CE = router SHOULD log a system = management error.

 

Thanks and regards,

 

Hemant

_______________________________________________
v6op= s mailing list
v6ops@ietf.org
https://www.ietf.org= /mailman/listinfo/v6ops

 

------_=_NextPart_001_01CD0777.445DD5FC-- From ichiroumakino@gmail.com Wed Mar 21 12:16:56 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B05221E80A3 for ; Wed, 21 Mar 2012 12:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.269 X-Spam-Level: X-Spam-Status: No, score=-3.269 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 EpzbjzqSR9XA for ; Wed, 21 Mar 2012 12:16:55 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 51D0421E80B6 for ; Wed, 21 Mar 2012 12:16:55 -0700 (PDT) Received: by werb10 with SMTP id b10so1460687wer.31 for ; Wed, 21 Mar 2012 12:16:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=mIbCvnUZu7u5ZTFEKgyAY07J+eyztqQc4CXDB3W6yho=; b=vfSy9NYbv+IIdlywhtvLdFlYJ3OWLIL8aRMUugUfkHNMS7HFLK09eskbm7/dM2lLZy fzUJQXlu2CXfCcitY6aXCTbnvkpeyUQShvc1oodbw+q9xHa9iioEeCaWcQFHbWbX84nu 283cAIt1QHbd+0UUrMalh2zqcjHGXoGbZGkHbSif9MsX3AtTdVTc4FkmobbaytaSkYmK oY3FnKRRCFFq5YbbitbJ7rxIsDiJrNblRdPVsfXFX/TZhDkjvj8JwoDwhqO2EXlISFHp 61VjhKo1Czv85LDYWGzs8tbh4SUCvlRBa3V50ep2KPwDbQ6BCgkcll+ezelOJev2lFwg 6Yaw== Received: by 10.180.81.135 with SMTP id a7mr41025104wiy.16.1332357414501; Wed, 21 Mar 2012 12:16:54 -0700 (PDT) Received: from dhcp-10-61-97-204.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id k6sm6701338wie.9.2012.03.21.12.16.52 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Mar 2012 12:16:53 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: Date: Wed, 21 Mar 2012 20:16:49 +0100 Content-Transfer-Encoding: 7bit Message-Id: <2A026F04-9D43-4CD4-B98F-9C9222A41972@employees.org> References: To: Chris Grundemann X-Mailer: Apple Mail (2.1257) Cc: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" , Ronald Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 19:16:56 -0000 >>>> DHCPv6 PD does not use the M/O flags. neither should it, they are >>>> overloaded as it is. >>> >>> There is no IETF document that says DHCPv6 PD does not use the M flags. >>> I am not sold on the overloading just yet. M=0, O=0 in RFC 4861 >>> indicates no DHCPv6 services are available. >> >> more correctly there is no document that says PD uses the M flag. the M >> flag is the "Managed address configuration " flag. > > Yes, and the O flag is the "Other configuration" flag. PD is certainly > other DHCPv6 configuration information. In fact, RFC 4861 is quite clear > on this point, it states: "If neither M nor O flags are set, this > indicates that no information is available via DHCPv6." (emphasis on 'NO > information') no, and this was certainly not the spirit that 3633 was written in. can we please not discuss the M/O flags again? cheers, Ole From rajiva@cisco.com Wed Mar 21 14:26:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 899EA21E8087 for ; Wed, 21 Mar 2012 14:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.999 X-Spam-Level: X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 lWr99ARdqqrh for ; Wed, 21 Mar 2012 14:26:20 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id B9B5D21E8013 for ; Wed, 21 Mar 2012 14:26:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=2425; q=dns/txt; s=iport; t=1332365180; x=1333574780; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=kPHe8vk7jSwK+j0sNQoJL6nGMzBXpgy7aHFifvpwBdM=; b=TKV/FG6e6IU5Bd7h7lTk32RozHDGpnM6OREhLvYYe60svvCD/EBnr8yn hi9rmqddtjwQLKmr0/PXgWcW+0nOo2QfAHDz64lScb4wYAoq8zK6g0Iy6 ex7hgjIGs4o7xQm7yA3rPWYg6GSHsZeJtXz3nTeBof033yNeIFCTrBVpv Q=; X-IronPort-AV: E=Sophos;i="4.73,624,1325462400"; d="scan'208";a="68397428" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 21 Mar 2012 21:26:20 +0000 Received: from [64.102.202.59] (dhcp-64-102-202-59.cisco.com [64.102.202.59]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2LLQAcv013908; Wed, 21 Mar 2012 21:26:13 GMT User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Wed, 21 Mar 2012 17:26:08 -0400 From: Rajiv Asati To: Jen Linkova , "Michael Behringer (mbehring)" Message-ID: Thread-Topic: [v6ops] New Draft: Using Only Link-Local Address in Network Core In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 21:26:21 -0000 Jen, Thanks for the feedback. It is reasonable to say that troubleshooting/diagnostics tools (e.g. Ping, trace route, ftp, syslog=8A) would work just fine, if their source address is hardcoded to a particular GUA (instead of relying on automagical SAS). Good point on the caveat about RSVP-TE. That one, along with few more, should be there in the next revision. Wrt the last point, it is a common practice to dedicate a particular subnet for the loopbacks. So, a single policy wouldn't cut it in that case. Cheers Rajiv -----Original Message----- From: Jen Linkova Date: Tue, 20 Mar 2012 23:47:02 +1100 To: "Michael Behringer (mbehring)" Cc: Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core >Hi Michael, > >On Thu, Mar 8, 2012 at 8:56 PM, Michael Behringer (mbehring) > wrote: >> V6ops WG, >> Eric and myself published a new draft, which is in the context of v6ops. >> We'd like to solicit feedback. >> >> We feel there are substantial advantages to only using link-local >> addresses on core links, and propose this model as a "best common >> practice". However, there are some caveats. >> >> Our draft lists advantages and disadvantages to allow network operators >> to make a factual decision on whether this model fits their needs. > >The suggested design does look very elegant, it does work but I have a >few comments: >- as it has been mentioned before, troubleshooting/diagnostic tools >could get broken (unless we are 100% sure that address selection works >as expected which isn't a case currently :(( > >- one of caveats not mentioned in the doc: let's say I have two links >between two routers and I need to construct a *strict* ERO for an LSP >to control which link is used. > >Speaking of advantages: >"If a network only uses > loopback addresses for the routers, only those loopback addresses > need to be protected from outside the network." - if loopbacks are >addressed from the same block as core links, I don't believe using LLA >only would simplify your filters significantly. You'd probably have >the same policy for loopbacks as for core links anyway. > > >--- >SY, Jen Linkova aka Furry >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From hansliu@gmail.com Wed Mar 21 18:01:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA1721E8015 for ; Wed, 21 Mar 2012 18:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 sNizBlcPV+3t for ; Wed, 21 Mar 2012 18:01:23 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8397D21E800F for ; Wed, 21 Mar 2012 18:01:22 -0700 (PDT) Received: by lagj5 with SMTP id j5so1392699lag.31 for ; Wed, 21 Mar 2012 18:01:19 -0700 (PDT) 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:content-transfer-encoding; bh=uVsCYDVdGQqkvH7fhUldRl9j2edUcKv+1Uw+4jrlLkk=; b=td6yyj9GwdO0ct9jmYahFj2aexjrXDPWBD6z7uOd7iavEqja2AF7XF6MzR5XXxLCIU 5XoW9qOFQxKuZr/nfHbMA0bXXT91lzN1K9r8jsW/R5fLdIa570JFz76TTl3Rl7UV+2xo m2VWbZUOtDdPyqUJLw+8qzz57yurcJCibWfCWUIS3j7I4+cTJV6YU1KnKbLnSSXeo4ja yac5hp/qXKsJoqZFPyvF9yROpZHNtBRgo0eLjRP8ehZZOQAcLpiFEQcmcYDbkM1rIAKY xYgI7v8I7DobuH8nIuH9HTI3OH4ucywEs7/OEXkiHanPkk0I2I2TqEfJynr29QwoCOY/ h+ZQ== MIME-Version: 1.0 Received: by 10.152.112.68 with SMTP id io4mr4195162lab.40.1332378079308; Wed, 21 Mar 2012 18:01:19 -0700 (PDT) Received: by 10.112.5.34 with HTTP; Wed, 21 Mar 2012 18:01:19 -0700 (PDT) In-Reply-To: <2A026F04-9D43-4CD4-B98F-9C9222A41972@employees.org> References: <2A026F04-9D43-4CD4-B98F-9C9222A41972@employees.org> Date: Thu, 22 Mar 2012 09:01:19 +0800 Message-ID: From: Hans Liu To: =?UTF-8?Q?Ole_Tr=C3=B8an?= , v6ops@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Claire Cheng , Hans Liu Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 01:01:23 -0000 +1 If someone again asks me what is the challenge for CE vendors, I might tell them because we don't even have those most fundamental standard settled, such as M/O flags!? Sincerely, Hans On Thu, Mar 22, 2012 at 3:16 AM, Ole Tr=C3=B8an wrot= e: > > no, and this was certainly not the spirit that 3633 was written in. > can we please not discuss the M/O flags again? > > cheers, > Ole From sgundave@cisco.com Wed Mar 21 18:39:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6FC921E8011 for ; Wed, 21 Mar 2012 18:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.073 X-Spam-Level: X-Spam-Status: No, score=-8.073 tagged_above=-999 required=5 tests=[AWL=0.529, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, 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 K1EkJxIFGPDr for ; Wed, 21 Mar 2012 18:39:37 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id EB18E21E800C for ; Wed, 21 Mar 2012 18:39:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=5703; q=dns/txt; s=iport; t=1332380377; x=1333589977; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=NgDWJQioex6rLBwxZ3v82lWamifXM9RRauAYYlUU6qU=; b=LZIpPVv4eqO9dqyB/mSW7ym/KWfTnywfFILI6tys+3mcRTtXWFO50Cni XlQ0s39s9IpiTLMHBzcw7IDRmHp2YPt5+LMW4NLdodMvzyUnA0ywhrGIv 6GFsmyxIj+voNMX5cGIL72fMmRZmV1ReSyyMrefqlq0pfse1STX+hmnJI k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABmCak+rRDoH/2dsb2JhbAA5CoJPs1F6gQeCCQEBAQMBAQEBDwEqMRANAQgEYwYwAQEEARIUDodjBAELnz6XKgSJbGyGCgSIIzONCYsugxGBaIMH X-IronPort-AV: E=Sophos;i="4.73,626,1325462400"; d="scan'208,217";a="37066466" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 22 Mar 2012 01:39:36 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2M1dacQ000760; Thu, 22 Mar 2012 01:39:36 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 21 Mar 2012 18:39:36 -0700 Received: from 10.32.246.211 ([10.32.246.211]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Thu, 22 Mar 2012 01:39:35 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Wed, 21 Mar 2012 18:39:30 -0700 From: Sri Gundavelli To: Hui Deng , Message-ID: Thread-Topic: [v6ops] Comments on draft-gundavelli-v6ops-community-wifi-svcs-03 Thread-Index: Ac0HzJ/WhR/2gF+/REWfL3S+CCuhkw== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3415199972_32054783" X-OriginalArrivalTime: 22 Mar 2012 01:39:36.0559 (UTC) FILETIME=[A3BFC7F0:01CD07CC] Subject: Re: [v6ops] Comments on draft-gundavelli-v6ops-community-wifi-svcs-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 01:39:38 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3415199972_32054783 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Hui, Thanks for your comments. SP WIFI is one of the key focus areas for all mos= t every mobility operator. Wi-Fi Offload is the topic of interest, with significant vendor and operator interest in this space. Correct me, how man= y million hotspots you guys have deployed last year ? The spec tries to identify what it takes to enable that service, the protocol choice, mobilit= y considerations, IPv6 transitioning and other aspects. We are still working on additional updates, that should complete all the IPv6 considerations. > It is a good tutorial for people who start to work on wifi. would that b= e possible to describe each section related to IETF work such as mentioning capwap, EAP, pmip6/GTP,diameter et al. :) You missed the point, Hui. This is not a tutorial, come on. This is about enabling a service. > Recent wifi authentication=A0work mostly is based on portal, but guess futu= re would be based on EAP to have some disucssion on this would be helpful? It is true that 802.1x/EAP is the way to go, but as you are aware, not all terminals are 802.1x compliant and many operators are not willing to enforc= e this at this time. You/CMCC as an operator understands these challenges as well, so we may have to address the Web Auth issue and provided the recommendations. Regards Sri On 3/21/12 1:17 AM, "Hui Deng" wrote: > Hello authors, > =A0 > Thanks for writing this draft, I have several comments below: > 1) I searched the whole document, only 2,3 place have mentioned IPv6, > don't know whether it is related to v6ops, considering Intarea? > =A0 > 2) It is a good tutorial for people who start to work on wifi. would that= be > possible > to describe each section related to IETF work such as mentioning capwap, = EAP, > pmip6/GTP,diameter et al. > =A0 > 3) Recent wifi authentication=A0work mostly is based on portal, but guess f= uture > would be based on EAP > to have some disucssion on this would be helpful? > =A0 > Best, > =A0 > -Hui > =A0 > =A0 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --B_3415199972_32054783 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [v6ops] Comments on draft-gundavelli-v6ops-community-wifi-svcs-0= 3 Hi Hui,

Thanks for your comments. SP WIFI is one of the key focus areas for all mos= t every mobility operator. Wi-Fi Offload is the topic of interest, with sign= ificant vendor and operator interest in this space. Correct me, how many mil= lion hotspots you guys have deployed last year ? The spec tries to identify = what it takes to enable that service, the protocol choice, mobility consider= ations, IPv6 transitioning and other aspects. We are still working on additi= onal updates, that should complete all the IPv6 considerations.


>  It is a good tutorial for people who start to work on wifi. woul= d that be possible to describe each section related to IETF work such as men= tioning capwap, EAP, pmip6/GTP,diameter et al.
:)  You missed the point, Hui. This is not a tutorial, come on. This i= s about enabling a service.


> Recent wifi authentication=A0work mostly is based on portal, but guess f= uture would be based on EAP to have some disucssion on this would be helpful= ?

It is true that 802.1x/EAP is the way to go, but as you are aware, not all = terminals are 802.1x compliant and many operators are not willing to enforce= this at this time. You/CMCC as an operator understands these challenges as = well, so we may have to address the Web Auth issue and provided the recommen= dations.


Regards
Sri




On 3/21/12 1:17 AM, "Hui Deng" <= denghui02@gmail.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Hello authors,
=A0
Thanks for writing this draft, I have several comments below:
1) I searched the whole document, only 2,3 place have mentioned IPv6,
don't know whether it is related to v6ops, considering Intarea?
=A0
2) It is a good tutorial for people who start to work on wifi. would that b= e possible
to describe each section related to IETF work such as mentioning capwap, EA= P, pmip6/GTP,diameter et al.
=A0
3) Recent wifi authentication=A0work mostly is based on portal, but guess fut= ure would be based on EAP
to have some disucssion on this would be helpful?
=A0
Best,
=A0
-Hui
=A0
=A0

___________= ____________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/= mailman/listinfo/v6ops
--B_3415199972_32054783-- From denghui02@gmail.com Wed Mar 21 19:00:12 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B994C21E8039 for ; Wed, 21 Mar 2012 19:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.087 X-Spam-Level: X-Spam-Status: No, score=-103.087 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, 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 fOCCSaKc2r0a for ; Wed, 21 Mar 2012 19:00:11 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id B006421E800C for ; Wed, 21 Mar 2012 19:00:11 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1608517yhk.31 for ; Wed, 21 Mar 2012 19:00:11 -0700 (PDT) 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=SGxQySopNmqZ9D9suEQyuMqalMJh8RB6RR9iPew7T3Y=; b=rHB0spZYF4rojtL7La5BaQIUkY1Um3xWKj5k4O2pAuGrBSUo/k2c5wqirh/8ddVKVR BtWL3ONb/zZW7PmKGIPpomzVNWZxOWWB1WULXhhfJszuu73YBs/AKGMgbK8whVFlsmjU gPaR/XBCOxcKMWbkYVGrKWQ6LrlN0h+tcKv4Pp+D9q2qO6mIh99LbUwe5HPl+QL84Pwz 2HbwmDrNCOAAyfKkdzxMY2JeyJtOC4RwcpcXv4WVDBuzbFj5y4+KosHfRMxKFCzDmujw 4/XS8eJc4ACQ+iffQIatBOYVuYaviAI6sPTjBA3Tn1YwEANGF+TKwZ+iDIoVH2dyY86N Kglg== MIME-Version: 1.0 Received: by 10.236.138.110 with SMTP id z74mr6017396yhi.114.1332381611290; Wed, 21 Mar 2012 19:00:11 -0700 (PDT) Received: by 10.147.112.1 with HTTP; Wed, 21 Mar 2012 19:00:11 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 Mar 2012 10:00:11 +0800 Message-ID: From: Hui Deng To: Sri Gundavelli Content-Type: multipart/alternative; boundary=20cf303a3271a570a704bbcb44e0 Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments on draft-gundavelli-v6ops-community-wifi-svcs-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 02:00:12 -0000 --20cf303a3271a570a704bbcb44e0 Content-Type: text/plain; charset=ISO-8859-1 Hi Sri, Thanks for your reply. I would agree today SP WIFI offload become one of top issues discussed everywhere GSMA/WBA/WFA/3GPP/SMALL CELL.. we have deployed couple of million APs last year. agree your points that IETF could also help to enhance the such Internet access expansion especially taking on IPv6 consideration. Your work could be a good start for that direction. Let's have wifi network support IPv6. thanks for your contribution -Hui 2012/3/22 Sri Gundavelli > Hi Hui, > > Thanks for your comments. SP WIFI is one of the key focus areas for all > most every mobility operator. Wi-Fi Offload is the topic of interest, with > significant vendor and operator interest in this space. Correct me, how > many million hotspots you guys have deployed last year ? The spec tries to > identify what it takes to enable that service, the protocol choice, > mobility considerations, IPv6 transitioning and other aspects. We are still > working on additional updates, that should complete all the IPv6 > considerations. > > > > > It is a good tutorial for people who start to work on wifi. would that > be possible to describe each section related to IETF work such as > mentioning capwap, EAP, pmip6/GTP,diameter et al. > :) You missed the point, Hui. This is not a tutorial, come on. This is > about enabling a service. > > > > > Recent wifi authentication work mostly is based on portal, but guess > future would be based on EAP to have some disucssion on this would be > helpful? > > It is true that 802.1x/EAP is the way to go, but as you are aware, not all > terminals are 802.1x compliant and many operators are not willing to > enforce this at this time. You/CMCC as an operator understands these > challenges as well, so we may have to address the Web Auth issue and > provided the recommendations. > > > > Regards > Sri > > > > > On 3/21/12 1:17 AM, "Hui Deng" wrote: > > Hello authors, > > Thanks for writing this draft, I have several comments below: > 1) I searched the whole document, only 2,3 place have mentioned IPv6, > don't know whether it is related to v6ops, considering Intarea? > > 2) It is a good tutorial for people who start to work on wifi. would that > be possible > to describe each section related to IETF work such as mentioning capwap, > EAP, pmip6/GTP,diameter et al. > > 3) Recent wifi authentication work mostly is based on portal, but guess > future would be based on EAP > to have some disucssion on this would be helpful? > > Best, > > -Hui > > > > ------------------------------ > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > --20cf303a3271a570a704bbcb44e0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Sri,
=A0
Thanks for your reply.
I would agree today SP WIFI offload become one of top issues discussed= everywhere GSMA/WBA/WFA/3GPP/SMALL CELL.. we have deployed couple of milli= on APs last year. agree your points that IETF could also help to enhance th= e such Internet access expansion especially taking on IPv6 consideration. Y= our work could be a good start for that direction.
Let's have wifi network=A0support IPv6. thanks for your contributi= on
=A0
-Hui
=A0
=A0
2012/3/22 Sri Gundavelli <<= a href=3D"mailto:sgundave@cisco.com">sgundave@cisco.com>
Hi Hui,

Thanks for your comments. SP WIFI is one of the k= ey focus areas for all most every mobility operator. Wi-Fi Offload is the t= opic of interest, with significant vendor and operator interest in this spa= ce. Correct me, how many million hotspots you guys have deployed last year = ? The spec tries to identify what it takes to enable that service, the prot= ocol choice, mobility considerations, IPv6 transitioning and other aspects.= We are still working on additional updates, that should complete all the I= Pv6 considerations.=20



> =A0It is a good tutorial for people who = start to work on wifi. would that be possible to describe each section rela= ted to IETF work such as mentioning capwap, EAP, pmip6/GTP,diameter et al.<= br>
:) =A0You missed the point, Hui. This is not a tutorial, come on. Thi= s is about enabling a service.=20



> Recent wifi authentication=A0work mostly= is based on portal, but guess future would be based on EAP to have some di= sucssion on this would be helpful?

It is true that 802.1x/EAP = is the way to go, but as you are aware, not all terminals are 802.1x compli= ant and many operators are not willing to enforce this at this time. You/CM= CC as an operator understands these challenges as well, so we may have to a= ddress the Web Auth issue and provided the recommendations.=20



Regards
Sri




On 3/21/12 = 1:17 AM, "Hui Deng" <denghui02@gmail.com> wrote:
Hello authors,
=A0
Thanks for writing this draft, I= have several comments below:
1) I searched the whole document, only 2,3= place have mentioned IPv6,
don't know whether it is related to v6o= ps, considering Intarea?
=A0
2) It is a good tutorial for people who start to work on wifi. would= that be possible
to describe each section related to IETF work such as = mentioning capwap, EAP, pmip6/GTP,diameter et al.
=A0
3) Recent wifi = authentication=A0work mostly is based on portal, but guess future would be = based on EAP
to have some disucssion on this would be helpful?
=A0
Best,
=A0-Hui
=A0
=A0
_______________________________________________v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--20cf303a3271a570a704bbcb44e0-- From hiromi@inetcore.com Wed Mar 21 22:14:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3851221E8028 for ; Wed, 21 Mar 2012 22:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_35=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 BJpz6T8Ila2f for ; Wed, 21 Mar 2012 22:14:52 -0700 (PDT) Received: from inc.inetcore.com (inc.inetcore.com [IPv6:2403:2000:1:1::11]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECC921E8027 for ; Wed, 21 Mar 2012 22:14:51 -0700 (PDT) Received: from [IPv6:2403:2000:1:3:fcea:e7e2:7997:51e7] (unknown [IPv6:2403:2000:1:3:fcea:e7e2:7997:51e7]) by inc.inetcore.com (Postfix) with ESMTPSA id 3287131EA9C for ; Thu, 22 Mar 2012 14:14:49 +0900 (JST) Message-ID: <4F6AB545.50904@inetcore.com> Date: Thu, 22 Mar 2012 14:14:45 +0900 From: Ruri Hiromi Organization: INTEC Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: v6ops@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: [v6ops] Comments on draft-hazeyama-widecamp-ipv6-only-experience-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 05:14:53 -0000 Hi Gang and all, Thanks for your comment. As you mentioned in the previous mail, the failures are due to implementation or settings, not for protocol specification. So that we will modify its description to be more clear. Our additional comment in line; > 1. Some testing results have been shown in tables of section 4.2. > Wondering to known what reasons cause the data transmission failures > in the case of Frag. C => S on table 7. IIJ who gave us 4rd implementation is still inspecting their codes but the reason might comes from the MTU handling process. For your reference, IIJ said they follow RFC2473 Section 7.2 for the Path MTU function in 4rd. Consequently the correct answer for this goes "yes". We will make a correction at Frag. C => S in the 4rd/IPoE case on table 7 as follows. +-----------------+-------------------+------------------+ | Elements | 4RD/PPPoE (v4) | 4RD/IPoE (v4) | +-----------------+-------------------+------------------+ | NAT | Exist | Exist | | --------------- | ----------------- | ---------------- | | Mapping | Bad | Good | | --------------- | ----------------- | ---------------- | | Filtering | Good | Good | | --------------- | ----------------- | ---------------- | | RTT | 156 | 323 | | --------------- | ----------------- | ---------------- | | MTU size C => S | 1452 | 1452 | | --------------- | ----------------- | ---------------- | | Frag. C => S | NO | YES | | --------------- | ----------------- | ---------------- | | MTU size S => C | 1280 | 1452 | | --------------- | ----------------- | ---------------- | | Frag. S => C | YES | YES | +-----------------+-------------------+------------------+ > 2. I guess some statements on "dependency between IPv4 and IPv6 > address" should be clarified further. Thank you for the advice. We will modify it more appropriate expression. > 3. In table10, why is the hairpinning not supported? 4rd could do that > in hub&spoke mode between CE-CE communications. And 464XLAT adpoted > RFC 6146, which could support hairpinning as well. We think the lack of hairpinning support on the camp experiment might be from configuration matters. In the 4rd case, IIJ answered us that it was disabled in the configuration and we could not evaluate hairpining function with CE-CE communication at that time. In addition to that the 4rd configured as mesh model. The 464XLAT case was also caused by setting of PLAT. Anyway specification of 4rd and 464XLAT would be satisfied with hairpinning. We will try to give more information in detail in the draft. We appreciate further comments. Regards, (2012/03/14 18:04), GangChen wrote: > Hello authors, > > Generally, the draft provided informative testing data and pointed the > failures cases. I guess some failures are related to implementations; > some are due to protocol inconsistency. It's better to make categories > so it's beneficial for the group identifying the workaround. > > More detailed: > > 1. Some testing results have been shown in tables of section 4.2. > Wondering to known what reasons cause the data transmission failures > in the case of Frag. C => S on table 7. > > 2. I guess some statements on "dependency between IPv4 and IPv6 > address" should be clarified further. > > 3. In table10, why is the hairpinning not supported? 4rd could do that > in hub&spoke mode between CE-CE communications. And 464XLAT adpoted > RFC 6146, which could support hairpinning as well. > > BRs > > Gang > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops -- --------------- Ruri Hiromi INTEC Inc. From Tina.Tsou.Zouting@huawei.com Wed Mar 21 22:20:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC54821F854C for ; Wed, 21 Mar 2012 22:20:08 -0700 (PDT) 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=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_35=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 ViMpXamdj4KQ for ; Wed, 21 Mar 2012 22:20:07 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id B90A021E803F for ; Wed, 21 Mar 2012 22:20:07 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEH16310; Thu, 22 Mar 2012 01:20:07 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 21 Mar 2012 22:17:33 -0700 Received: from SZXEML431-HUB.china.huawei.com (10.72.61.39) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 21 Mar 2012 22:17:38 -0700 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.172]) by szxeml431-hub.china.huawei.com ([10.72.61.39]) with mapi id 14.01.0323.003; Thu, 22 Mar 2012 13:17:34 +0800 From: Tina TSOU To: Ruri Hiromi Thread-Topic: [v6ops] Comments on draft-hazeyama-widecamp-ipv6-only-experience-01 Thread-Index: AQHNB+rF1wAmA/2/60qQfgBpk01boZZ1xlgE Date: Thu, 22 Mar 2012 05:17:34 +0000 Message-ID: <1E94A024-31A2-4B74-9FE0-7A618F757940@huawei.com> References: , <4F6AB545.50904@inetcore.com> In-Reply-To: <4F6AB545.50904@inetcore.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Comments on draft-hazeyama-widecamp-ipv6-only-experience-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 05:20:09 -0000 Jari has a IPv6 only experience draft before. Sent from my iPad On Mar 21, 2012, at 10:15 PM, "Ruri Hiromi" wrote: > Hi Gang and all, >=20 > Thanks for your comment. >=20 > As you mentioned in the previous mail, the failures are due to > implementation or settings, not for protocol specification. So that we > will modify its description to be more clear. >=20 > Our additional comment in line; >=20 >> 1. Some testing results have been shown in tables of section 4.2. >> Wondering to known what reasons cause the data transmission failures >> in the case of Frag. C =3D> S on table 7. >=20 > IIJ who gave us 4rd implementation is still inspecting their codes but > the reason might comes from the MTU handling process. > For your reference, IIJ said they follow RFC2473 Section 7.2 for the > Path MTU function in 4rd. >=20 > Consequently the correct answer for this goes "yes". > We will make a correction at Frag. C =3D> S in the 4rd/IPoE case on table > 7 as follows. >=20 > +-----------------+-------------------+------------------+ > | Elements | 4RD/PPPoE (v4) | 4RD/IPoE (v4) | > +-----------------+-------------------+------------------+ > | NAT | Exist | Exist | > | --------------- | ----------------- | ---------------- | > | Mapping | Bad | Good | > | --------------- | ----------------- | ---------------- | > | Filtering | Good | Good | > | --------------- | ----------------- | ---------------- | > | RTT | 156 | 323 | > | --------------- | ----------------- | ---------------- | > | MTU size C =3D> S | 1452 | 1452 | > | --------------- | ----------------- | ---------------- | > | Frag. C =3D> S | NO | YES | > | --------------- | ----------------- | ---------------- | > | MTU size S =3D> C | 1280 | 1452 | > | --------------- | ----------------- | ---------------- | > | Frag. S =3D> C | YES | YES | > +-----------------+-------------------+------------------+ >=20 >=20 >> 2. I guess some statements on "dependency between IPv4 and IPv6 >> address" should be clarified further. >=20 > Thank you for the advice. We will modify it more appropriate expression. >=20 >> 3. In table10, why is the hairpinning not supported? 4rd could do that >> in hub&spoke mode between CE-CE communications. And 464XLAT adpoted >> RFC 6146, which could support hairpinning as well. >=20 > We think the lack of hairpinning support on the camp experiment might be > from configuration matters. >=20 > In the 4rd case, IIJ answered us that it was disabled in the > configuration and we could not evaluate hairpining function with CE-CE > communication at that time. In addition to that the 4rd configured as > mesh model. > The 464XLAT case was also caused by setting of PLAT. > Anyway specification of 4rd and 464XLAT would be satisfied with hairpinni= ng. >=20 > We will try to give more information in detail in the draft. >=20 > We appreciate further comments. > Regards, >=20 > (2012/03/14 18:04), GangChen wrote: >> Hello authors, >>=20 >> Generally, the draft provided informative testing data and pointed the >> failures cases. I guess some failures are related to implementations; >> some are due to protocol inconsistency. It's better to make categories >> so it's beneficial for the group identifying the workaround. >>=20 >> More detailed: >>=20 >> 1. Some testing results have been shown in tables of section 4.2. >> Wondering to known what reasons cause the data transmission failures >> in the case of Frag. C =3D> S on table 7. >>=20 >> 2. I guess some statements on "dependency between IPv4 and IPv6 >> address" should be clarified further. >>=20 >> 3. In table10, why is the hairpinning not supported? 4rd could do that >> in hub&spoke mode between CE-CE communications. And 464XLAT adpoted >> RFC 6146, which could support hairpinning as well. >>=20 >> BRs >>=20 >> Gang >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 > --=20 > --------------- > Ruri Hiromi > INTEC Inc. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From hiromi@inetcore.com Wed Mar 21 22:27:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B851C21F856C for ; Wed, 21 Mar 2012 22:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_35=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 1oze9sRXk3NL for ; Wed, 21 Mar 2012 22:27:34 -0700 (PDT) Received: from inc.inetcore.com (inc.inetcore.com [IPv6:2403:2000:1:1::11]) by ietfa.amsl.com (Postfix) with ESMTP id ED46921F856A for ; Wed, 21 Mar 2012 22:27:33 -0700 (PDT) Received: from [IPv6:2403:2000:1:3:fcea:e7e2:7997:51e7] (unknown [IPv6:2403:2000:1:3:fcea:e7e2:7997:51e7]) by inc.inetcore.com (Postfix) with ESMTPSA id 6AB4B31EC0D; Thu, 22 Mar 2012 14:27:33 +0900 (JST) Message-ID: <4F6AB841.3010307@inetcore.com> Date: Thu, 22 Mar 2012 14:27:29 +0900 From: Ruri Hiromi Organization: INTEC Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Tina TSOU References: <4F6AB545.50904@inetcore.com> <1E94A024-31A2-4B74-9FE0-7A618F757940@huawei.com> In-Reply-To: <1E94A024-31A2-4B74-9FE0-7A618F757940@huawei.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Comments on draft-hazeyama-widecamp-ipv6-only-experience-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 05:27:34 -0000 Hi Tina, Yes we know his draft and refer in our draft. In our draft we tried to use multiple techniques as "IPv6 only network". For example, we connected upstream networks using with PPPv6 tunnel and IPv6 over ethernet. We also use different types of IPv4 connection like 464XLAT,4rd,SA46T over the IPv6 only networks. We report the differences between them. Regards, (2012/03/22 14:17), Tina TSOU wrote: > Jari has a IPv6 only experience draft before. > > Sent from my iPad > > On Mar 21, 2012, at 10:15 PM, "Ruri Hiromi" wrote: > >> Hi Gang and all, >> >> Thanks for your comment. >> >> As you mentioned in the previous mail, the failures are due to >> implementation or settings, not for protocol specification. So that we >> will modify its description to be more clear. >> >> Our additional comment in line; >> >>> 1. Some testing results have been shown in tables of section 4.2. >>> Wondering to known what reasons cause the data transmission failures >>> in the case of Frag. C => S on table 7. >> >> IIJ who gave us 4rd implementation is still inspecting their codes but >> the reason might comes from the MTU handling process. >> For your reference, IIJ said they follow RFC2473 Section 7.2 for the >> Path MTU function in 4rd. >> >> Consequently the correct answer for this goes "yes". >> We will make a correction at Frag. C => S in the 4rd/IPoE case on table >> 7 as follows. >> >> +-----------------+-------------------+------------------+ >> | Elements | 4RD/PPPoE (v4) | 4RD/IPoE (v4) | >> +-----------------+-------------------+------------------+ >> | NAT | Exist | Exist | >> | --------------- | ----------------- | ---------------- | >> | Mapping | Bad | Good | >> | --------------- | ----------------- | ---------------- | >> | Filtering | Good | Good | >> | --------------- | ----------------- | ---------------- | >> | RTT | 156 | 323 | >> | --------------- | ----------------- | ---------------- | >> | MTU size C => S | 1452 | 1452 | >> | --------------- | ----------------- | ---------------- | >> | Frag. C => S | NO | YES | >> | --------------- | ----------------- | ---------------- | >> | MTU size S => C | 1280 | 1452 | >> | --------------- | ----------------- | ---------------- | >> | Frag. S => C | YES | YES | >> +-----------------+-------------------+------------------+ >> >> >>> 2. I guess some statements on "dependency between IPv4 and IPv6 >>> address" should be clarified further. >> >> Thank you for the advice. We will modify it more appropriate expression. >> >>> 3. In table10, why is the hairpinning not supported? 4rd could do that >>> in hub&spoke mode between CE-CE communications. And 464XLAT adpoted >>> RFC 6146, which could support hairpinning as well. >> >> We think the lack of hairpinning support on the camp experiment might be >> from configuration matters. >> >> In the 4rd case, IIJ answered us that it was disabled in the >> configuration and we could not evaluate hairpining function with CE-CE >> communication at that time. In addition to that the 4rd configured as >> mesh model. >> The 464XLAT case was also caused by setting of PLAT. >> Anyway specification of 4rd and 464XLAT would be satisfied with hairpinning. >> >> We will try to give more information in detail in the draft. >> >> We appreciate further comments. >> Regards, >> >> (2012/03/14 18:04), GangChen wrote: >>> Hello authors, >>> >>> Generally, the draft provided informative testing data and pointed the >>> failures cases. I guess some failures are related to implementations; >>> some are due to protocol inconsistency. It's better to make categories >>> so it's beneficial for the group identifying the workaround. >>> >>> More detailed: >>> >>> 1. Some testing results have been shown in tables of section 4.2. >>> Wondering to known what reasons cause the data transmission failures >>> in the case of Frag. C => S on table 7. >>> >>> 2. I guess some statements on "dependency between IPv4 and IPv6 >>> address" should be clarified further. >>> >>> 3. In table10, why is the hairpinning not supported? 4rd could do that >>> in hub&spoke mode between CE-CE communications. And 464XLAT adpoted >>> RFC 6146, which could support hairpinning as well. >>> >>> BRs >>> >>> Gang >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> >> >> -- >> --------------- >> Ruri Hiromi >> INTEC Inc. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops -- --------------- Ruri Hiromi INTEC Inc. From Tina.Tsou.Zouting@huawei.com Wed Mar 21 22:52:22 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA15221F85B4 for ; Wed, 21 Mar 2012 22:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_35=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 CRebzpASiTmD for ; Wed, 21 Mar 2012 22:52:22 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2F55B21F85A8 for ; Wed, 21 Mar 2012 22:52:22 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEP21291; Thu, 22 Mar 2012 01:52:21 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 21 Mar 2012 22:51:06 -0700 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 21 Mar 2012 22:51:04 -0700 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.172]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.003; Thu, 22 Mar 2012 13:50:59 +0800 From: Tina TSOU To: Ruri Hiromi Thread-Topic: [v6ops] Comments on draft-hazeyama-widecamp-ipv6-only-experience-01 Thread-Index: AQHNB+rF1wAmA/2/60qQfgBpk01boZZ1xlgE//98qICAAIytgQ== Date: Thu, 22 Mar 2012 05:50:59 +0000 Message-ID: <7A5DD910-69D3-4F99-81EA-CB5A6E3FED9B@huawei.com> References: <4F6AB545.50904@inetcore.com> <1E94A024-31A2-4B74-9FE0-7A618F757940@huawei.com>, <4F6AB841.3010307@inetcore.com> In-Reply-To: <4F6AB841.3010307@inetcore.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Comments on draft-hazeyama-widecamp-ipv6-only-experience-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 05:52:23 -0000 Sent from my iPad On Mar 21, 2012, at 10:27 PM, "Ruri Hiromi" wrote: > Hi Tina, >=20 > Yes we know his draft and refer in our draft. > In our draft we tried to use multiple techniques as "IPv6 only network". > For example, we connected upstream networks using with PPPv6 tunnel and > IPv6 over ethernet. We also use different types of IPv4 connection like > 464XLAT,4rd,SA46T over the IPv6 only networks. Can the title of the I-D reflect this point precisely? > We report the differences > between them. >=20 > Regards, >=20 > (2012/03/22 14:17), Tina TSOU wrote: >> Jari has a IPv6 only experience draft before. >>=20 >> Sent from my iPad >>=20 >> On Mar 21, 2012, at 10:15 PM, "Ruri Hiromi" wrote: >>=20 >>> Hi Gang and all, >>>=20 >>> Thanks for your comment. >>>=20 >>> As you mentioned in the previous mail, the failures are due to >>> implementation or settings, not for protocol specification. So that we >>> will modify its description to be more clear. >>>=20 >>> Our additional comment in line; >>>=20 >>>> 1. Some testing results have been shown in tables of section 4.2. >>>> Wondering to known what reasons cause the data transmission failures >>>> in the case of Frag. C =3D> S on table 7. >>>=20 >>> IIJ who gave us 4rd implementation is still inspecting their codes but >>> the reason might comes from the MTU handling process. >>> For your reference, IIJ said they follow RFC2473 Section 7.2 for the >>> Path MTU function in 4rd. >>>=20 >>> Consequently the correct answer for this goes "yes". >>> We will make a correction at Frag. C =3D> S in the 4rd/IPoE case on tab= le >>> 7 as follows. >>>=20 >>> +-----------------+-------------------+------------------+ >>> | Elements | 4RD/PPPoE (v4) | 4RD/IPoE (v4) | >>> +-----------------+-------------------+------------------+ >>> | NAT | Exist | Exist | >>> | --------------- | ----------------- | ---------------- | >>> | Mapping | Bad | Good | >>> | --------------- | ----------------- | ---------------- | >>> | Filtering | Good | Good | >>> | --------------- | ----------------- | ---------------- | >>> | RTT | 156 | 323 | >>> | --------------- | ----------------- | ---------------- | >>> | MTU size C =3D> S | 1452 | 1452 | >>> | --------------- | ----------------- | ---------------- | >>> | Frag. C =3D> S | NO | YES | >>> | --------------- | ----------------- | ---------------- | >>> | MTU size S =3D> C | 1280 | 1452 | >>> | --------------- | ----------------- | ---------------- | >>> | Frag. S =3D> C | YES | YES | >>> +-----------------+-------------------+------------------+ >>>=20 >>>=20 >>>> 2. I guess some statements on "dependency between IPv4 and IPv6 >>>> address" should be clarified further. >>>=20 >>> Thank you for the advice. We will modify it more appropriate expression= . >>>=20 >>>> 3. In table10, why is the hairpinning not supported? 4rd could do that >>>> in hub&spoke mode between CE-CE communications. And 464XLAT adpoted >>>> RFC 6146, which could support hairpinning as well. >>>=20 >>> We think the lack of hairpinning support on the camp experiment might b= e >>> from configuration matters. >>>=20 >>> In the 4rd case, IIJ answered us that it was disabled in the >>> configuration and we could not evaluate hairpining function with CE-CE >>> communication at that time. In addition to that the 4rd configured as >>> mesh model. >>> The 464XLAT case was also caused by setting of PLAT. >>> Anyway specification of 4rd and 464XLAT would be satisfied with hairpin= ning. >>>=20 >>> We will try to give more information in detail in the draft. >>>=20 >>> We appreciate further comments. >>> Regards, >>>=20 >>> (2012/03/14 18:04), GangChen wrote: >>>> Hello authors, >>>>=20 >>>> Generally, the draft provided informative testing data and pointed the >>>> failures cases. I guess some failures are related to implementations; >>>> some are due to protocol inconsistency. It's better to make categories >>>> so it's beneficial for the group identifying the workaround. >>>>=20 >>>> More detailed: >>>>=20 >>>> 1. Some testing results have been shown in tables of section 4.2. >>>> Wondering to known what reasons cause the data transmission failures >>>> in the case of Frag. C =3D> S on table 7. >>>>=20 >>>> 2. I guess some statements on "dependency between IPv4 and IPv6 >>>> address" should be clarified further. >>>>=20 >>>> 3. In table10, why is the hairpinning not supported? 4rd could do that >>>> in hub&spoke mode between CE-CE communications. And 464XLAT adpoted >>>> RFC 6146, which could support hairpinning as well. >>>>=20 >>>> BRs >>>>=20 >>>> Gang >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>>=20 >>>=20 >>> --=20 >>> --------------- >>> Ruri Hiromi >>> INTEC Inc. >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >=20 >=20 > --=20 > --------------- > Ruri Hiromi > INTEC Inc. From phdgang@gmail.com Thu Mar 22 00:01:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2654B21E802C for ; Thu, 22 Mar 2012 00:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.49 X-Spam-Level: X-Spam-Status: No, score=-3.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 tYowvOOkuoPv for ; Thu, 22 Mar 2012 00:01:41 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 62EFC21E8026 for ; Thu, 22 Mar 2012 00:01:41 -0700 (PDT) Received: by werb10 with SMTP id b10so1834735wer.31 for ; Thu, 22 Mar 2012 00:01:40 -0700 (PDT) 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=P84RVLCIq/UL8rQhOMWKbROGOUhMZtKr1vck8XYm+UM=; b=mctf09BDPGigZWxq8lbDPDUJytz6Q4EmxHKNzyi6bRpTczUFqPE4O5OWaWMnE88c8J FsbF4ySkKAng3PRmPPENHytnlDsphAXAoGzy7zrjEq7OySO60vlP37SrPhgW0LS3HMVh O8F2aeNQVYIXuQEaXZW1nLCJ/bWGb7nHbO/axoBddyMovtXAWahqvfhLlMNQQbeEmC3Y /JqScCv2x9AjaY5uZosclsmB8zVm3IJRYC+XzH4m8wCeF4cKbJaIYsLJ3gSvr/MgkLmO ZDp/B95r9gY1xwUoWH5aXXAEV0z/QGVK1RwTk+T5s0GLbMjqkyls4RPXwy2cIDVcGrAL gvNg== MIME-Version: 1.0 Received: by 10.216.137.97 with SMTP id x75mr4128277wei.25.1332399700534; Thu, 22 Mar 2012 00:01:40 -0700 (PDT) Received: by 10.180.7.105 with HTTP; Thu, 22 Mar 2012 00:01:40 -0700 (PDT) In-Reply-To: <4F6AB545.50904@inetcore.com> References: <4F6AB545.50904@inetcore.com> Date: Thu, 22 Mar 2012 15:01:40 +0800 Message-ID: From: GangChen To: Ruri Hiromi Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments on draft-hazeyama-widecamp-ipv6-only-experience-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 07:01:42 -0000 Hello Ruri, 2012/3/22, Ruri Hiromi : > Consequently the correct answer for this goes "yes". > We will make a correction at Frag. C => S in the 4rd/IPoE case on table > 7 as follows. > > +-----------------+-------------------+------------------+ > | Elements | 4RD/PPPoE (v4) | 4RD/IPoE (v4) | > +-----------------+-------------------+------------------+ > | NAT | Exist | Exist | > | --------------- | ----------------- | ---------------- | > | Mapping | Bad | Good | > | --------------- | ----------------- | ---------------- | > | Filtering | Good | Good | > | --------------- | ----------------- | ---------------- | > | RTT | 156 | 323 | > | --------------- | ----------------- | ---------------- | > | MTU size C => S | 1452 | 1452 | > | --------------- | ----------------- | ---------------- | > | Frag. C => S | NO | YES | ^^^^^^^ Still NO here? I guess that's a typo? > > >> 2. I guess some statements on "dependency between IPv4 and IPv6 >> address" should be clarified further. > > Thank you for the advice. We will modify it more appropriate expression. It would be good if you could give more details on the list. Many thanks Gang From joelja@bogus.com Thu Mar 22 00:04:55 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B3121F85DA for ; Thu, 22 Mar 2012 00:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.226 X-Spam-Level: X-Spam-Status: No, score=-102.226 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 HOirzd-q6X+s for ; Thu, 22 Mar 2012 00:04:54 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id C427821F85C6 for ; Thu, 22 Mar 2012 00:04:54 -0700 (PDT) Received: from Joels-MacBook-Pro.local (c-98-234-216-143.hsd1.ca.comcast.net [98.234.216.143]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q2M74pfe007470 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 22 Mar 2012 07:04:52 GMT (envelope-from joelja@bogus.com) Message-ID: <4F6ACF13.5080109@bogus.com> Date: Thu, 22 Mar 2012 00:04:51 -0700 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Thu, 22 Mar 2012 07:04:52 +0000 (UTC) Subject: [v6ops] Reminder, meeting schedule IETF 83, Monday 0900, Thursday 1520 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 07:04:55 -0000 The nice part about being up first is? Reminder, v6ops meetings first thing monday morning MONDAY, March 26, 2012 0900-1130 Morning Session I Room: Maillot IPv6 Operations WG The second meeting is: THURSDAY, March 29, 2012 1520-1720 Afternoon Session II Room: Maillot IPv6 Operations WG Tools agenda is here: http://tools.ietf.org/wg/v6ops/agenda?item=agenda-83-v6ops.html Along with the audio stream and the v6ops jabber room. if you are inclined to assist by taking notes or monitoring the jabber room, let us know. Thanks joel From Ted.Lemon@nominum.com Thu Mar 22 04:03:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3C9521F8699 for ; Thu, 22 Mar 2012 04:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.302 X-Spam-Level: X-Spam-Status: No, score=-106.302 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, 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 h8bR9ANnMoc8 for ; Thu, 22 Mar 2012 04:03:10 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 2A54B21F868A for ; Thu, 22 Mar 2012 04:03:10 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKT2sG7WGwN0WAoWackXv2VqdxedZRA0bq@postini.com; Thu, 22 Mar 2012 04:03:10 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id E09431B82C4 for ; Thu, 22 Mar 2012 04:03:08 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id CFB9D19005D; Thu, 22 Mar 2012 04:03:08 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 22 Mar 2012 04:03:09 -0700 From: Ted Lemon To: =?iso-8859-1?Q?Ole_Tr=F8an?= , Chris Grundemann Thread-Topic: [v6ops] draft-ietf-v6ops-6204bis WGLC Thread-Index: AQHM/XLS6xlU9RM8lUyZTUbHbPfvPJZiYOaAgA5rHwCAALhKgIAAepoAgAGXBACAAJa6AIABfCCAgACQegw= Date: Thu, 22 Mar 2012 11:03:08 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472B8748@mbx-01.win.nominum.com> References: , <2A026F04-9D43-4CD4-B98F-9C9222A41972@employees.org> In-Reply-To: <2A026F04-9D43-4CD4-B98F-9C9222A41972@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" , Ronald Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 11:03:11 -0000 > no, and this was certainly not the spirit that 3633 was written in. > can we please not discuss the M/O flags again? I think this is a good intention to have, but the fact is that how this all= works isn't clearly specified. If your response is correct, and I think = it's reasonable to say that it is, then it needs to be stated explicitly so= mewhere where people will see it. RFC3633 doesn't refer to the M and O bits at all, but does refer to RFC3315= for guidance on how to start. Consequently, the reader is left free to d= ecide which of several possible interpretations of how to behave with respe= ct to the M and O bits is correct. We have heard people give convincing a= rguments in favor of all three interpretations. I think that you, as an a= uthor of the original document, should be treated as fairly authoritative o= n this question, but the fact is that if we want to resolve this debate, th= e right thing to do is reissue RFC3633 with the addition of a clear stateme= nt to the effect that the M and O bits are not considered when doing prefix= delegation. It would be good to do this sooner rather than later. From ichiroumakino@gmail.com Thu Mar 22 04:31:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C0521F856C for ; Thu, 22 Mar 2012 04:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.269 X-Spam-Level: X-Spam-Status: No, score=-3.269 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 eoCw7XnwVdyP for ; Thu, 22 Mar 2012 04:31:44 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id B845621F8569 for ; Thu, 22 Mar 2012 04:31:43 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so880442wgb.13 for ; Thu, 22 Mar 2012 04:31:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ZedxwIWYYmsi9PrBYg2DA/QfrDLyYH2Ljwy5URWYCHk=; b=WJh8VufISYtNpfGJlWHQszA8SdoOELoFBHFixzZtoxsO3kVJhNwFoM57nn+Q1DhVFC j9gOgJxMEuBdwizCHzAhvvGxFedj8hhJjAaRMqtQPareuA4ghFwKuJk9yBbTds20L9ds 0HZAdiYiUlu63qnMuONlqW4Q7ukP0PiLBmagj2XAOBrb9CStzNFLCOyn89zDZ0cNc1PE RbWsY+JBGUiLVJzIO+Tkcxnnbq2CKkmyEzOJ+C6NuCrc2z3V9OjZ001/Mxs9/nTf48i5 lbhbsOEAG07LRhsCRTjh5Vkq5qjrH6L51B1w17gXsyeYaDTZ07/2WS5BjbVVA5KhBy1o 8k0A== Received: by 10.180.96.228 with SMTP id dv4mr4159727wib.14.1332415902863; Thu, 22 Mar 2012 04:31:42 -0700 (PDT) Received: from [10.147.13.169] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ff2sm7701419wib.9.2012.03.22.04.31.41 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 22 Mar 2012 04:31:42 -0700 (PDT) Sender: Ole Troan Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?Ole_Tr=F8an?= In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472B8748@mbx-01.win.nominum.com> Date: Thu, 22 Mar 2012 12:31:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <23E545D9-18FC-4310-AE32-946BCD10F4DE@employees.org> References: , <2A026F04-9D43-4CD4-B98F-9C9222A41972@employees.org> <8D23D4052ABE7A4490E77B1A012B6307472B8748@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1257) Cc: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" , Ronald Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 11:31:45 -0000 Ted, >> no, and this was certainly not the spirit that 3633 was written in. >> can we please not discuss the M/O flags again? >=20 > I think this is a good intention to have, but the fact is that how = this all works isn't clearly specified. If your response is correct, = and I think it's reasonable to say that it is, then it needs to be = stated explicitly somewhere where people will see it. >=20 > RFC3633 doesn't refer to the M and O bits at all, but does refer to = RFC3315 for guidance on how to start. Consequently, the reader is left = free to decide which of several possible interpretations of how to = behave with respect to the M and O bits is correct. We have heard = people give convincing arguments in favor of all three interpretations. = I think that you, as an author of the original document, should be = treated as fairly authoritative on this question, but the fact is that = if we want to resolve this debate, the right thing to do is reissue = RFC3633 with the addition of a clear statement to the effect that the M = and O bits are not considered when doing prefix delegation. >=20 > It would be good to do this sooner rather than later. RFC3633 specifies a protocol between two routers. it does say the = requesting router should behave like a DHCP client, but it specifically = does not say that the requesting router should behave like a host as = defined in RFC4861. the combination of 3315, 3633, 4861 creates no ambiguity in my view. = (4861 states that routers set the M/O bits when sending RAs, but do not = do anything with them). the problem comes when RFC6204 defines the WAN interface behaving both = as a RFC4861 host and router at the same time. which function is done in = which context? should 6204 be authoritative on that? given that this isn't a model = either of 4861/3315 or 3633 or written according to. cheers, Ole From ietf-ipr@ietf.org Thu Mar 22 04:37:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A6221F868C; Thu, 22 Mar 2012 04:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.346 X-Spam-Level: X-Spam-Status: No, score=-102.346 tagged_above=-999 required=5 tests=[AWL=0.253, 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 OdgHNDbZe+sc; Thu, 22 Mar 2012 04:37:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE5121F8675; Thu, 22 Mar 2012 04:37:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: mawatari@jpix.ad.jp, kawashimam@vx.jp.nec.com, cameron.byrne@t-mobile.com X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120322113729.19251.14284.idtracker@ietfa.amsl.com> Date: Thu, 22 Mar 2012 04:37:29 -0700 Cc: v6ops@ietf.org, fred.baker@cisco.com, dromasca@avaya.com, ipr-announce@ietf.org Subject: [v6ops] IPR Disclosure: China Mobile Communications Corporation's Statement about IPR related to draft-ietf-v6ops-464xlat-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 11:37:29 -0000 Dear Masataka Mawatari, Masanobu Kawashima, Cameron Byrne: An IPR disclosure that pertains to your Internet-Draft entitled "464XLAT: Combination of Stateful and Stateless Translation" (draft-ietf-v6ops-464xla= t) was submitted to the IETF Secretariat on 2012-03-22 and has been posted on = the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1730/). The title of the IPR disclosure is "China Mobile Communications Corporation's Statement about IPR related to d= raft- ietf-v6ops-464xlat-01.""); The IETF Secretariat From gert@space.net Thu Mar 22 04:39:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684DD21F8680 for ; Thu, 22 Mar 2012 04:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, SARE_STILLSINGLE=1.66] 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 4RiEiZGCox8I for ; Thu, 22 Mar 2012 04:39:44 -0700 (PDT) Received: from mobil.space.net (mobil.Space.Net [IPv6:2001:608:2:81::2]) by ietfa.amsl.com (Postfix) with ESMTP id D8A9221F8675 for ; Thu, 22 Mar 2012 04:39:43 -0700 (PDT) Received: from mobil.space.net (localhost [127.0.0.1]) by mobil.space.net (Postfix) with ESMTP id 9C254F8A52 for ; Thu, 22 Mar 2012 12:39:42 +0100 (CET) X-SpaceNet-Relay: true Received: from moebius3.space.net (moebius3.Space.Net [IPv6:2001:608:2:2::250]) by mobil.space.net (Postfix) with ESMTPS id 8A1ADF8A0B for ; Thu, 22 Mar 2012 12:39:42 +0100 (CET) Received: (qmail 21131 invoked by uid 1007); 22 Mar 2012 12:39:42 +0100 Date: Thu, 22 Mar 2012 12:39:42 +0100 From: Gert Doering To: Rajiv Asati Message-ID: <20120322113942.GY84425@Space.Net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-NCC-RegID: de.space X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.21 (2010-09-15) Cc: v6ops@ietf.org, "Michael Behringer \(mbehring\)" Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 11:39:44 -0000 Hi, On Wed, Mar 21, 2012 at 05:26:08PM -0400, Rajiv Asati wrote: > Wrt the last point, it is a common practice to dedicate a particular > subnet for the loopbacks. So, a single policy wouldn't cut it in that case. Dedicate a larger subnet (like, "a /48") for loopbacks + transit. Still single policy. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From tjc@ecs.soton.ac.uk Thu Mar 22 05:02:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 246FC21F8539 for ; Thu, 22 Mar 2012 05:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[AWL=-0.478, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, SARE_SUB_6CONS_WORD=0.356] 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 AYC+sWAsyiLg for ; Thu, 22 Mar 2012 05:02:57 -0700 (PDT) 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 228B321F861E for ; Thu, 22 Mar 2012 05:02:56 -0700 (PDT) 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 q2MC2pqP000522 for ; Thu, 22 Mar 2012 12:02:51 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q2MC2pqP000522 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1332417771; bh=nUjuutBqd2mz/Tlyhg1B4IOYxIc=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=xaVCpotngt1y0YrSTxKSR710DNe8heWJj9nFLvbs3zDTSAyt6EXVbt7QxSCaEUEeV i3y47s36OMis8TCDZz8i/Nb+2LAlYjvH+ZTBipZ0hnm4R/KQu5y0pIm7RUyrx66gy9 Zm2+h+u6B1xtVG/MkFJh0gj7mzAcPDeCMo+6/DdA= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP id o2LC2p0543749967gM ret-id none; Thu, 22 Mar 2012 12:02:51 +0000 Received: from tjc-vpn.ecs.soton.ac.uk (tjc-vpn.ecs.soton.ac.uk [152.78.236.241]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q2MC2mtj028828 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 22 Mar 2012 12:02:49 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Tim Chown In-Reply-To: <23E545D9-18FC-4310-AE32-946BCD10F4DE@employees.org> Date: Thu, 22 Mar 2012 12:02:52 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: , <2A026F04-9D43-4CD4-B98F-9C9222A41972@employees.org> <8D23D4052ABE7A4490E77B1A012B6307472B8748@mbx-01.win.nominum.com> <23E545D9-18FC-4310-AE32-946BCD10F4DE@employees.org> <3F052093-2E18-4DD6-8ED0-61E41F528F85@ecs.soton.ac.uk> To: IPv6 Operations X-Mailer: Apple Mail (2.1257) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o2LC2p054374996700; tid=o2LC2p0543749967gM; client=relay,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q2MC2pqP000522 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: [v6ops] draft-chkpvc-enterprise-incremental-ipv6-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 12:02:58 -0000 Hi, Due to a typo in the draft name, this draft didn't hit Fred's automated = WG tools, so the authors would like to raise the draft on the list now = with a view to securing a slot in Paris to discuss its value and = content. In Taipei there was a comment in the WG session that there is no = up-to-date v6ops guidance on enterprise networks, while other scenarios = do have such texts. So at the mic I invited people to join an effort to = put something together. There is a good breadth of experience across = the people who stepped forward, and the result is available as=20 = http://www.ietf.org/id/draft-chkpvc-enterprise-incremental-ipv6-00.txt Does the WG think the subject matter of this draft is one we should = pursue in the WG? If so, is the structure and content appropriate? We = need some positive feedback and comments in order for Fred to schedule = us time in Paris. We have had a couple of people contact us off-list offering to help = develop the content. But we'd like some feedback from the WG before = investing more time in doing so. The -00 text is somewhat "rough", but = we feel it could be polished into something quite useful for the = community. Tim From Ted.Lemon@nominum.com Thu Mar 22 05:13:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B81E21F8624 for ; Thu, 22 Mar 2012 05:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.302 X-Spam-Level: X-Spam-Status: No, score=-106.302 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, 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 vr7Xkay0uRTg for ; Thu, 22 Mar 2012 05:13:56 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6DAAE21F8604 for ; Thu, 22 Mar 2012 05:13:56 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKT2sXgzL3YZxZCBnvHvwWkklNaBDvzLdA@postini.com; Thu, 22 Mar 2012 05:13:56 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 75E271B811E for ; Thu, 22 Mar 2012 05:13:55 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 67C1C19005D; Thu, 22 Mar 2012 05:13:55 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 22 Mar 2012 05:13:49 -0700 From: Ted Lemon To: =?iso-8859-1?Q?Ole_Tr=F8an?= Thread-Topic: [v6ops] draft-ietf-v6ops-6204bis WGLC Thread-Index: AQHM/XLS6xlU9RM8lUyZTUbHbPfvPJZiYOaAgA5rHwCAALhKgIAAepoAgAGXBACAAJa6AIABfCCAgACQegyAAH/jgP//lR7k Date: Thu, 22 Mar 2012 12:13:49 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472B8912@mbx-01.win.nominum.com> References: , <2A026F04-9D43-4CD4-B98F-9C9222A41972@employees.org> <8D23D4052ABE7A4490E77B1A012B6307472B8748@mbx-01.win.nominum.com>, <23E545D9-18FC-4310-AE32-946BCD10F4DE@employees.org> In-Reply-To: <23E545D9-18FC-4310-AE32-946BCD10F4DE@employees.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" , Ronald Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 12:13:57 -0000 > the combination of 3315, 3633, 4861 creates no ambiguity in my view. (486= 1=20 > states that routers set the M/O bits when sending RAs, but do not do anyt= hing > with them). So what you are saying is that a person who is intimately familiar with all= relevant documents will always, through logical derivation, come to the co= nclusion that you say is correct. Even if this were true, it would be irr= elevant: what matters is the conclusion that someone who reads RFC33633 com= es to. And since we have seen IETF participants draw conclusions other th= an the one you say is correct, we have clear evidence that the current spec= ification is inadequate. > should 6204 be authoritative on that? given that this isn't a model eithe= r of 4861/3315 or 3633 or written according to. I don't think this is relevant. If you think the right thing is for the r= outer to ignore the M and O bits in the RA, then the document should say so= , and should not leave it up to the reader to decide, based on interpretat= ion of various related, particularly when those documents do not all agree. From gvandeve@cisco.com Thu Mar 22 05:48:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED0BD21F8671 for ; Thu, 22 Mar 2012 05:48:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.394 X-Spam-Level: X-Spam-Status: No, score=-9.394 tagged_above=-999 required=5 tests=[AWL=-1.055, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, SARE_STILLSINGLE=1.66] 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 P5h6UX30s06b for ; Thu, 22 Mar 2012 05:48:48 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 97B7A21F8650 for ; Thu, 22 Mar 2012 05:48:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=1294; q=dns/txt; s=iport; t=1332420528; x=1333630128; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=6zawyttahsTVqumQ5Ip7Mrh8asmLUEcwe3I+SZ09c/c=; b=JPr8MhDHSg5GduJrs18gY2nN+w0J/6STv+ECIm2dLYjl2IyKwBDT/jkT nm90zTsne27Ews53j+AsL0KfUGsPyeTaoimekzGTRSqLmToaJpTQ0cV+X CtGfCVEYj5njggSx5SreiwGdCC/RRG/TfOfnIKxdIOawh29I8rGhVRRLp 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHcea0+Q/khL/2dsb2JhbABEtzOBB4IJAQEBBAEBAQ8BHQo0CwwEAgEIEQQBAQEKBhcBBgEmHwkIAQEEARIIGodoC5kunxoEkAFjBKQfgWiCaA X-IronPort-AV: E=Sophos;i="4.73,630,1325462400"; d="scan'208";a="69089164" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 22 Mar 2012 12:48:47 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2MCmlhD001083; Thu, 22 Mar 2012 12:48:47 GMT Received: from xmb-ams-102.cisco.com ([144.254.74.77]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Mar 2012 13:48:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Mar 2012 13:48:46 +0100 Message-ID: <5C99EC8C99D9BB45AC51D20DC2AD2DC5072BBD7D@XMB-AMS-102.cisco.com> In-Reply-To: <20120322113942.GY84425@Space.Net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] New Draft: Using Only Link-Local Address in Network Core thread-index: Ac0IIIHE7XP7C/9PRbSsHAX7EK+WLAACXZdg References: <20120322113942.GY84425@Space.Net> From: "Gunter Van de Velde (gvandeve)" To: "Gert Doering" , "Rajiv Asati (rajiva)" X-OriginalArrivalTime: 22 Mar 2012 12:48:47.0490 (UTC) FILETIME=[1F91A620:01CD082A] Cc: v6ops@ietf.org, "Michael Behringer \(mbehring\)" Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 12:48:55 -0000 I Agree with Gert. The simplicity is into making sure that teh policy doesn't have to be changed every week for example, but only maybe once every 2 a 3 years... G/ -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Gert Doering Sent: donderdag 22 maart 2012 12:40 To: Rajiv Asati (rajiva) Cc: v6ops@ietf.org; Michael Behringer (mbehring) Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core Hi, On Wed, Mar 21, 2012 at 05:26:08PM -0400, Rajiv Asati wrote: > Wrt the last point, it is a common practice to dedicate a particular > subnet for the loopbacks. So, a single policy wouldn't cut it in that case. Dedicate a larger subnet (like, "a /48") for loopbacks + transit. =20 Still single policy. Gert Doering -- NetMaster --=20 have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From rajiva@cisco.com Thu Mar 22 06:46:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48B921F863D for ; Thu, 22 Mar 2012 06:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.469 X-Spam-Level: X-Spam-Status: No, score=-9.469 tagged_above=-999 required=5 tests=[AWL=-0.530, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_STILLSINGLE=1.66] 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 cplGOIgRM7P6 for ; Thu, 22 Mar 2012 06:46:47 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id E838E21F862A for ; Thu, 22 Mar 2012 06:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=1057; q=dns/txt; s=iport; t=1332424007; x=1333633607; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=Nv9jg0IO/qwBxSjOW4kJBDec6/ZJW19YdXSaDdH2WDQ=; b=Cs1Z4vzQ9K0Gh0rFAn/EbwnHUdRXd4mTzMGm0HDuiDie4DPzXOs/q+fn GVcp3CUQoab3h1D4SJ7BpHG3oLg7YnokwHC8amoNt5KoIsOGL+gMpeUeB g60yoImJTsNmulvrqYLEknJmeNi0bMUVEtgitVNMCOxK6Q9xbd08Y1qw0 8=; X-IronPort-AV: E=Sophos;i="4.73,630,1325462400"; d="scan'208";a="68351718" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 22 Mar 2012 13:46:46 +0000 Received: from [64.102.209.118] (dhcp-64-102-209-118.cisco.com [64.102.209.118]) by rcdn-core2-5.cisco.com (8.14.3/8.14.3) with ESMTP id q2MDkf2p031531; Thu, 22 Mar 2012 13:46:43 GMT User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Thu, 22 Mar 2012 09:46:40 -0400 From: Rajiv Asati To: Gert Doering Message-ID: Thread-Topic: [v6ops] New Draft: Using Only Link-Local Address in Network Core In-Reply-To: <20120322113942.GY84425@Space.Net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: v6ops@ietf.org, "Michael Behringer \(mbehring\)" Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 13:46:47 -0000 Yah, in that case, I agree. -----Original Message----- From: Gert Doering Date: Thu, 22 Mar 2012 12:39:42 +0100 To: Rajiv Asati Cc: Jen Linkova , "Michael Behringer (mbehring)" , Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core >Hi, > >On Wed, Mar 21, 2012 at 05:26:08PM -0400, Rajiv Asati wrote: >> Wrt the last point, it is a common practice to dedicate a particular >> subnet for the loopbacks. So, a single policy wouldn't cut it in that >>case. > >Dedicate a larger subnet (like, "a /48") for loopbacks + transit. > >Still single policy. > >Gert Doering > -- NetMaster >-- >have you enabled IPv6 on something today...? > >SpaceNet AG Vorstand: Sebastian v. Bomhard >Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. >Grundner-Culemann >D-80807 Muenchen HRB: 136055 (AG Muenchen) >Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 From volz@cisco.com Thu Mar 22 06:52:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD91E21F8619 for ; Thu, 22 Mar 2012 06:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.489 X-Spam-Level: X-Spam-Status: No, score=-9.489 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, 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 dDRgUW4jAyHq for ; Thu, 22 Mar 2012 06:52:45 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 05BF521F8419 for ; Thu, 22 Mar 2012 06:52:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=volz@cisco.com; l=1925; q=dns/txt; s=iport; t=1332424365; x=1333633965; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=RGpKQvDyIFo8PLO2UMfHh1KAKumOxF4wxSIk/+Lp49g=; b=dQAHxd4t6KNd1YN22Xw67Fi5mr0KkGmayhMVSySc9WedBjVamp6ViqTw go2PRCsQPemoy8scSgG2jRiYzgVqL2j+hpFh7CaZ4mq7XYrheqnTukbRT 4TOv1stfSZKVWDnaATHeoN+MlllK89ga04/TJvQcvEiFEPe2asqW2EvfJ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIota0+tJV2c/2dsb2JhbABEtzaBB4IJAQEBAwEBAQEPAR0+CwUHBAIBCBEEAQELBhcBBgEmHwkIAgQBEggah2MFC5lHnxoEkAFjBIgjM5tJgWiDBQ X-IronPort-AV: E=Sophos;i="4.73,630,1325462400"; d="scan'208";a="68565220" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-3.cisco.com with ESMTP; 22 Mar 2012 13:52:44 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id q2MDqiTC009033; Thu, 22 Mar 2012 13:52:44 GMT Received: from xmb-rcd-101.cisco.com ([72.163.62.143]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Mar 2012 08:52:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Mar 2012 08:52:43 -0500 Message-ID: In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472B8912@mbx-01.win.nominum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6204bis WGLC thread-index: AQHM/XLS6xlU9RM8lUyZTUbHbPfvPJZiYOaAgA5rHwCAALhKgIAAepoAgAGXBACAAJa6AIABfCCAgACQegyAAH/jgP//lR7kgAAb8/A= References: , <2A026F04-9D43-4CD4-B98F-9C9222A41972@employees.org><8D23D4052ABE7A4490E77B1A012B6307472B8748@mbx-01.win.nominum.com>, <23E545D9-18FC-4310-AE32-946BCD10F4DE@employees.org> <8D23D4052ABE7A4490E77B1A012B6307472B8912@mbx-01.win.nominum.com> From: "Bernie Volz (volz)" To: "Ted Lemon" , =?iso-8859-1?Q?Ole_Tr=F8an?= X-OriginalArrivalTime: 22 Mar 2012 13:52:44.0138 (UTC) FILETIME=[0E63ACA0:01CD0833] Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ronald Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 13:52:45 -0000 Perhaps for now an errata for 3633 stating that the M&O bits are not = used for Prefix Delegation would be best? This does also tie into the open issues for IA_NA/IA_PD for the CPE = router ... does it wait for the RA before initiating DHCPv6 or should it = do the IA_PD Solicit "immediately" (with an IA_NA if the RA was received = with the M bit set).=20 - Bernie -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Ted Lemon Sent: Thursday, March 22, 2012 8:14 AM To: Ole Tr=F8an Cc: v6ops@ietf.org; v6ops-chairs@tools.ietf.org; Ronald Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC > the combination of 3315, 3633, 4861 creates no ambiguity in my view.=20 > (4861 states that routers set the M/O bits when sending RAs, but do=20 > not do anything with them). So what you are saying is that a person who is intimately familiar with = all relevant documents will always, through logical derivation, come to = the conclusion that you say is correct. Even if this were true, it = would be irrelevant: what matters is the conclusion that someone who = reads RFC33633 comes to. And since we have seen IETF participants draw = conclusions other than the one you say is correct, we have clear = evidence that the current specification is inadequate. > should 6204 be authoritative on that? given that this isn't a model = either of 4861/3315 or 3633 or written according to. I don't think this is relevant. If you think the right thing is for = the router to ignore the M and O bits in the RA, then the document = should say so, and should not leave it up to the reader to decide, based = on interpretation of various related, particularly when those documents = do not all agree. _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From Ted.Lemon@nominum.com Thu Mar 22 06:58:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4DA221F8597 for ; Thu, 22 Mar 2012 06:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.302 X-Spam-Level: X-Spam-Status: No, score=-106.302 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, 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 NDMK-pjFw6dr for ; Thu, 22 Mar 2012 06:58:41 -0700 (PDT) Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id 397E821F869A for ; Thu, 22 Mar 2012 06:58:36 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKT2swC8U/JowLTw+woF5OvqfMm7skao+m@postini.com; Thu, 22 Mar 2012 06:58:36 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0B6741B82B4 for ; Thu, 22 Mar 2012 06:58:35 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id E5D4919005D; Thu, 22 Mar 2012 06:58:34 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Thu, 22 Mar 2012 06:58:34 -0700 From: Ted Lemon To: "Bernie Volz (volz)" , =?iso-8859-1?Q?Ole_Tr=F8an?= Thread-Topic: [v6ops] draft-ietf-v6ops-6204bis WGLC Thread-Index: AQHM/XLS6xlU9RM8lUyZTUbHbPfvPJZiYOaAgA5rHwCAALhKgIAAepoAgAGXBACAAJa6AIABfCCAgACQegyAAH/jgP//lR7kgAAb8/CAAAG+cw== Date: Thu, 22 Mar 2012 13:58:34 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472B8996@mbx-01.win.nominum.com> References: , <2A026F04-9D43-4CD4-B98F-9C9222A41972@employees.org><8D23D4052ABE7A4490E77B1A012B6307472B8748@mbx-01.win.nominum.com>, <23E545D9-18FC-4310-AE32-946BCD10F4DE@employees.org> <8D23D4052ABE7A4490E77B1A012B6307472B8912@mbx-01.win.nominum.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "v6ops@ietf.org" , Ronald Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 13:58:43 -0000 > Perhaps for now an errata for 3633 stating that the M&O bits are not used= for Prefix Delegation would be best? This may be all anyone has the energy to do, but errata are a very limited = mechanism for addressing problems of this sort. Most implementors aren't = aware enough to read them, so their primary purpose is for standards activi= ty--either standards referring to them, or as a record to use when doing a = future update of the standard with the error. It's still fairly early day= s, so clarifying these documents now by reissuing them, rather than writing= errata, will be fairly effective. The longer we wait, the less effective= it will be.= From rajiva@cisco.com Thu Mar 22 07:25:26 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3692E21F8624 for ; Thu, 22 Mar 2012 07:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.324 X-Spam-Level: X-Spam-Status: No, score=-9.324 tagged_above=-999 required=5 tests=[AWL=-0.421, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, 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 0386CranRE5U for ; Thu, 22 Mar 2012 07:25:25 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id ADBC721F85DD for ; Thu, 22 Mar 2012 07:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=1124; q=dns/txt; s=iport; t=1332426325; x=1333635925; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=+4SvXYTZ/mPvnE+WFjwLBPMQ9ZQK1I8Ri6NWHSSEM0Q=; b=aJfL5T4xDJ8V7V7jEGhPhT+esY25bYw1WKrMmHwUj/1RkFVJadiLqtIw TLoKSEhovyiDe5X+Gl+lGV9xG/A8S9e9eOPLeH7lHlr9iGqpcdUzD04gx aqIi1PNu2wOo02g/M5PCVYEsoAbtko7Jjt8T2h6v6VjZQJWnpgGRcceEu c=; X-IronPort-AV: E=Sophos;i="4.73,630,1325462400"; d="scan'208";a="68563460" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 22 Mar 2012 14:25:23 +0000 Received: from [64.102.209.118] (dhcp-64-102-209-118.cisco.com [64.102.209.118]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q2MEPMH4022052; Thu, 22 Mar 2012 14:25:23 GMT User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Thu, 22 Mar 2012 10:25:20 -0400 From: Rajiv Asati To: Ted Lemon , "Bernie Volz (volz)" , Ole =?ISO-8859-1?B?VHL4YW4=?= Message-ID: Thread-Topic: [v6ops] draft-ietf-v6ops-6204bis WGLC In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472B8996@mbx-01.win.nominum.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: "v6ops@ietf.org" , Ronald Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 14:25:26 -0000 +1 -----Original Message----- From: Ted Lemon Date: Thu, 22 Mar 2012 13:58:34 +0000 To: "Bernie Volz (volz)" , Ole Tr=F8an Cc: "v6ops@ietf.org" , Ronald Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC >> Perhaps for now an errata for 3633 stating that the M&O bits are not >>used for Prefix Delegation would be best? > >This may be all anyone has the energy to do, but errata are a very >limited mechanism for addressing problems of this sort. Most >implementors aren't aware enough to read them, so their primary purpose >is for standards activity--either standards referring to them, or as a >record to use when doing a future update of the standard with the error. > It's still fairly early days, so clarifying these documents now by >reissuing them, rather than writing errata, will be fairly effective. >The longer we wait, the less effective it will be. >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From cgrundemann@gmail.com Thu Mar 22 07:36:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7A021F85F6 for ; Thu, 22 Mar 2012 07:36:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[AWL=-0.487, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, 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 Is115c7t6e1U for ; Thu, 22 Mar 2012 07:36:36 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 71BD721F85D6 for ; Thu, 22 Mar 2012 07:36:36 -0700 (PDT) Received: by yenm5 with SMTP id m5so1998904yen.31 for ; Thu, 22 Mar 2012 07:36:36 -0700 (PDT) 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:content-transfer-encoding; bh=co8Fv+0q/MRy8M5DGyjRn5/qteVlmwOVguO35Xwf054=; b=o7sZnYrpFcr26QWZJt6a2laprlo/9Nnw1Ai7VOFmlp/Z1a+dkoC8eMtI2OJzT6HuOE sy91sG0axNYqHJnx8LVSOaKujdJzbEZ+7oJ2MhV+446llX6r2vDE7TZASIzt902Z4wzs rsEE7WpIkuH8IfvFYRQszZ1ecQ1bPl42daHNiIK7Zd8PNu0Ovjszn7BH4RGaa66L+krl uQ6sZ0xmxjTWyI6J8IorJnLrsKP/r/3tmjmXYXqrG/PYMKIptFzv6HQJhUKZH4Lzt9bi 1vzflieqGXg3fVcfvT4Zeyom2RMNeNz6BCioYzDieMglyyZCMZ5HrQJkAd9mr9yzI+Uw it+g== MIME-Version: 1.0 Received: by 10.68.238.3 with SMTP id vg3mr20806795pbc.140.1332426995704; Thu, 22 Mar 2012 07:36:35 -0700 (PDT) Received: by 10.68.40.166 with HTTP; Thu, 22 Mar 2012 07:36:35 -0700 (PDT) In-Reply-To: <23E545D9-18FC-4310-AE32-946BCD10F4DE@employees.org> References: <2A026F04-9D43-4CD4-B98F-9C9222A41972@employees.org> <8D23D4052ABE7A4490E77B1A012B6307472B8748@mbx-01.win.nominum.com> <23E545D9-18FC-4310-AE32-946BCD10F4DE@employees.org> Date: Thu, 22 Mar 2012 08:36:35 -0600 Message-ID: From: Chris Grundemann To: =?ISO-8859-1?Q?Ole_Tr=F8an?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "v6ops@ietf.org" , "v6ops-chairs@tools.ietf.org" , Ronald Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 14:36:37 -0000 Ole, On Thu, Mar 22, 2012 at 05:31, Ole Tr=F8an wrote: > RFC3633 specifies a protocol between two routers. it does say the request= ing router should behave like a DHCP client, but it specifically does not s= ay that the requesting router should behave like a host as defined in RFC48= 61. It also does not say that it should not behave in that way. > the combination of 3315, 3633, 4861 creates no ambiguity in my view. (486= 1 states that routers set the M/O bits when sending RAs, but do not do anyt= hing with them). > > the problem comes when RFC6204 defines the WAN interface behaving both as= a RFC4861 host and router at the same time. which function is done in whic= h context? It appears clear that client/host functions are primarily WAN facing and server/router functions are primarily LAN facing, this facilitates predictable behavior in ISP networks where customers may connect either customer edge routers or hosts to the service provider network. > should 6204 be authoritative on that? given that this isn't a model eithe= r of 4861/3315 or 3633 or written according to. Yes. In several cases 6204/6204bis provides more specific requirements than the standards it points to. Understanding that 3633 was not written to specifically address customer edge routers, we are now adding a needed requirement which does not contradict any previously documented requirements. > cheers, > Ole Cheers, ~Chris > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --=20 @ChrisGrundemann http://chrisgrundemann.com From sarikaya2012@gmail.com Thu Mar 22 08:51:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4704321F8647 for ; Thu, 22 Mar 2012 08:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.565 X-Spam-Level: X-Spam-Status: No, score=-3.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 UcRzplbwVwDY for ; Thu, 22 Mar 2012 08:51:09 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1F82B21F863C for ; Thu, 22 Mar 2012 08:51:06 -0700 (PDT) Received: by eaaq11 with SMTP id q11so748283eaa.31 for ; Thu, 22 Mar 2012 08:51:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=t0MscIpjTRObbYkaAt4lJel/L+b9ftRNk9s+NfSDlPg=; b=M135ZJg9gkrxDyUB9LxQdbxvcZYAU3PgoEgTpx7JjqPtQk/1POLLf6Y0pJsXwJyE9E ZUHNXMAYf9OoR6bSynN/Xmwv6LYIJHwSYH7tR7gsm/aN0yGLhO4GGiOdWv1lQd33TXj6 hbBzFb/42e/Jn0nzTd+iX8VeJw2z98ESv21MNFM2M3Ot9TP13KplN0gc7pM//fe4JXbe GDW9+nZyjrW8URLZT4gVf71lo95QcndIa4w5JKDgoMjUeNG3hj3iGgzXHGyAMGTG3U6S OhWTdMgIM7YCUUqWtGaABisVX9zukk/Df2dEtSqZNljC1pxgRkxwN02d41in9t9MZgoq nBfA== MIME-Version: 1.0 Received: by 10.50.222.131 with SMTP id qm3mr2185578igc.66.1332431465521; Thu, 22 Mar 2012 08:51:05 -0700 (PDT) Received: by 10.231.179.71 with HTTP; Thu, 22 Mar 2012 08:51:05 -0700 (PDT) In-Reply-To: References: Date: Thu, 22 Mar 2012 10:51:05 -0500 Message-ID: From: Behcet Sarikaya To: Sri Gundavelli Content-Type: text/plain; charset=ISO-8859-1 Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments on draft-gundavelli-v6ops-community-wifi-svcs-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 15:51:10 -0000 On Wed, Mar 21, 2012 at 8:39 PM, Sri Gundavelli wrote: > Hi Hui, > > Thanks for your comments. SP WIFI is one of the key focus areas for all most > every mobility operator. Wi-Fi Offload is the topic of interest, with > significant vendor and operator interest in this space. Wi-Fi ofload is FMC (fixed mobile convergence). Profiting the occasion, I invite everybody to FMC side meeting on Tuesday at 19:30, the room is TBA. > Correct me, how many > million hotspots you guys have deployed last year ? The spec tries to > identify what it takes to enable that service, the protocol choice, mobility > considerations, IPv6 transitioning and other aspects. We are still working > on additional updates, that should complete all the IPv6 considerations. > Yes, part of FMC. Regards, Behcet From shemant@cisco.com Thu Mar 22 08:54:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26E621F85CC for ; Thu, 22 Mar 2012 08:54:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.077 X-Spam-Level: X-Spam-Status: No, score=-10.077 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 e8uAL1CqwZ9x for ; Thu, 22 Mar 2012 08:54:19 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2A14E21F85AF for ; Thu, 22 Mar 2012 08:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=7339; q=dns/txt; s=iport; t=1332431659; x=1333641259; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=mD4KbUHvjmxPrAySt8fxleMr7hHPulzGFzmKSSxfvg4=; b=F5Bei8AkSdiAtUA9Sr+sBJKcBRq7Ul2eTfyUr9SqFoV1lGtWZLQEtXdA zmAirwm0eb9rpD0+xamG5mpztU7Yet1dqTiR36YdmiYSVDIW/YpJYuC7J ROuqdHrmjvt6AgtnlCf2pCNd4P7epk2WFzmrtrrwEHCk7kVl0V5Q/G1H5 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAPJKa0+tJXG8/2dsb2JhbABEgka0doEHggkBAQEEEgEJEQNJDAQCAQgRBAEBCwYXAQYBRQkIAQEEARIIGodomU2fKJABYwSIIzObSYFogwU X-IronPort-AV: E=Sophos;i="4.73,630,1325462400"; d="scan'208,217";a="68572744" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 22 Mar 2012 15:54:14 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2MFsDxv011809; Thu, 22 Mar 2012 15:54:13 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Mar 2012 10:54:13 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD0844.07032730" Date: Thu, 22 Mar 2012 10:54:12 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30444AC83@XMB-RCD-109.cisco.com> In-Reply-To: <23E545D9-18FC-4310-AE32-946BCD10F4DE@employees.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6204bis WGLC Thread-Index: Ac0IH2HsmoKRs9BJQeeOkVU1kash0QAI0VrA References: , <2A026F04-9D43-4CD4-B98F-9C9222A41972@employees.org><8D23D4052ABE7A4490E77B1A012B6307472B8748@mbx-01.win.nominum.com> <23E545D9-18FC-4310-AE32-946BCD10F4DE@employees.org> From: "Hemant Singh (shemant)" To: =?iso-8859-1?Q?Ole_Tr=F8an?= , "Ted Lemon" X-OriginalArrivalTime: 22 Mar 2012 15:54:13.0880 (UTC) FILETIME=[076A0780:01CD0844] Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ronald Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 15:54:21 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD0844.07032730 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf = Of Ole Tr=F8an Sent: Thursday, March 22, 2012 7:32 AM To: Ted Lemon Cc: v6ops@ietf.org; v6ops-chairs@tools.ietf.org; Ronald Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC =20 >RFC3633 specifies a protocol between two routers. it does say the = requesting router should behave like a DHCP client, but it specifically = does not say that the >requesting router should behave like a host as = defined in RFC4861. =20 I already said once to the mailer that the protocol between two routers = for RFC 3633 uses DHCPv6 and the requesting router uses a DHCPv6 client. = Likewise the delegating router uses a DHCPv6 server. I have also said, = that the router RA provides the default router to the requesting router = - the reason is because DHCPv6 does not support default router = information provision. Neither should DHCPv6 because we still could not = resolve what if DHCPv6 and IPv6 ND RA both provide the default router = and there is a conflict? Who wins? =20 >the combination of 3315, 3633, 4861 creates no ambiguity in my view. = (4861 states that routers set the M/O bits when sending RAs, but do not = do anything with >them). =20 Not quite. I am not debating the M or the O bit which is a decade-long = rat-hole. It's the case when both the bits are zero is what I am = focusing the discussion on. When M and O bits are both zero, then IPv6 = nodes should follow RFC4861 that says, "indicates no dhcpv6 services are = available". Thus only for the case of M and O being zero, the CE router = MUST not initiate DHCPv6.=20 =20 Please hold off any Errata to RFC 3633 or any new document. Thus =20 Hemant ------_=_NextPart_001_01CD0844.07032730 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

 

-----Original Message-----
From: v6ops-bounces@ietf.org = [mailto:v6ops-bounces@ietf.org] On Behalf Of Ole Tr=F8an
Sent: = Thursday, March 22, 2012 7:32 AM
To: Ted Lemon
Cc: v6ops@ietf.org; = v6ops-chairs@tools.ietf.org; Ronald Bonica
Subject: Re: [v6ops] = draft-ietf-v6ops-6204bis WGLC

 

>RFC3633 specifies a protocol = between two routers. it does say the requesting router should behave = like a DHCP client, but it specifically does not say that the = >requesting router should behave like a host as defined in = RFC4861.

 

I already said once to the mailer that the protocol = between two routers for RFC 3633 uses DHCPv6 and the requesting router = uses a DHCPv6 client.=A0 Likewise the delegating router uses a DHCPv6 = server.=A0 I have also said, that the router RA provides the default = router to the requesting router – the reason is because DHCPv6 = does not support default router information provision.=A0 Neither should = DHCPv6 because we still could not resolve what if DHCPv6 and IPv6 ND RA = both provide the default router and there is a conflict?=A0 Who = wins?

 

>the = combination of 3315, 3633, 4861 creates no ambiguity in my view. (4861 = states that routers set the M/O bits when sending RAs, but do not do = anything with >them).

 

Not quite.=A0 I am not = debating the M or the O bit which is a decade-long rat-hole.=A0 It's the = case when both the bits are zero is what I am focusing the discussion = on.=A0 When M and O bits are both zero, then IPv6 nodes should follow = RFC4861 that says, "indicates no dhcpv6 services are = available".=A0 Thus only for the case of M and O being zero, the CE = router MUST not initiate DHCPv6.

 

Please hold off any Errata to RFC 3633 or any new = document.=A0 Thus

 

Hemant

------_=_NextPart_001_01CD0844.07032730-- From brian.e.carpenter@gmail.com Thu Mar 22 20:18:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDC2321E8017 for ; Thu, 22 Mar 2012 20:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.501 X-Spam-Level: X-Spam-Status: No, score=-103.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 26SOO435QvH5 for ; Thu, 22 Mar 2012 20:18:57 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3044121E8013 for ; Thu, 22 Mar 2012 20:18:57 -0700 (PDT) Received: by eaaq11 with SMTP id q11so872491eaa.31 for ; Thu, 22 Mar 2012 20:18:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=ZkzHgGM2eqeNA3xf9Rut29FCyxORPGU71gjAcMhAR/w=; b=frc+X8geAhBWtLqKgNIGH+v43D2sTyBDfKUYT3Sly+J2zTSNWdlzSdZtf/7CTq+k6Z sONTjzp4Rl7OZ9LHwWo53UYtlhFfDoKKD1Ew6fNYrn5Ni87BnPZ+iOktnv1/1fkqAEp5 MwODuNkKNCIFYPcDSYfHta4lo0w9SvwByvmG6sJMd+9TNb1h3y1cjQ64tW4xZm4Jf8ch MtwNeaRYu+a+vXo7ZDQzSVhbk2WeLxTmhZ3eRECYqsg41I8a1JfEGQWSDC2gmYXBziSr L2yRMUSkTchVRcuZOO4DikI0zjiuzXJwNKdp0MgLVkJgii43HE5xDY6UHGGdyVC11qT/ ej8g== Received: by 10.14.99.6 with SMTP id w6mr1494031eef.68.1332472736417; Thu, 22 Mar 2012 20:18:56 -0700 (PDT) Received: from [10.1.1.4] ([121.98.251.219]) by mx.google.com with ESMTPS id e56sm23422038eea.11.2012.03.22.20.18.52 (version=SSLv3 cipher=OTHER); Thu, 22 Mar 2012 20:18:55 -0700 (PDT) Message-ID: <4F6BEB95.60608@gmail.com> Date: Fri, 23 Mar 2012 16:18:45 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: IPv6 Operations Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [v6ops] draft-liu-v6ops-ula-usage-analysis-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 03:18:58 -0000 Hi, I think this draft is a considerable improvement on the -00 version. It still needs some work on the English, but I think the main points are covered now and the work should continue. However, there is clearly a complication, which is that this document needs to be aligned with whatever consensus appears in homenet about ULAs, and with whatever consensus appears in 6man about RFC3484bis. In particular, homenet is hitting the problem of what happens when multiple ULA prefixes show up automatically in the same network. That may not be recommended practice, but it seems very likely to happen, and raises routing and address-selection questions. I think the various WG Chairs need to agree how the discussion should be managed, because it might get complicated with three WGs involved (or four, if you count 6renum). Regards Brian From Tina.Tsou.Zouting@huawei.com Thu Mar 22 20:19:08 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2372B21E8045 for ; Thu, 22 Mar 2012 20:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.229 X-Spam-Level: X-Spam-Status: No, score=-1.229 tagged_above=-999 required=5 tests=[AWL=-0.890, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, SARE_STILLSINGLE=1.66] 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 6zgkoUmN7fPU for ; Thu, 22 Mar 2012 20:19:07 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC7721E8042 for ; Thu, 22 Mar 2012 20:19:07 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEP91075; Thu, 22 Mar 2012 23:19:07 -0400 (EDT) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 22 Mar 2012 20:15:19 -0700 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 22 Mar 2012 20:15:25 -0700 Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.172]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.003; Fri, 23 Mar 2012 11:15:22 +0800 From: Tina TSOU To: Rajiv Asati Thread-Topic: [v6ops] New Draft: Using Only Link-Local Address in Network Core Thread-Index: AQHNBpeUOttUlngqr0CMhcHW3EqGbpZ0vyoAgADuewCAACN6AIAAz6KA Date: Fri, 23 Mar 2012 03:15:21 +0000 Message-ID: <47D40373-530E-433F-9A0F-51E299088A45@huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <494D74224C5C2D4AAEB87CEC632470F9@huawei.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "v6ops@ietf.org" , "Michael Behringer \(mbehring\)" Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 03:19:08 -0000 Link-Local Address can not be used in CE router or even lower position of e= nterprise service? Sent from my iPad On Mar 22, 2012, at 6:47 AM, "Rajiv Asati" wrote: > Yah, in that case, I agree. >=20 >=20 > -----Original Message----- > From: Gert Doering > Date: Thu, 22 Mar 2012 12:39:42 +0100 > To: Rajiv Asati > Cc: Jen Linkova , "Michael Behringer (mbehring)" > , > Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network > Core >=20 >> Hi, >>=20 >> On Wed, Mar 21, 2012 at 05:26:08PM -0400, Rajiv Asati wrote: >>> Wrt the last point, it is a common practice to dedicate a particular >>> subnet for the loopbacks. So, a single policy wouldn't cut it in that >>> case. >>=20 >> Dedicate a larger subnet (like, "a /48") for loopbacks + transit. >>=20 >> Still single policy. >>=20 >> Gert Doering >> -- NetMaster >> --=20 >> have you enabled IPv6 on something today...? >>=20 >> SpaceNet AG Vorstand: Sebastian v. Bomhard >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. >> Grundner-Culemann >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Thu Mar 22 20:38:30 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C3CE21E8017 for ; Thu, 22 Mar 2012 20:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.475 X-Spam-Level: X-Spam-Status: No, score=-110.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 3nnJXWWrSbPo for ; Thu, 22 Mar 2012 20:38:29 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8E99221E8013 for ; Thu, 22 Mar 2012 20:38:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1118; q=dns/txt; s=iport; t=1332473909; x=1333683509; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=TTvGqjQ+XiDCK0eLn5RkpVisczpfvV8T2C/6ca0kTfw=; b=iMvUceRkmVBt9oVWNhlnMy4pUHZ5djV4uwtbuSEDLPegkOYSmlLL8lVQ 0QypjEAoDFTtmeT+j6/GmKp9dxG6RQL3wOiu4/CGzSOnRNSp091ZTNCfc rYuylMv60vrenSSo36SHSUsDXpLl9x26FJ+6Tb0zn+apTeZe1FRVbPmLq Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJDva0+Q/khN/2dsb2JhbABEt0qBB4IJAQEBAwESASc/BQsLNRFXBjWHYwWZEJ8QkCBjBJVfhW2IU4FogmiBUxc X-IronPort-AV: E=Sophos;i="4.73,633,1325462400"; d="scan'208";a="133126410" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 23 Mar 2012 03:38:28 +0000 Received: from Freds-Computer.local (dhcp-10-55-81-71.cisco.com [10.55.81.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2N3cRBX016771; Fri, 23 Mar 2012 03:38:27 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Fri, 23 Mar 2012 04:38:28 +0100 X-PGP-Universal: processed; by Freds-Computer.local on Fri, 23 Mar 2012 04:38:28 +0100 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <4F6BEB95.60608@gmail.com> Date: Fri, 23 Mar 2012 04:37:54 +0100 Message-Id: <1891004D-1190-4FE0-9E25-B4FE2A770DE8@cisco.com> References: <4F6BEB95.60608@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 03:38:30 -0000 On Mar 23, 2012, at 4:18 AM, Brian E Carpenter wrote: > In particular, homenet is hitting the problem of what happens when = multiple ULA prefixes show up automatically in the same network. That = may not be recommended practice, but it seems very likely to happen, and = raises routing and address-selection questions. Personally, I think that having each router generate a /48 ULA prefix = and use it without a conversation with its neighboring routers is a = pretty silly concept, and what is happening in homenet is the obvious = outcome of that. The problem is indeed tractable. A ULA generated in = that way has one of two purposes: it is supposed to be the prefix from = which all of the routers in a domain derive their prefixes, or it is a = temporary use that will not survive the reason that it was created = (probably to configure a residential router, which will then be = configured with an address from upstream using DHCP-PD). Making one for = a temporary purpose and keeping it forever in every router in the home = just isn't very smart - for exactly the reasons you point to.= From shemant@cisco.com Thu Mar 22 20:55:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D062221E8045 for ; Thu, 22 Mar 2012 20:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.081 X-Spam-Level: X-Spam-Status: No, score=-10.081 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 4h86Vx6Us7bO for ; Thu, 22 Mar 2012 20:55:31 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id ED0F221E8042 for ; Thu, 22 Mar 2012 20:55:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=8485; q=dns/txt; s=iport; t=1332474931; x=1333684531; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=TCQQy09Fif/9o0FbKZvWtAtqvlEOBMTtWr2/YCIlnnw=; b=Qmy1PMuYITGUSitZLo/Xct0h8v2tEnWdvKNugin0aAj6IKZtfZlX4eLm V4VjoH1cOl/kb5YgxmMEBGKV8VlI+odpuzjT6O3vfgozCQ2QpsTSMDsAn l5wv+xqTPJzsS5SSO2ZWW6YMAVxicxcOAWaUwrOx623zFeAV+T7FvD+Gf A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAFAKfya0+tJXG//2dsb2JhbABEgkasFAGIcIEHggkBAQEEEgEJEQNJDAQCAQgOAwQBAQsGFwEGAUUJCAEBBAESCBqHaAuYf58QkCBjBIgjM5tJgWiDBQ X-IronPort-AV: E=Sophos;i="4.73,633,1325462400"; d="scan'208,217";a="68767619" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-6.cisco.com with ESMTP; 23 Mar 2012 03:55:30 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2N3tU71024934; Fri, 23 Mar 2012 03:55:30 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 22 Mar 2012 22:55:30 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD08A8.C9C26D30" Date: Thu, 22 Mar 2012 22:55:11 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30444AF35@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6204bis WGLC Thread-Index: Ac0G2RxKlB6clMQXR960EG0tX6YgZABzOttA References: <702415E0-2849-4AB9-BA8E-BD312A7EE8EE@employees.org> From: "Hemant Singh (shemant)" To: "Chris Grundemann" , =?iso-8859-1?Q?Ole_Tr=F8an?= X-OriginalArrivalTime: 23 Mar 2012 03:55:30.0047 (UTC) FILETIME=[CA0510F0:01CD08A8] Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ronald Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 03:55:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD08A8.C9C26D30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Chris, =20 -----Original Message----- From: Chris Grundemann [mailto:C.Grundemann@cablelabs.com]=20 Sent: Tuesday, March 20, 2012 4:36 PM To: Ole Tr=F8an; Hemant Singh (shemant) Cc: v6ops@ietf.org; v6ops-chairs@tools.ietf.org; Ronald Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC =20 =20 >Yes, and the O flag is the "Other configuration" flag. PD is certainly >other DHCPv6 configuration information. In fact, RFC 4861 is quite = clear >on this point, it states: "If neither M nor O flags are set, this >indicates that no information is available via DHCPv6." (emphasis on = 'NO >information') =20 Not quite. The O flag is to obtain information using stateless DHCPv6 - = see http://tools.ietf.org/rfc/rfc3736.txt. PD acquisition is a stateful DHCPv6 procedure or RFC 3633 has to also = clarify if PD acquisition is supported via both stateful and stateless = DHCPv6. We have discussed such a clarification with Ralph Droms and Ole = in the past - don't remember the outcome. Further, a DHCPv6 client = includes the IA_NA and the IA_PD option in the DHCPv6 SOLICIT. IA_NA = IA_Address acquisition is a stateful DHCPv6 operation and now if PD = acquisition is a stateless operation, what if the DHCPv6 server the = SOLICIT is going to is only stateless (and if rfc3633 supports stateless = dhcpv6 operation?). The IA_NA is not obtained from such a server. I = hope it's clear now the kind of DHCPv6 client and server issues one has. = In the kind of network I develop products for, I so do prefer that = 120,000 DHCPv6 clients on my router relay agent do issue SOLICIT with = both IA_NA and the IA_PD so that I save upstream bandwidth or alleviate = congestion. The DHCPv6 server in our deployment also better support = stateful and stateless services in one server. =20 =20 I keep hearing of new corner cases in the DHC WG related to DHCPv6 = server for the PD being separate from the server that allocates IA_NA's. = It's fine to work out such corner cases, but a gentle reminder that the = broadband networks, IMHO, need consolidated options in a DHCPv6 SOLICIT. =20 Hemant ------_=_NextPart_001_01CD08A8.C9C26D30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Chris,

 

-----Original Message-----
From: = Chris Grundemann [mailto:C.Grundemann@cablelabs.com]
Sent: Tuesday, = March 20, 2012 4:36 PM
To: Ole Tr=F8an; Hemant Singh (shemant)
Cc: = v6ops@ietf.org; v6ops-chairs@tools.ietf.org; Ronald Bonica
Subject: = Re: [v6ops] draft-ietf-v6ops-6204bis WGLC

 

 

>Yes, = and the O flag is the "Other configuration" flag. PD is = certainly

>other DHCPv6 configuration = information. In fact, RFC 4861 is quite clear

>on = this point, it states: "If neither M nor O flags are set, = this

>indicates that no information is = available via DHCPv6." (emphasis on 'NO

>information')

 

Not quite.  The O = flag is to obtain information using stateless DHCPv6 – see http://tools.ietf.org/rfc/= rfc3736.txt.

PD acquisition is a = stateful DHCPv6 procedure or RFC 3633 has to also clarify if PD = acquisition is supported via both stateful and stateless DHCPv6.  = We have discussed such a clarification with Ralph Droms and Ole in = the past – don’t remember the outcome.  Further, a = DHCPv6 client includes the IA_NA and the IA_PD option in the DHCPv6 = SOLICIT.  IA_NA IA_Address acquisition is a stateful DHCPv6 = operation and now if PD acquisition is a stateless operation, what if = the DHCPv6 server the SOLICIT is going to is only stateless (and if = rfc3633 supports stateless dhcpv6 operation?). The IA_NA is not obtained = from such a server.   I hope it’s clear now the kind of = DHCPv6 client and server issues one has.  In the kind of network I = develop products for, I so do prefer that 120,000 DHCPv6 clients on my = router relay agent do issue SOLICIT with both IA_NA and the IA_PD so = that I save upstream bandwidth or alleviate congestion.  The DHCPv6 = server in our deployment also better support stateful and stateless = services in one server. 

 

I keep hearing of new corner cases in the DHC WG = related to DHCPv6 server for the PD being separate from the server that = allocates IA_NA’s.  It’s fine to work out such corner = cases, but a gentle reminder that the broadband networks, IMHO, need = consolidated options in a DHCPv6 SOLICIT.

 

Hemant

------_=_NextPart_001_01CD08A8.C9C26D30-- From leo.liubing@huawei.com Thu Mar 22 22:34:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6BE21F8469; Thu, 22 Mar 2012 22:34:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.246 X-Spam-Level: X-Spam-Status: No, score=-0.246 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753] 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 OfIR8Qw9lA09; Thu, 22 Mar 2012 22:34:01 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id B9DA521F8468; Thu, 22 Mar 2012 22:34:01 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEP96741; Fri, 23 Mar 2012 01:34:01 -0400 (EDT) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 22 Mar 2012 22:31:02 -0700 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 22 Mar 2012 22:31:09 -0700 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 23 Mar 2012 13:31:03 +0800 From: "Liubing (Leo)" To: Brian E Carpenter , IPv6 Operations Thread-Topic: [v6ops] draft-liu-v6ops-ula-usage-analysis-02 Thread-Index: AQHNCKO8Z4KSGk/lHk+mkdEjskALJpZ3UmnA Date: Fri, 23 Mar 2012 05:31:02 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F4524A26650@szxeml509-mbs> References: <4F6BEB95.60608@gmail.com> In-Reply-To: <4F6BEB95.60608@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.84] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "homenet@ietf.org" , "6man@ietf.org" <6man@ietf.org> Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 05:34:02 -0000 SGksIEJyaWFuDQoNClRoZXJlIGNvbWVzIGNvbW1lbnRzIGZpbmFsbHkgOi0pIFRoYW5rcyBmb3Ig eW91ciBjb25jZXJuIGFib3V0IHRoZSBkcmFmdC4gIA0KDQpJJ3ZlIG5vdGljZWQgdGhlIGRpc2N1 c3Npb24gaW4gNm1hbiBhbmQgaG9tZW5ldCwgd2hpY2ggaXMgbW9yZSBpbi1kZXB0aCB0ZWNobmlj YWwgaXNzdWUgd2hpbGUgdGhlIFVMQSB1c2FnZSBkcmFmdCBpcyBtb3JlIGdlbmVyYWwgdXNlIGNh c2VzLiBCdXQgSSB0aGluayBpdCBpcyBleGFjdGx5IHZhbHVhYmxlIGlucHV0IGFuZCBjb25zaWRl cmF0aW9uIHRvIHRoZSBVTEEgZHJhZnQgZm9yIHRoZSBmdXJ0aGVyIHN0ZXAuICANCg0KSSBhbSBh bHNvIGNvbmZ1c2VkIGFib3V0IHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgZGlzY3Vzc2lv biBpbiB2YXJpb3VzIFdHcyBhbmQgdGhlIFVMQSBkcmFmdC4NCldlIHNob3VsZCBjb3ZlciBhbGwg dGhlIHNwZWNpZmljIGlzc3VlcyBpbiB0aGUgZHJhZnQsIG9yIGp1c3QgbGltaXQgdGhlIGRpc2N1 c3Npb24gd2l0aGluIGVhY2ggV0cgd2hpbGUgdGhlIGRyYWZ0IG9ubHkgZm9jdXMgb24gZ2VuZXJh bCB1c2UgY2FzZXOjvw0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog djZvcHMtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnY2b3BzLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZg0KPiBCcmlhbiBFIENhcnBlbnRlcg0KPiBTZW50OiBGcmlkYXksIE1hcmNoIDIz LCAyMDEyIDExOjE5IEFNDQo+IFRvOiBJUHY2IE9wZXJhdGlvbnMNCj4gU3ViamVjdDogW3Y2b3Bz XSBkcmFmdC1saXUtdjZvcHMtdWxhLXVzYWdlLWFuYWx5c2lzLTAyDQo+IA0KPiBIaSwNCj4gDQo+ IEkgdGhpbmsgdGhpcyBkcmFmdCBpcyBhIGNvbnNpZGVyYWJsZSBpbXByb3ZlbWVudCBvbiB0aGUg LTAwIHZlcnNpb24uDQo+IEl0IHN0aWxsIG5lZWRzIHNvbWUgd29yayBvbiB0aGUgRW5nbGlzaCwg YnV0IEkgdGhpbmsgdGhlIG1haW4gcG9pbnRzDQo+IGFyZSBjb3ZlcmVkIG5vdyBhbmQgdGhlIHdv cmsgc2hvdWxkIGNvbnRpbnVlLg0KPiANCj4gSG93ZXZlciwgdGhlcmUgaXMgY2xlYXJseSBhIGNv bXBsaWNhdGlvbiwgd2hpY2ggaXMgdGhhdCB0aGlzIGRvY3VtZW50DQo+IG5lZWRzIHRvIGJlIGFs aWduZWQgd2l0aCB3aGF0ZXZlciBjb25zZW5zdXMgYXBwZWFycyBpbiBob21lbmV0IGFib3V0DQo+ IFVMQXMsIGFuZCB3aXRoIHdoYXRldmVyIGNvbnNlbnN1cyBhcHBlYXJzIGluIDZtYW4gYWJvdXQg UkZDMzQ4NGJpcy4NCj4gDQo+IEluIHBhcnRpY3VsYXIsIGhvbWVuZXQgaXMgaGl0dGluZyB0aGUg cHJvYmxlbSBvZiB3aGF0IGhhcHBlbnMgd2hlbg0KPiBtdWx0aXBsZSBVTEEgcHJlZml4ZXMgc2hv dyB1cCBhdXRvbWF0aWNhbGx5IGluIHRoZSBzYW1lIG5ldHdvcmsuIFRoYXQNCj4gbWF5IG5vdCBi ZSByZWNvbW1lbmRlZCBwcmFjdGljZSwgYnV0IGl0IHNlZW1zIHZlcnkgbGlrZWx5IHRvIGhhcHBl biwNCj4gYW5kIHJhaXNlcyByb3V0aW5nIGFuZCBhZGRyZXNzLXNlbGVjdGlvbiBxdWVzdGlvbnMu DQo+IA0KPiBJIHRoaW5rIHRoZSB2YXJpb3VzIFdHIENoYWlycyBuZWVkIHRvIGFncmVlIGhvdyB0 aGUgZGlzY3Vzc2lvbiBzaG91bGQNCj4gYmUgbWFuYWdlZCwgYmVjYXVzZSBpdCBtaWdodCBnZXQg Y29tcGxpY2F0ZWQgd2l0aCB0aHJlZSBXR3MgaW52b2x2ZWQNCj4gKG9yIGZvdXIsIGlmIHlvdSBj b3VudCA2cmVudW0pLg0KPiANCj4gUmVnYXJkcw0KPiAgICBCcmlhbg0KPiANCj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gdjZvcHMgbWFpbGluZyBs aXN0DQo+IHY2b3BzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdjZvcHMNCg== From leo.liubing@huawei.com Thu Mar 22 22:54:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6344421F8462 for ; Thu, 22 Mar 2012 22:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.123 X-Spam-Level: X-Spam-Status: No, score=-1.123 tagged_above=-999 required=5 tests=[AWL=0.877, BAYES_00=-2.599, J_CHICKENPOX_13=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 s5odPLwqXJEX for ; Thu, 22 Mar 2012 22:54:28 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1D321F849B for ; Thu, 22 Mar 2012 22:54:24 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEH93151; Fri, 23 Mar 2012 01:54:24 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 22 Mar 2012 22:52:08 -0700 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 22 Mar 2012 22:51:45 -0700 Received: from SZXEML509-MBS.china.huawei.com ([10.82.67.53]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0323.003; Fri, 23 Mar 2012 13:52:03 +0800 From: "Liubing (Leo)" To: Fred Baker , Brian E Carpenter Thread-Topic: [v6ops] draft-liu-v6ops-ula-usage-analysis-02 Thread-Index: AQHNCKO8Z4KSGk/lHk+mkdEjskALJpZ2tUUAgACo/VA= Date: Fri, 23 Mar 2012 05:52:02 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F4524A26670@szxeml509-mbs> References: <4F6BEB95.60608@gmail.com> <1891004D-1190-4FE0-9E25-B4FE2A770DE8@cisco.com> In-Reply-To: <1891004D-1190-4FE0-9E25-B4FE2A770DE8@cisco.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.4.84] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: IPv6 Operations Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 05:54:29 -0000 Hi, Fred Inline. > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Fred Baker > Sent: Friday, March 23, 2012 11:38 AM > To: Brian E Carpenter > Cc: IPv6 Operations > Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis-02 >=20 >=20 > On Mar 23, 2012, at 4:18 AM, Brian E Carpenter wrote: >=20 > > In particular, homenet is hitting the problem of what happens when mult= iple > ULA prefixes show up automatically in the same network. That may not be > recommended practice, but it seems very likely to happen, and raises rout= ing > and address-selection questions. >=20 > Personally, I think that having each router generate a /48 ULA prefix and= use it > without a conversation with its neighboring routers is a pretty silly con= cept, > and what is happening in homenet is the obvious outcome of that.=20 [Bing] I'm a little confused about the assumption "without a conversation",= aren't there some drafts in homenet WG to address the routing issue? Pardo= n me for my unfamiliar with the homenet discussions.=20 > The problem is indeed tractable. A ULA generated in that way has one of t= wo purposes: it is > supposed to be the prefix from which all of the routers in a domain deriv= e their > prefixes, or it is a temporary use that will not survive the reason that = it was > created (probably to configure a residential router, which will then be > configured with an address from upstream using DHCP-PD). Making one for a > temporary purpose and keeping it forever in every router in the home just= isn't > very smart - for exactly the reasons you point to. [Bing] I just read Anders Brandt's thread in homenet WG, "[homenet] Routing= between hosts in ULA subnets". I think it is very clear explanation in mul= tiple ULA prefixes requirement.=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From hiromi@inetcore.com Fri Mar 23 01:34:52 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B179D21F8549 for ; Fri, 23 Mar 2012 01:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, J_CHICKENPOX_45=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 CD7RVn-k7GwT for ; Fri, 23 Mar 2012 01:34:52 -0700 (PDT) Received: from inc.inetcore.com (inc.inetcore.com [IPv6:2403:2000:1:1::11]) by ietfa.amsl.com (Postfix) with ESMTP id E398721F8548 for ; Fri, 23 Mar 2012 01:34:51 -0700 (PDT) Received: from [IPv6:2403:2000:1:3:497f:3aff:dda0:b896] (unknown [IPv6:2403:2000:1:3:497f:3aff:dda0:b896]) by inc.inetcore.com (Postfix) with ESMTPSA id 88E94376932; Fri, 23 Mar 2012 17:34:50 +0900 (JST) Message-ID: <4F6C35A5.4030105@inetcore.com> Date: Fri, 23 Mar 2012 17:34:45 +0900 From: Ruri Hiromi Organization: INTEC Inc. User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: GangChen References: <4F6AB545.50904@inetcore.com> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] Comments on draft-hazeyama-widecamp-ipv6-only-experience-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 08:34:52 -0000 Hello GangChen and all, We are still holding to submit of -02 and if you access to the datatracker you see NO in that part. >>> 2. I guess some statements on "dependency between IPv4 and IPv6 >>> address" should be clarified further. >> >> Thank you for the advice. We will modify it more appropriate expression. > > It would be good if you could give more details on the list. In 5.1 we wrote it as following; ---------- 5.1. Dependency between IPv4 and IPv6 address configuration In this 2nd experiment, we observed troubles due to the dependency between IPv4 and IPv6 address configuration. We think, both IPv4 and IPv6 address configuration SHOULD work independently in a device or an OS. ---------- We looked some OS failed to get/use of IPv6 address if there is no IPv4 address. Some OS tries to get IPv4 address over and over again until local auto configured IPv4 address appeared and won't to get IPv6 address. The OS get both IPv4 and IPv6 address if IPv4 private/global address is available on the NIC. We thought that kind of OS has a wrong procedure in address configuration implementation. Android OS is one of them but not all the Android OS behave as above and it is presumed to be from vendor customization. BTW MacOS X(10.7.0) 's Network Configuration GUI has another problem. At the camp network we use several IPv4 addresses and switch over from one AP to other AP, this might be a corner case but we saw a previously used IPv4 address come up on the GUI and "ipconfig" command replied local auto configured IPv4 address. Renew button in the GUI does not work correctly always displayed that previously used(wrong ranged, abandoned) address. Best Regards, (2012/03/22 16:01), GangChen wrote: > Hello Ruri, > > 2012/3/22, Ruri Hiromi : >> Consequently the correct answer for this goes "yes". >> We will make a correction at Frag. C => S in the 4rd/IPoE case on table >> 7 as follows. >> >> +-----------------+-------------------+------------------+ >> | Elements | 4RD/PPPoE (v4) | 4RD/IPoE (v4) | >> +-----------------+-------------------+------------------+ >> | NAT | Exist | Exist | >> | --------------- | ----------------- | ---------------- | >> | Mapping | Bad | Good | >> | --------------- | ----------------- | ---------------- | >> | Filtering | Good | Good | >> | --------------- | ----------------- | ---------------- | >> | RTT | 156 | 323 | >> | --------------- | ----------------- | ---------------- | >> | MTU size C => S | 1452 | 1452 | >> | --------------- | ----------------- | ---------------- | >> | Frag. C => S | NO | YES | > ^^^^^^^ > > Still NO here? I guess that's a typo? > >> >> >>> 2. I guess some statements on "dependency between IPv4 and IPv6 >>> address" should be clarified further. >> >> Thank you for the advice. We will modify it more appropriate expression. > > It would be good if you could give more details on the list. > > Many thanks > > Gang -- --------------- Ruri Hiromi INTEC Inc. From gvandeve@cisco.com Fri Mar 23 03:13:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 802DD21F84B6 for ; Fri, 23 Mar 2012 03:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.344 X-Spam-Level: X-Spam-Status: No, score=-9.344 tagged_above=-999 required=5 tests=[AWL=-1.005, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, SARE_STILLSINGLE=1.66] 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 cd2erHIEczeL for ; Fri, 23 Mar 2012 03:13:49 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 90F0121F8447 for ; Fri, 23 Mar 2012 03:13:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=gvandeve@cisco.com; l=2026; q=dns/txt; s=iport; t=1332497628; x=1333707228; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=nPVb5I9Cg9aWmNWQ7YaUhslNB/lEogthC9aCy7aFsR4=; b=eqCw6F5LQE3bg0brr0JeDDOzJQdkEvlYFL2Bm7M06GlVftEUWx0QFsjN SkQCyyB33rrbXAe7Nwt+uYHGFTmlz3i5KqVr/HVTlttQq2oGW1lfKGVa6 cddlQsOkS+ZZUekx0vsMvSZ20HbrrP/Y8/731Fjf3MMua7RKrUTMelL6A 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAIpMbE+Q/khL/2dsb2JhbABEt3eBB4IJAQEBAwEBAQEPAR0KNAsFBwQCAQgRAwEBAQEKBhcBBgEgBh8JCAIEARIIGodjBQuZIJ56BIlthjNjBKEOgxGBaIJo X-IronPort-AV: E=Sophos;i="4.73,636,1325462400"; d="scan'208";a="69168062" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 23 Mar 2012 10:13:46 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2NADk2s026436; Fri, 23 Mar 2012 10:13:46 GMT Received: from xmb-ams-102.cisco.com ([144.254.74.77]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Mar 2012 11:13:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Mar 2012 11:13:45 +0100 Message-ID: <5C99EC8C99D9BB45AC51D20DC2AD2DC5072BC1E6@XMB-AMS-102.cisco.com> In-Reply-To: <47D40373-530E-433F-9A0F-51E299088A45@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] New Draft: Using Only Link-Local Address in Network Core thread-index: AQHNBpeUOttUlngqr0CMhcHW3EqGbpZ0vyoAgADuewCAACN6AIAAz6KAgAENLJA= References: <47D40373-530E-433F-9A0F-51E299088A45@huawei.com> From: "Gunter Van de Velde (gvandeve)" To: "Tina TSOU" , "Rajiv Asati (rajiva)" X-OriginalArrivalTime: 23 Mar 2012 10:13:46.0339 (UTC) FILETIME=[A2106330:01CD08DD] Cc: v6ops@ietf.org, "Michael Behringer \(mbehring\)" Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 10:13:53 -0000 Why? As long as CE gets a PD prefix for its users at home, then that should work just fine, not? G/ -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Tina TSOU Sent: vrijdag 23 maart 2012 4:15 To: Rajiv Asati (rajiva) Cc: v6ops@ietf.org; Michael Behringer (mbehring) Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core Link-Local Address can not be used in CE router or even lower position of enterprise service? Sent from my iPad On Mar 22, 2012, at 6:47 AM, "Rajiv Asati" wrote: > Yah, in that case, I agree. >=20 >=20 > -----Original Message----- > From: Gert Doering > Date: Thu, 22 Mar 2012 12:39:42 +0100 > To: Rajiv Asati > Cc: Jen Linkova , "Michael Behringer (mbehring)" > , > Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network > Core >=20 >> Hi, >>=20 >> On Wed, Mar 21, 2012 at 05:26:08PM -0400, Rajiv Asati wrote: >>> Wrt the last point, it is a common practice to dedicate a particular >>> subnet for the loopbacks. So, a single policy wouldn't cut it in that >>> case. >>=20 >> Dedicate a larger subnet (like, "a /48") for loopbacks + transit. >>=20 >> Still single policy. >>=20 >> Gert Doering >> -- NetMaster >> --=20 >> have you enabled IPv6 on something today...? >>=20 >> SpaceNet AG Vorstand: Sebastian v. Bomhard >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. >> Grundner-Culemann >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 >=20 >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From mohacsi@niif.hu Fri Mar 23 06:07:17 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B77221F852D for ; Fri, 23 Mar 2012 06:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.564 X-Spam-Level: * X-Spam-Status: No, score=1.564 tagged_above=-999 required=5 tests=[AWL=-0.693, BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, J_CHICKENPOX_13=0.6, SARE_STILLSINGLE=1.66] 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 5IoETUFq9kfR for ; Fri, 23 Mar 2012 06:07:13 -0700 (PDT) Received: from mail.ki.iif.hu (mail.ki.iif.hu [IPv6:2001:738:0:411::241]) by ietfa.amsl.com (Postfix) with ESMTP id 49E7521F850F for ; Fri, 23 Mar 2012 06:07:13 -0700 (PDT) Received: from bolha.lvs.iif.hu (bolha.lvs.iif.hu [193.225.14.181]) by mail.ki.iif.hu (Postfix) with ESMTP id DD5B187AA9; Fri, 23 Mar 2012 14:07:11 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at bolha.lvs.iif.hu Received: from mail.ki.iif.hu ([IPv6:::ffff:193.6.222.241]) by bolha.lvs.iif.hu (bolha.lvs.iif.hu [::ffff:193.225.14.72]) (amavisd-new, port 10024) with ESMTP id 9Mp5dQdhlM97; Fri, 23 Mar 2012 14:07:03 +0100 (CET) Received: by mail.ki.iif.hu (Postfix, from userid 9002) id A214487AA0; Fri, 23 Mar 2012 14:07:03 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.ki.iif.hu (Postfix) with ESMTP id 9FB1387A8F; Fri, 23 Mar 2012 14:07:03 +0100 (CET) Date: Fri, 23 Mar 2012 14:07:03 +0100 (CET) From: Mohacsi Janos X-X-Sender: mohacsi@mignon.ki.iif.hu To: "Gunter Van de Velde (gvandeve)" In-Reply-To: <5C99EC8C99D9BB45AC51D20DC2AD2DC5072BC1E6@XMB-AMS-102.cisco.com> Message-ID: References: <47D40373-530E-433F-9A0F-51E299088A45@huawei.com> <5C99EC8C99D9BB45AC51D20DC2AD2DC5072BC1E6@XMB-AMS-102.cisco.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org, "Michael Behringer \(mbehring\)" Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 13:07:17 -0000 Dear all, I Agree with Gunter. It is working. On my home router the addresses: root@OpenWrt:~# ip addr show 1: lo: mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope host lo inet6 fd00::1/64 scope global valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:24:01:6c:73:e6 brd ff:ff:ff:ff:ff:ff 3: eth1: mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:24:01:6c:73:e7 brd ff:ff:ff:ff:ff:ff inet xx.yy.23.1/30 brd xx.yy.23.3 scope global eth1 inet6 fe80::224:1ff:fe6c:73e7/64 scope link valid_lft forever preferred_lft forever 4: br-lan: mtu 1500 qdisc noqueue state UNKNOWN link/ether 00:24:01:6c:73:e6 brd ff:ff:ff:ff:ff:ff inet 192.168.0.1/24 brd 192.168.0.255 scope global br-lan inet6 2001:738:xxxx:yyyy:224:1ff:fe6c:73e6/64 scope global valid_lft forever preferred_lft forever inet6 fe80::224:1ff:fe6c:73e6/64 scope link valid_lft forever preferred_lft forever The only global IPv6 address on interface 4: I got via DHCPv6-PD. Best Regards, Janos Mohacsi Head of HBONE+ project Network Engineer, Deputy Director Network and Multimedia NIIF/HUNGARNET, HUNGARY Co-chair of Hungarian IPv6 Forum Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Fri, 23 Mar 2012, Gunter Van de Velde (gvandeve) wrote: > Why? > > As long as CE gets a PD prefix for its users at home, then that should > work just fine, not? > > G/ > > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Tina TSOU > Sent: vrijdag 23 maart 2012 4:15 > To: Rajiv Asati (rajiva) > Cc: v6ops@ietf.org; Michael Behringer (mbehring) > Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network > Core > > Link-Local Address can not be used in CE router or even lower position > of enterprise service? > > Sent from my iPad > > On Mar 22, 2012, at 6:47 AM, "Rajiv Asati" wrote: > >> Yah, in that case, I agree. >> >> >> -----Original Message----- >> From: Gert Doering >> Date: Thu, 22 Mar 2012 12:39:42 +0100 >> To: Rajiv Asati >> Cc: Jen Linkova , "Michael Behringer (mbehring)" >> , >> Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in > Network >> Core >> >>> Hi, >>> >>> On Wed, Mar 21, 2012 at 05:26:08PM -0400, Rajiv Asati wrote: >>>> Wrt the last point, it is a common practice to dedicate a particular >>>> subnet for the loopbacks. So, a single policy wouldn't cut it in > that >>>> case. >>> >>> Dedicate a larger subnet (like, "a /48") for loopbacks + transit. >>> >>> Still single policy. >>> >>> Gert Doering >>> -- NetMaster >>> -- >>> have you enabled IPv6 on something today...? >>> >>> SpaceNet AG Vorstand: Sebastian v. Bomhard >>> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. >>> Grundner-Culemann >>> D-80807 Muenchen HRB: 136055 (AG Muenchen) >>> Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 >> >> >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > From d.sturek@att.net Fri Mar 23 06:14:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A9F21F8514 for ; Fri, 23 Mar 2012 06:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.169 X-Spam-Level: X-Spam-Status: No, score=-1.169 tagged_above=-999 required=5 tests=[AWL=-0.830, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, SARE_STILLSINGLE=1.66] 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 koYc2GVweVtZ for ; Fri, 23 Mar 2012 06:14:23 -0700 (PDT) Received: from nm16-vm0.bullet.mail.ne1.yahoo.com (nm16-vm0.bullet.mail.ne1.yahoo.com [98.138.91.49]) by ietfa.amsl.com (Postfix) with SMTP id 5528E21F8503 for ; Fri, 23 Mar 2012 06:14:23 -0700 (PDT) Received: from [98.138.90.48] by nm16.bullet.mail.ne1.yahoo.com with NNFMP; 23 Mar 2012 13:14:18 -0000 Received: from [68.142.200.226] by tm1.bullet.mail.ne1.yahoo.com with NNFMP; 23 Mar 2012 13:14:18 -0000 Received: from [66.94.237.106] by t7.bullet.mud.yahoo.com with NNFMP; 23 Mar 2012 13:14:18 -0000 Received: from [127.0.0.1] by omp1011.access.mail.mud.yahoo.com with NNFMP; 23 Mar 2012 13:14:18 -0000 X-Yahoo-Newman-Id: 616481.79311.bm@omp1011.access.mail.mud.yahoo.com Received: (qmail 78867 invoked from network); 23 Mar 2012 13:14:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1332508458; bh=xcyqFnwJPn86A4OoW1jFFt27k04B0bfT1KbwuPpKsi0=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=kJTUIPMO9ou7RDQFhPIr692aQm5QKhuaaMWdWyUnRqEIN5e4w2Nfh1TxcrmGecyrhIOmvPSNL7EVl7VFC2DvdHV7a8qtrtAnNyas3PZxWCUcCOPXv3vkYBIf008Xzosh8ztRFUa4wk4F3BO87Nd3XV0aNO6OIiqKXcfGPPR5KQE= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: VWIw8R0VM1mtYo9YVi8qmzLfDcHi5qWP2i9kHTA.r3leVlS dz9v6jn1GB8JroYD44gy5kd3YePLytya9athPbdcQc6DVfhNTgCsqa8FNgBv kuDfyM9w0ovLM86C9lP1_EimqQV_.k1VvIIEuqqQFxXxSCbrzl7yyLEfJfp1 gysQqh_JkEwZvFOvMugWyS3jNxJb15R9cCUxD75X.ejHl2U7cb_FjhPsm7aT cT5jcw1SBByxTD5W6QOG4dxzONZQx_MKvQHt2s4EByeoISlPT8cvT1SAS3Op GOtrgDN9PBQGWQ3XDH5Qwf4OHkwUnSdPiTnElTkvMI6T7dmrs_oBbwbn.w33 rHhxeqA0X_RP9KZQo6sa08PG3zgnnwLZuC1TYHjZ0K1aG91AnKPN3_xUkXEY i23wcIBImHFxiVjyDd3MGts5M_YoyvYIS59ir87LgyUTzAP1qLdnV2I_Nybw xax02NZe_8kcN1rRwgrlvuQMZxd00EjabEmO6aeVawpKk4MV7o6fIZwQLCYA KhG3u77PWpM_i X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [192.168.0.196] (d.sturek@69.224.122.17 with login) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 23 Mar 2012 06:14:17 -0700 PDT User-Agent: Microsoft-MacOutlook/14.14.0.111121 Date: Fri, 23 Mar 2012 06:13:01 -0700 From: Don Sturek To: Mohacsi Janos , "Gunter Van de Velde \(gvandeve\)" Message-ID: Thread-Topic: [v6ops] New Draft: Using Only Link-Local Address in Network Core In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: v6ops@ietf.org, "Michael Behringer \(mbehring\)" Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 13:14:27 -0000 Hi Gunter, There are several MAC/PHY technologies that don't support bridging (eg, IEEE 802.15.4-2006, PLC solutions like G3, etc.). Adding ROLL RPL as a routing solution to these MAC/PHYs mean that link locals don't cover the entire residence in scope. Many homeowners don't want to rely on a global prefix just to support local functions like finding a printer. Hence the requirement for ULAs in these settings...... Don On 3/23/12 6:07 AM, "Mohacsi Janos" wrote: >Dear all, > >I Agree with Gunter. It is working. On my home router the addresses: > >root@OpenWrt:~# ip addr show >1: lo: mtu 16436 qdisc noqueue state UNKNOWN > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 brd 127.255.255.255 scope host lo > inet6 fd00::1/64 scope global > valid_lft forever preferred_lft forever > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever >2: eth0: mtu 1500 qdisc pfifo_fast >state >UP qlen 1000 > link/ether 00:24:01:6c:73:e6 brd ff:ff:ff:ff:ff:ff >3: eth1: mtu 1500 qdisc pfifo_fast >state >UP qlen 1000 > link/ether 00:24:01:6c:73:e7 brd ff:ff:ff:ff:ff:ff > inet xx.yy.23.1/30 brd xx.yy.23.3 scope global eth1 > inet6 fe80::224:1ff:fe6c:73e7/64 scope link > valid_lft forever preferred_lft forever >4: br-lan: mtu 1500 qdisc noqueue state >UNKNOWN > link/ether 00:24:01:6c:73:e6 brd ff:ff:ff:ff:ff:ff > inet 192.168.0.1/24 brd 192.168.0.255 scope global br-lan > inet6 2001:738:xxxx:yyyy:224:1ff:fe6c:73e6/64 scope global > valid_lft forever preferred_lft forever > inet6 fe80::224:1ff:fe6c:73e6/64 scope link > valid_lft forever preferred_lft forever > >The only global IPv6 address on interface 4: I got via DHCPv6-PD. > >Best Regards, > >Janos Mohacsi >Head of HBONE+ project >Network Engineer, Deputy Director Network and Multimedia >NIIF/HUNGARNET, HUNGARY >Co-chair of Hungarian IPv6 Forum >Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 > >On Fri, 23 Mar 2012, Gunter Van de Velde (gvandeve) wrote: > >> Why? >> >> As long as CE gets a PD prefix for its users at home, then that should >> work just fine, not? >> >> G/ >> >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf >> Of Tina TSOU >> Sent: vrijdag 23 maart 2012 4:15 >> To: Rajiv Asati (rajiva) >> Cc: v6ops@ietf.org; Michael Behringer (mbehring) >> Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network >> Core >> >> Link-Local Address can not be used in CE router or even lower position >> of enterprise service? >> >> Sent from my iPad >> >> On Mar 22, 2012, at 6:47 AM, "Rajiv Asati" wrote: >> >>> Yah, in that case, I agree. >>> >>> >>> -----Original Message----- >>> From: Gert Doering >>> Date: Thu, 22 Mar 2012 12:39:42 +0100 >>> To: Rajiv Asati >>> Cc: Jen Linkova , "Michael Behringer (mbehring)" >>> , >>> Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in >> Network >>> Core >>> >>>> Hi, >>>> >>>> On Wed, Mar 21, 2012 at 05:26:08PM -0400, Rajiv Asati wrote: >>>>> Wrt the last point, it is a common practice to dedicate a particular >>>>> subnet for the loopbacks. So, a single policy wouldn't cut it in >> that >>>>> case. >>>> >>>> Dedicate a larger subnet (like, "a /48") for loopbacks + transit. >>>> >>>> Still single policy. >>>> >>>> Gert Doering >>>> -- NetMaster >>>> -- >>>> have you enabled IPv6 on something today...? >>>> >>>> SpaceNet AG Vorstand: Sebastian v. Bomhard >>>> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. >>>> Grundner-Culemann >>>> D-80807 Muenchen HRB: 136055 (AG Muenchen) >>>> Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 >>> >>> >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >> >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From mark@townsley.net Fri Mar 23 15:49:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E625F21F8522 for ; Fri, 23 Mar 2012 15:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.892 X-Spam-Level: X-Spam-Status: No, score=-2.892 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 AxrhOCS7Gunl for ; Fri, 23 Mar 2012 15:49:11 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2332321F851E for ; Fri, 23 Mar 2012 15:49:10 -0700 (PDT) Received: by werb10 with SMTP id b10so3587999wer.31 for ; Fri, 23 Mar 2012 15:49:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to:x-mailer:x-gm-message-state:content-type :content-transfer-encoding; bh=sYB9204mdsEktQ8813H5/N2x9BQS9USlIUGA9/HgnsE=; b=lQH+9jaOU6uAssT6ExM6H1rn1CK5GoN6XrZOyVoS2sg51LB96xjlhPpOyh1SRuY57V w/UrIBI+Oni051vvHjBthdIZyX3c6eZ35H6NAacKrSLDiMvWodUJ0BF9VeZqQgKuMLXA qSeBrc22JqyYURF2+3lO6wjK5NwWfFPRFtJGtpeza0awkWPx08302CVlLOMZHuP8orBl 0pNzbDErgnJxZwVklhi+mVyZv7YeFuc/qVsE5VZjzUPHsOfyEjCzFQWxCRjdEiB3PSWj EH3XQxGJapNXU8PxweVkNEjJGT9PGlnI+zf0A34d5GXlQUOl39tcFhDm2j8a8ldme7Om MeVQ== Received: by 10.180.79.135 with SMTP id j7mr651457wix.19.1332542950310; Fri, 23 Mar 2012 15:49:10 -0700 (PDT) Received: from ams-townsley-8914.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id l5sm17579978wia.11.2012.03.23.15.49.07 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Mar 2012 15:49:08 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) From: Mark Townsley In-Reply-To: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> Date: Fri, 23 Mar 2012 23:49:05 +0100 Message-Id: References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkHTB7imna/StEEgSEO8S/hIdIUxc6OliWylj8uJ10LUV5Ns7YE/j6Ru3xJ46J23Yd+dcxY Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 22:49:12 -0000 The current description of 6rd and ds-lite in 6204bis dangerously avoids = the issue of how to gracefully transition from a native IPv4 to = Dual-Stack lite, in particular with a retail CPE vs. ISP-managed CPE. = The same is true for graceful sunsetting of 6rd to native IPv6. Ole and I captured the rather heated discussion on v6ops a couple of = months back in the following document: = draft-townsley-troan-ipv6-ce-transitioning-02 I believe the problem here is that there is demand from operators to = include DS-Lite and 6rd in this document is very strong, yet the = implementation details have not been specified well enough to allow = DS-Lite and Native IPv4 or Native IPv6 and 6rd to coexist in a = consistent and non-distruptive manner with one another. This is fairly = dangerous as it will undoubtedly lead to highly variant implementation. = I can easily see this sinking the ability to incrementally deploy = DS-Lite in a retail CPE setting, for example. It could also be = detrimental to sunsetting of 6rd. I'd be happy to present the issue to v6ops. I think the issue needs to = be voiced (as the draft appeared since the last meeting, it has not had = airtime in any IETF meeting yet, despite us revving a couple of times).=20= - Mark =20 On Mar 8, 2012, at 10:30 PM, Fred Baker wrote: > This is to initiate a two week working group last call of = draft-ietf-v6ops-6204bis. Please read it now. If you find nits (spelling = errors, minor suggested wording changes, etc), comment to the authors; = if you find greater issues, such as disagreeing with a statement or = finding additional issues that need to be addressed, please post your = comments to the list. The draft will be on the agenda at IETF 83, and I = would like to send the authors home with a work plan to complete it if = it is not to the WG's liking. >=20 > We are looking specifically for comments on the importance of the = document as well as its content. If you have read the document and = believe it to be of operational utility, that is also an important = comment to make. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From mark@townsley.net Fri Mar 23 16:05:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6C221E8027 for ; Fri, 23 Mar 2012 16:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 IW6GYt1dtf4D for ; Fri, 23 Mar 2012 16:05:02 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id BC14221E8011 for ; Fri, 23 Mar 2012 16:05:01 -0700 (PDT) Received: by wibhr17 with SMTP id hr17so2206963wib.1 for ; Fri, 23 Mar 2012 16:05:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=OMiEK+ctKyRfYCPSUhyMq8RyrbY/0oX9ZP6hJDRmZCI=; b=LwALoS4iBJ/YvMQJo7E0z0dxL3iasUm7vJsaPvW1DD0uiWCHFFWBBaTaGYaCBqQA/0 JWhV7oSp+n5iLa2o0yGh5yrot+ZFWB9WndXGXPKm/VarbnHQ48H0tOtTdreSEcrsJwVD FlOl49/1k8ySqpE9pO5oox+ukSp45Lu9Y+q5kqzBTAAoGPC5FuwBgHF0TvfMW3eF5iNX ILlKBKyJVzfGP17dlYh24dD+eTzVooYEqwEanpMwrHIme2DPKTi4N75+Gfpa/ab43F+M Lsi5NB587ISGS7DtqToXFW3U6YE7h2R791fZbwaE4g0EUpQ95OOQM+LB67vZEF5rKn0K 3jdg== Received: by 10.180.95.34 with SMTP id dh2mr758583wib.15.1332543900932; Fri, 23 Mar 2012 16:05:00 -0700 (PDT) Received: from ams-townsley-8914.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id b3sm17708581wib.4.2012.03.23.16.04.58 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 23 Mar 2012 16:04:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Mark Townsley In-Reply-To: <201203171355.q2HDt0Q29532@ftpeng-update.cisco.com> Date: Sat, 24 Mar 2012 00:04:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <00457860-5834-4AD1-8A82-2F2EDD319756@townsley.net> References: <201203171355.q2HDt0Q29532@ftpeng-update.cisco.com> To: X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQlT09KMSMiQ+choZTQJLY74R0pJAwL/iD1ImAwFbOinubIgRwOwYSDfUlq/wAXIo95OWyqk Cc: v6ops@ietf.org, Alexandre Cassen , draft-townsley-v6ops-6rd-sunsetting@tools.ietf.org Subject: Re: [v6ops] new draft: draft-townsley-v6ops-6rd-sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 23:05:03 -0000 On Mar 17, 2012, at 2:55 PM, wrote: >=20 > A new draft has been posted, at = http://tools.ietf.org/html/draft-townsley-v6ops-6rd-sunsetting. Please = take a look at it and comment. It's actually not a new draft, it's an "old" one, posted during the IETF = meeting in Taipei last November. After our admittedly tardy posting, the = Chairs asked me to pull together a presentation on it, which I was happy = to do though the time was quite rushed if I recall. I think the = meeting-based conversation on this one started but did not finish. In any case, since then Ole and I worked out a draft that incorporates = the 6rd sunsetting issue together with the related (yet "inverted") = issue that ds-lite has. This is described in = draft-townsley-troan-ipv6-ce-transitioning-02. As mentioned in my other mail, 6204-bis is skirting this issue in what I = continue to assert will end up as dangerous to both technologies should = 6204-bis become the reference for inclusion of 6rd or ds-lite into = retail CPE hardware. Chairs: Alexandre from Free *may* be available Monday (and only Monday) = for presentation or Q&A on 6rd-sunsetting if you can squeeze it in as = the last presentation (I only know this as CIsco is trying to arrange = our "host lunch presentation" on Monday to include him and others to = discuss the upcoming v6world launch, so he would have to be here at noon = for that anyway - perhaps we can talk him into coming at 11). As the = largest 6rd (and IPv6) operator in the world, it might be worth making = time for=85 In particular as generally he and his team does not have = time to contribute directly to IETF activities, even if they are = certainly contributing to IETF running code.=20 Thanks, - Mark From fred@cisco.com Fri Mar 23 16:23:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6FB21E8011 for ; Fri, 23 Mar 2012 16:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.209 X-Spam-Level: X-Spam-Status: No, score=-110.209 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, 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 cLqvxlaJWIgR for ; Fri, 23 Mar 2012 16:23:46 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id AEA9F21E800F for ; Fri, 23 Mar 2012 16:23:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=2301; q=dns/txt; s=iport; t=1332545025; x=1333754625; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=W/RmV4RYXb9nW/3JjHkI2Jimcz7e1qQ1IRwLof3SkZs=; b=OFV4UbIgS9GOeyvatOGi7UvkDqcQsxkG4lh/+zNnToaU2LMDizfqtwIl GJNRyugZPrPCLu3YXxRw4IQbY4022CMNUBG9USKHlXlUulwV9i/kGmNjA g9MWFy64rIRtusQxBhE6BgMfs9e/rpu1lr9VSDz2E67JbzrVlq854d8+l E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABsFbU+Q/khL/2dsb2JhbABEuBqBB4IJAQEBAwESAWYQCxguVwYTIodjBQuZXJ5simOFP2MElWCFbohWgWiCaIFb X-IronPort-AV: E=Sophos;i="4.73,639,1325462400"; d="scan'208";a="133227433" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 23 Mar 2012 23:23:44 +0000 Received: from Freds-Computer.local (ams3-vpn-dhcp4219.cisco.com [10.61.80.122]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2NNNhfA027076; Fri, 23 Mar 2012 23:23:43 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Sat, 24 Mar 2012 00:23:44 +0100 X-PGP-Universal: processed; by Freds-Computer.local on Sat, 24 Mar 2012 00:23:44 +0100 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <00457860-5834-4AD1-8A82-2F2EDD319756@townsley.net> Date: Sat, 24 Mar 2012 00:23:29 +0100 Message-Id: <115AB445-0A53-4675-B74C-79BFEAF1D53B@cisco.com> References: <201203171355.q2HDt0Q29532@ftpeng-update.cisco.com> <00457860-5834-4AD1-8A82-2F2EDD319756@townsley.net> To: Mark Townsley X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org, Alexandre Cassen , draft-townsley-v6ops-6rd-sunsetting@tools.ietf.org Subject: Re: [v6ops] new draft: draft-townsley-v6ops-6rd-sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Mar 2012 23:23:47 -0000 Well, we have had 182 messages on the topic since IETF 82. It fits that = criterion. I have a problem in that Monday's agenda is pretty full. Let's discuss = Monday during the agenda bash, and we may move a discussion to Thursday. = I'll be looking for a volunteer; with my luck, I'll move someone that = has a dead short conflict if I pick at random. On Mar 24, 2012, at 12:04 AM, Mark Townsley wrote: >=20 > On Mar 17, 2012, at 2:55 PM, wrote: >=20 >>=20 >> A new draft has been posted, at = http://tools.ietf.org/html/draft-townsley-v6ops-6rd-sunsetting. Please = take a look at it and comment. >=20 >=20 > It's actually not a new draft, it's an "old" one, posted during the = IETF meeting in Taipei last November. After our admittedly tardy = posting, the Chairs asked me to pull together a presentation on it, = which I was happy to do though the time was quite rushed if I recall. I = think the meeting-based conversation on this one started but did not = finish. >=20 > In any case, since then Ole and I worked out a draft that incorporates = the 6rd sunsetting issue together with the related (yet "inverted") = issue that ds-lite has. This is described in = draft-townsley-troan-ipv6-ce-transitioning-02. >=20 > As mentioned in my other mail, 6204-bis is skirting this issue in what = I continue to assert will end up as dangerous to both technologies = should 6204-bis become the reference for inclusion of 6rd or ds-lite = into retail CPE hardware. >=20 > Chairs: Alexandre from Free *may* be available Monday (and only = Monday) for presentation or Q&A on 6rd-sunsetting if you can squeeze it = in as the last presentation (I only know this as CIsco is trying to = arrange our "host lunch presentation" on Monday to include him and = others to discuss the upcoming v6world launch, so he would have to be = here at noon for that anyway - perhaps we can talk him into coming at = 11). As the largest 6rd (and IPv6) operator in the world, it might be = worth making time for=85 In particular as generally he and his team does = not have time to contribute directly to IETF activities, even if they = are certainly contributing to IETF running code.=20 >=20 > Thanks, >=20 > - Mark >=20 >=20 >=20 >=20 From shemant@cisco.com Fri Mar 23 17:02:11 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6847A21E8015 for ; Fri, 23 Mar 2012 17:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.935 X-Spam-Level: X-Spam-Status: No, score=-9.935 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 o0Glwl-+Llzz for ; Fri, 23 Mar 2012 17:02:10 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9DFC521E800F for ; Fri, 23 Mar 2012 17:02:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3426; q=dns/txt; s=iport; t=1332547330; x=1333756930; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=A5GoZAyNsj4CJ9QRrfHDPlp2jKMr8SShKvSn+Ec0NXk=; b=YxpwLXXMzSIeOCKR58TLyDFjT/+eSskKg64Yuke6slJ+p73KSBWtKs7L kK4Giczuc89hWyr0e+8zq3VU5ang47Zi3IqupZcqIDvvkROHseFeKVOnf FIT31i/++ABucy2kR10y7OgNAkdo1I9E9mJ07prOP1nYKTjIf6tke0Dh8 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAEsObU+tJXG//2dsb2JhbABEuBqBB4IJAQEBAwEBAQEPAR0KNAsFBwQCAQgRBAEBCwYXAQYBJh8JCAEBBAESCBqHYwULmVCeYwSQImMEiFebTYFogwWBPg X-IronPort-AV: E=Sophos;i="4.73,639,1325462400"; d="scan'208";a="66014376" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 24 Mar 2012 00:02:10 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2O02Ao2022992; Sat, 24 Mar 2012 00:02:10 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Mar 2012 19:02:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 23 Mar 2012 19:02:05 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30444B2D2@XMB-RCD-109.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6204bis WGLC Thread-Index: Ac0JRzuyMrej3kE6ROuQiofM5U20TgACTS6w References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> From: "Hemant Singh (shemant)" To: "Mark Townsley" , "Fred Baker (fred)" X-OriginalArrivalTime: 24 Mar 2012 00:02:06.0941 (UTC) FILETIME=[59EE68D0:01CD0951] Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 00:02:11 -0000 draft-townsley-troan-ipv6-ce-transitioning-02 is not an RFC yet nor in the IESG review and thus this document has to be punted to rfc6204ter. Further the tech described in the document should be a Standard Tracks document. Chris Donley who represents all Cable MSO's from Cablelabs has expressed an urgent desire to get rfc6204bis out as an RFC by December 2011. Barbara Stark has expressed a similar desire. Further FT Orange and Telecom Italia have expressed the urgency too. If this email can humbly be considered for closure, one can avoid a lengthy discussion at Paris during the presentation of rfc6204bis in v6ops. For a much later consideration, which mailing list is draft-townsley-troan-ipv6-ce-transitioning-02 being discussed and where are the review comments? Hemant -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Mark Townsley Sent: Friday, March 23, 2012 6:49 PM To: Fred Baker (fred) Cc: v6ops@ietf.org; v6ops-chairs@tools.ietf.org; Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC The current description of 6rd and ds-lite in 6204bis dangerously avoids the issue of how to gracefully transition from a native IPv4 to Dual-Stack lite, in particular with a retail CPE vs. ISP-managed CPE. The same is true for graceful sunsetting of 6rd to native IPv6. Ole and I captured the rather heated discussion on v6ops a couple of months back in the following document: draft-townsley-troan-ipv6-ce-transitioning-02 I believe the problem here is that there is demand from operators to include DS-Lite and 6rd in this document is very strong, yet the implementation details have not been specified well enough to allow DS-Lite and Native IPv4 or Native IPv6 and 6rd to coexist in a consistent and non-distruptive manner with one another. This is fairly dangerous as it will undoubtedly lead to highly variant implementation. I can easily see this sinking the ability to incrementally deploy DS-Lite in a retail CPE setting, for example. It could also be detrimental to sunsetting of 6rd. I'd be happy to present the issue to v6ops. I think the issue needs to be voiced (as the draft appeared since the last meeting, it has not had airtime in any IETF meeting yet, despite us revving a couple of times).=20 - Mark =20 On Mar 8, 2012, at 10:30 PM, Fred Baker wrote: > This is to initiate a two week working group last call of draft-ietf-v6ops-6204bis. Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list. The draft will be on the agenda at IETF 83, and I would like to send the authors home with a work plan to complete it if it is not to the WG's liking. >=20 > We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From mark@townsley.net Sat Mar 24 00:36:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B5B21F8525 for ; Sat, 24 Mar 2012 00:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.908 X-Spam-Level: X-Spam-Status: No, score=-2.908 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 DiRhPlVhxI4T for ; Sat, 24 Mar 2012 00:36:22 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id EAB7E21F8522 for ; Sat, 24 Mar 2012 00:36:21 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so2210710wib.13 for ; Sat, 24 Mar 2012 00:36:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=PnACPSVtUM1R8Pas/llbg+GGW7vusQjGKtyUUKiNDxs=; b=MnAKCKvMSCCc+OgvGziRHOooUsA4erxhmzoAKB/G4wggQrBQjXBK8j8J34jbctj/HT 88e0zSuJ+9dFDPa4lf6rQbzG4U5ccAkqOgLLmjSbnV4+SxtAaXmOWJYkN7ci1/zRVJ4e 0Wud8h7u2XBjq9rtkx8zSzJCc9aLiUXkueQPElsX+81t0QDIsC08z+axdnli6EhXAfmt LjV7KNu5ma+H4tvKhc6LU1iJLUe9O+orV9G4X17FiKaXuEQafO9HRcZECnhCdY29kFkc jfdzTAizUgPcEMVh/RksNcpB40ccZMewUCFEs50iCEgSp6jdY7SkBHOAVPBm/iQwGhEH EnFQ== Received: by 10.180.14.73 with SMTP id n9mr3169588wic.16.1332574580941; Sat, 24 Mar 2012 00:36:20 -0700 (PDT) Received: from ams-townsley-8914.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id fn2sm34001215wib.0.2012.03.24.00.36.19 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 24 Mar 2012 00:36:20 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C30444B2D2@XMB-RCD-109.cisco.com> Date: Sat, 24 Mar 2012 08:36:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <27B6E9DD-9D64-41BB-BBBB-468F5E247916@townsley.net> References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30444B2D2@XMB-RCD-109.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQnDyoaZaefVcVM2uwyOamHLpGY0AmIUmrVF0NtQkvwCNVC8E/I5MGCytmwqR7UZJdwSvI3V Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 07:36:23 -0000 On Mar 24, 2012, at 1:02 AM, Hemant Singh (shemant) wrote: > draft-townsley-troan-ipv6-ce-transitioning-02 is not an RFC yet nor in Stating the obvious > the IESG review and thus this document has to be punted to rfc6204ter. Is there even consensus that a 6204ter document should exist at all? I = certainly hope not.=20 > Further the tech described in the document should be a Standard Tracks > document. =20 Perhaps. The problem is that the requirements placed in 6204bis require = some version of this tech (several options are identified, there is one = we prefer of course, but I argue that at least one by definition must be = chosen - 6204 bis just ignores it).=20 > Chris Donley who represents all Cable MSO's from Cablelabs In the IETF, Chris Donley represents Chris Donley. > has expressed an urgent desire to get rfc6204bis out as an RFC by > December 2011. Barbara Stark has expressed a similar desire. Further > FT Orange and Telecom Italia have expressed the urgency too. As above. > If this email can humbly be considered for closure, one can avoid a > lengthy discussion at Paris during the presentation of rfc6204bis in > v6ops. For a much later consideration, which mailing list is > draft-townsley-troan-ipv6-ce-transitioning-02 being discussed and = where > are the review comments? It's targeted at v6ops, but we made a mistake when we named it = obviously.=20 - Mark >=20 > Hemant >=20 > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of Mark Townsley > Sent: Friday, March 23, 2012 6:49 PM > To: Fred Baker (fred) > Cc: v6ops@ietf.org; v6ops-chairs@tools.ietf.org; Ron Bonica > Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC >=20 >=20 > The current description of 6rd and ds-lite in 6204bis dangerously = avoids > the issue of how to gracefully transition from a native IPv4 to > Dual-Stack lite, in particular with a retail CPE vs. ISP-managed CPE. > The same is true for graceful sunsetting of 6rd to native IPv6. >=20 > Ole and I captured the rather heated discussion on v6ops a couple of > months back in the following document: > draft-townsley-troan-ipv6-ce-transitioning-02 >=20 > I believe the problem here is that there is demand from operators to > include DS-Lite and 6rd in this document is very strong, yet the > implementation details have not been specified well enough to allow > DS-Lite and Native IPv4 or Native IPv6 and 6rd to coexist in a > consistent and non-distruptive manner with one another. This is fairly > dangerous as it will undoubtedly lead to highly variant = implementation. > I can easily see this sinking the ability to incrementally deploy > DS-Lite in a retail CPE setting, for example. It could also be > detrimental to sunsetting of 6rd. >=20 > I'd be happy to present the issue to v6ops. I think the issue needs to > be voiced (as the draft appeared since the last meeting, it has not = had > airtime in any IETF meeting yet, despite us revving a couple of = times).=20 >=20 > - Mark >=20 >=20 > On Mar 8, 2012, at 10:30 PM, Fred Baker wrote: >=20 >> This is to initiate a two week working group last call of > draft-ietf-v6ops-6204bis. Please read it now. If you find nits = (spelling > errors, minor suggested wording changes, etc), comment to the authors; > if you find greater issues, such as disagreeing with a statement or > finding additional issues that need to be addressed, please post your > comments to the list. The draft will be on the agenda at IETF 83, and = I > would like to send the authors home with a work plan to complete it if > it is not to the WG's liking. >>=20 >> We are looking specifically for comments on the importance of the > document as well as its content. If you have read the document and > believe it to be of operational utility, that is also an important > comment to make. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops >=20 > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From mark@townsley.net Sat Mar 24 00:44:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B77E21F851E for ; Sat, 24 Mar 2012 00:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.615 X-Spam-Level: X-Spam-Status: No, score=-2.615 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, 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 6v2-dJ8hxXZr for ; Sat, 24 Mar 2012 00:44:37 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id AD95A21F84E2 for ; Sat, 24 Mar 2012 00:44:36 -0700 (PDT) Received: by werb10 with SMTP id b10so3758901wer.31 for ; Sat, 24 Mar 2012 00:44:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=aks1o4MQoa35c/7pRuH3mlSj8KuhFI23tzeBiv/98k4=; b=UUG6XU1Nq/4A3NRpQ1nDmq6JtACmUf6/afrN0j4327o6xsKRT1+4jOR/FupmXoEcVk 12d9Be9FlnY493w+gIgki6tw2s4W8UENx3HkHjdk1tQ+atDvSqoqwFvEEmDAD0tSwdKT 7eqxhEwlNrW3F9Ta1eepAR5uGKcBl1N6ltxd5z19zdW12f+fkw9l3KwghlZweUnYBGQl j68W2XBDt7R7lt/4rf5jeLzXtoGgilWQhg4aFyrlgTlEzGPm3NRZfCUPDIR2nuTP4ld/ edrUoTUmTQIeMhdkG1ds73IYnCzU9UTHHw523v//IBSwzLHT6ZcFU4soKluffzxeKW44 Z8rQ== Received: by 10.216.141.212 with SMTP id g62mr8705996wej.2.1332575075771; Sat, 24 Mar 2012 00:44:35 -0700 (PDT) Received: from ams-townsley-8914.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id n8sm33973919wix.10.2012.03.24.00.44.32 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 24 Mar 2012 00:44:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Mark Townsley In-Reply-To: <115AB445-0A53-4675-B74C-79BFEAF1D53B@cisco.com> Date: Sat, 24 Mar 2012 08:44:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3D2F6FAC-0976-4E02-8C05-B6C26F582973@townsley.net> References: <201203171355.q2HDt0Q29532@ftpeng-update.cisco.com> <00457860-5834-4AD1-8A82-2F2EDD319756@townsley.net> <115AB445-0A53-4675-B74C-79BFEAF1D53B@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQnxyWqkxpiHfubeytq8WoksUISKjRp5wndy0PpooOj8ztZajcUdK7qBFvNXIcJ7Iv9g/+Gd Cc: v6ops@ietf.org, Alexandre Cassen , draft-townsley-v6ops-6rd-sunsetting@tools.ietf.org Subject: Re: [v6ops] new draft: draft-townsley-v6ops-6rd-sunsetting X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 07:44:37 -0000 On Mar 24, 2012, at 12:23 AM, Fred Baker wrote: > Well, we have had 182 messages on the topic since IETF 82. It fits = that criterion. >=20 > I have a problem in that Monday's agenda is pretty full. Let's discuss = Monday during the agenda bash, and we may move a discussion to Thursday. = I'll be looking for a volunteer; with my luck, I'll move someone that = has a dead short conflict if I pick at random. That's fair enough.=20 FWIW, I do recall us requesting a slot for = draft-townsley-troan-ipv6-ce-transitioning a while back (via email to = the chairs), but perhaps it got lost as we didn't put "v6ops" in the = name. As we don't match the regular expression in Henrik's tools for = v6ops, it could have easily been overlooked and I didn't review the = agenda myself until yesterday evening.=20 - Mark >=20 > On Mar 24, 2012, at 12:04 AM, Mark Townsley wrote: >=20 >>=20 >> On Mar 17, 2012, at 2:55 PM, wrote: >>=20 >>>=20 >>> A new draft has been posted, at = http://tools.ietf.org/html/draft-townsley-v6ops-6rd-sunsetting. Please = take a look at it and comment. >>=20 >>=20 >> It's actually not a new draft, it's an "old" one, posted during the = IETF meeting in Taipei last November. After our admittedly tardy = posting, the Chairs asked me to pull together a presentation on it, = which I was happy to do though the time was quite rushed if I recall. I = think the meeting-based conversation on this one started but did not = finish. >>=20 >> In any case, since then Ole and I worked out a draft that = incorporates the 6rd sunsetting issue together with the related (yet = "inverted") issue that ds-lite has. This is described in = draft-townsley-troan-ipv6-ce-transitioning-02. >>=20 >> As mentioned in my other mail, 6204-bis is skirting this issue in = what I continue to assert will end up as dangerous to both technologies = should 6204-bis become the reference for inclusion of 6rd or ds-lite = into retail CPE hardware. >>=20 >> Chairs: Alexandre from Free *may* be available Monday (and only = Monday) for presentation or Q&A on 6rd-sunsetting if you can squeeze it = in as the last presentation (I only know this as CIsco is trying to = arrange our "host lunch presentation" on Monday to include him and = others to discuss the upcoming v6world launch, so he would have to be = here at noon for that anyway - perhaps we can talk him into coming at = 11). As the largest 6rd (and IPv6) operator in the world, it might be = worth making time for=85 In particular as generally he and his team does = not have time to contribute directly to IETF activities, even if they = are certainly contributing to IETF running code.=20 >>=20 >> Thanks, >>=20 >> - Mark >>=20 >>=20 >>=20 >>=20 >=20 From shemant@cisco.com Sat Mar 24 02:31:32 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B30C21F8700 for ; Sat, 24 Mar 2012 02:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.935 X-Spam-Level: X-Spam-Status: No, score=-9.935 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 SDhCZoCr8Ul7 for ; Sat, 24 Mar 2012 02:31:30 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDDC21F86F5 for ; Sat, 24 Mar 2012 02:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=10754; q=dns/txt; s=iport; t=1332581490; x=1333791090; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=jJAH+QjGpUKDkPcltAEO1wTvWTt1YwtFS+Opxk6BIcI=; b=dtpSnFkAVgb6Q20TRpjDxQSCp944QScREDpflgE1eJ0jhT36+IYGUIsR Vh37U9gQB1FrOw0wME0/NZTQInyP+OXAg0E5/gKsxGLOScMbgBskIgVts 6+uFFbgbLCaD90ID+bFkZo/oJmCZtM1XvA6Gv9rYyjQ2060ctZLT4b58D U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAAGUbU+tJV2d/2dsb2JhbABEgka1WoEHggkBAQEEEgEJEQM+CwwEAgEIEQQBAQsGFwEGAUUJCAEBBAESCBqHaJlZnmKQRWMEiFebToFogwWBPg X-IronPort-AV: E=Sophos;i="4.73,640,1325462400"; d="scan'208,217";a="69087304" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 24 Mar 2012 09:31:30 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q2O9VTqX004389; Sat, 24 Mar 2012 09:31:29 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 24 Mar 2012 04:31:29 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD09A0.E3EC1DD0" Date: Sat, 24 Mar 2012 04:31:27 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30444B2E1@XMB-RCD-109.cisco.com> In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C30444B2D2@XMB-RCD-109.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] draft-ietf-v6ops-6204bis WGLC Thread-Index: Ac0JRzuyMrej3kE6ROuQiofM5U20TgACTS6wAAIgYFA= References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30444B2D2@XMB-RCD-109.cisco.com> From: "Hemant Singh (shemant)" To: "Hemant Singh (shemant)" , "Mark Townsley" , "Fred Baker (fred)" X-OriginalArrivalTime: 24 Mar 2012 09:31:29.0574 (UTC) FILETIME=[E4728460:01CD09A0] Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 09:31:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD09A0.E3EC1DD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 -----Original Message----- From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Hemant Singh (shemant) Sent: Friday, March 23, 2012 8:02 PM To: Mark Townsley; Fred Baker (fred) Cc: v6ops@ietf.org; v6ops-chairs@tools.ietf.org; Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC =20 >For a much later consideration, which mailing list is >draft-townsley-troan-ipv6-ce-transitioning-02 being discussed and where >are the review comments? =20 Sorry that I just read Fred's email about 184 emails on this topic. I got thrown off seeing no v6ops in the draft name above. I have seen the discussions on 6rd sunsetting but those are mostly general discussions. As Barbara said an SP deploys 6rd or DS-Lite, so why bother for 6rd, DS-Lite, and native dual-stack coexistence? =20 =20 The document is incomplete. Let's consider only IPv6 for now. There is an SRIB, DFIB, and a Policy Table. Additionally the CE does have a FIB. Where are the details for how does the FIB interface with the SRIB, DFIB, and the Policy Table? There are 24 combinations (4!) of results between the FIB, SRIB, DFIB, and the Policy Table. Which combination is used to forward a packet? Some conclusions below. =20 =20 (a) it is questionable if the work is even needed because the SP deploys one of 6rd and DS-Lite and one needs simpler 6rd sunsetting or DS-Lite sunsetting, and=20 (b) draft-townsley-troan-ipv6-ce-transitioning-02 is not ready to be adopted as a WG document. =20 Rfc6204bis can't be held up due to draft-townsley-troan-ipv6-ce-transitioning-02.=20 =20 Further, isn't draft-townsley-troan-ipv6-ce-transitioning-02 specifying technology or is there another document that covers the technology in more detail? Technology documents need to move to a different WG. =20 =20 Hemant =20 ------_=_NextPart_001_01CD09A0.E3EC1DD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

-----Original Message-----
From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@iet= f.org] On Behalf Of Hemant Singh (shemant)
Sent: Friday, March = 23, 2012 8:02 PM
To: Mark Townsley; Fred Baker (fred)
Cc: v6ops@ietf.org; v6ops-chairs@tools.ietf.org; Ron Bonica
Subject: Re: [v6ops] draft-ietf-v6ops-6204bis = WGLC

 

>For a = much later consideration, which mailing list is

>draft-townsley-troan-ipv6-ce-transitioning-02 being = discussed and where

>are the review = comments?

 

Sorry that I just read = Fred’s email about 184 emails on this topic.  I got thrown = off seeing no v6ops in the draft name above.  I have seen the = discussions on 6rd sunsetting but those are mostly general = discussions.  As Barbara said an SP deploys 6rd or DS-Lite, so why = bother for 6rd, DS-Lite, and native dual-stack coexistence?  =

 

The document is incomplete.  Let’s consider = only IPv6 for now. There is an SRIB, DFIB, and a Policy Table.  = Additionally the CE does have a FIB.  Where are the details for how = does the FIB interface with the SRIB, DFIB, and the Policy Table?  = There are 24 combinations (4!) of results between the FIB, SRIB, DFIB, = and the Policy Table.  Which combination is used to forward a = packet?  Some conclusions below.

 

 

(a)    = it is questionable if the work is even needed because = the SP deploys one of 6rd and DS-Lite and one needs simpler 6rd = sunsetting or DS-Lite sunsetting, and

(b)    = draft-townsley-troan-ipv6-ce-transitioning-02 is not = ready to be adopted as a WG document.

 

Rfc6204bis can’t be held up due to = draft-townsley-troan-ipv6-ce-transitioning-02.

 

Further, isn’t = draft-townsley-troan-ipv6-ce-transitioning-02 specifying technology or = is there another document that covers the technology in more = detail?  Technology documents need to move to a different WG.  =

 

Hemant

 

------_=_NextPart_001_01CD09A0.E3EC1DD0-- From fred@cisco.com Sat Mar 24 04:17:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA16D21F86D9 for ; Sat, 24 Mar 2012 04:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.523 X-Spam-Level: X-Spam-Status: No, score=-110.523 tagged_above=-999 required=5 tests=[AWL=0.076, 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 1Kh6mF0+9upg for ; Sat, 24 Mar 2012 04:17:35 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id D63C721F86E0 for ; Sat, 24 Mar 2012 04:17:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=1056; q=dns/txt; s=iport; t=1332587854; x=1333797454; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=C31NgGOVfniir15EN6C/vU42uB404aWSTkleXSWc1PQ=; b=HLZhE1xwa/GVXnHBEdclNTGqZR3slfLvXaGidpGhTYQuIQHtCXYfFMm6 iW4vEv/B/ApRyyUjlRS4CIAysCzdNP3LtVBRPvCTKMiL+60dpA8RtRPHY yv0WsleViAhYRZN+NIDWWUbxLHEE2+ZRdkoCg7IqS7cGqPtmR7rzHybiw c=; X-IronPort-AV: E=Sophos;i="4.73,641,1325462400"; d="scan'208";a="69242755" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 24 Mar 2012 11:17:31 +0000 Received: from dhcp-5155.meeting.ietf.org (dhcp-10-55-80-19.cisco.com [10.55.80.19]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2OBHThH016948; Sat, 24 Mar 2012 11:17:30 GMT Received: from [127.0.0.1] by dhcp-5155.meeting.ietf.org (PGP Universal service); Sat, 24 Mar 2012 12:17:31 +0100 X-PGP-Universal: processed; by dhcp-5155.meeting.ietf.org on Sat, 24 Mar 2012 12:17:31 +0100 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: <5B6B2B64C9FE2A489045EEEADDAFF2C30444B2E1@XMB-RCD-109.cisco.com> Date: Sat, 24 Mar 2012 12:16:34 +0100 Message-Id: <3723BC44-931F-4852-88A4-716931770F85@cisco.com> References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30444B2D2@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30444B2E1@XMB-RCD-109.cisco.com> To: Hemant Singh (shemant) X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 11:17:36 -0000 On Mar 24, 2012, at 10:31 AM, Hemant Singh (shemant) wrote: > Further, isn=92t draft-townsley-troan-ipv6-ce-transitioning-02 = specifying technology or is there another document that covers the = technology in more detail? Technology documents need to move to a = different WG.=20 I'm reading your statement above, and in other email reading statements = by someone using the same email address that go into some detail on the = implications of binary flags in messages. I'm wondering where the line = is drawn and why one draws it. I have asked a selection of ADs and WG Chairs to weigh in on where the = document should be discussed; if someone comes back to Joel and I with = "this obviously belongs in <>", we'll send it there or send the relevant = subset there. Personally, I think it falls within the charter of = operational procedures used in IPv6 networks. Where I draw the line on the normative reference that Ole and Mark would = like is how well baked the proposed procedures are. We will determine = that Monday.= From rdroms@cisco.com Sat Mar 24 04:26:40 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4BC521F86FD for ; Sat, 24 Mar 2012 04:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.966 X-Spam-Level: X-Spam-Status: No, score=-8.966 tagged_above=-999 required=5 tests=[AWL=-1.034, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 DENeKGgEs0W2 for ; Sat, 24 Mar 2012 04:26:40 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 23E0821F845C for ; Sat, 24 Mar 2012 04:26:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rdroms@cisco.com; l=2070; q=dns/txt; s=iport; t=1332588400; x=1333798000; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=E/1ZsuhFsH+D1F9vngyV2qE08F74UJ9hLurMQqUX6k4=; b=csB6j4fDiSyRX67KEPJ0ATw+4ZJk5r5vwo1sgSrrOECgo827ySrN+LYq svJl+Y4RpzH+VqOvq8JW2sfq9PjX8l6nQAPw8qTOgysAwPvIygAMkTxBP HM/DsCmydMX1hw6neI4/Dv0s4oUtuoxxJXOkskqFxalxy+vZKa+ha1HCR g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsMJAHCubU+tJV2d/2dsb2JhbABEhT+xYX4CgQeCCQEBAQMBAQEBDwEQEToLEAIBCBgCAiYCAgIlMAEBBBMih2MFC5lYjQiRVwSBL45hNWMElWCORYFogmiBWw X-IronPort-AV: E=Sophos;i="4.73,641,1325462400"; d="scan'208";a="69091744" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 24 Mar 2012 11:26:39 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id q2OBQdDH014488; Sat, 24 Mar 2012 11:26:39 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 24 Mar 2012 06:26:39 -0500 Received: from 72.163.43.39 ([72.163.43.39]) by XMB-RCD-202.cisco.com ([72.163.62.209]) with Microsoft Exchange Server HTTP-DAV ; Sat, 24 Mar 2012 11:26:39 +0000 References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30444B2D2@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30444B2E1@XMB-RCD-109.cisco.com> <3723BC44-931F-4852-88A4-716931770F85@cisco.com> Content-Transfer-Encoding: base64 From: "Ralph Droms (rdroms)" Content-Type: text/plain; charset="utf-8" Thread-Topic: [v6ops] draft-ietf-v6ops-6204bis WGLC Thread-Index: Ac0JsPrYNRsTImQsRYy+n1Sl0ZA++Q== In-Reply-To: <3723BC44-931F-4852-88A4-716931770F85@cisco.com> Message-ID: Date: Sat, 24 Mar 2012 12:26:35 +0100 To: "Fred Baker" MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 24 Mar 2012 11:26:39.0437 (UTC) FILETIME=[FB0BEFD0:01CD09B0] Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 11:26:40 -0000 RnJlZCAtIG5vdCBtZWFuaW5nIHRvIHN1Z2dlc3QgdGhpcyB0b3BpYyBpc24ndCBpbXBvcnRhbnQu Li5idXQgaXQncyB3YXkgdG9vIG5pY2UgYSBkYXkgdG8gZ2l2ZSB0aGUgaXNzdWUgdGhlIGNvbnNp ZGVyYXRpb24gaXQgZGVzZXJ2ZXMuICAgU28sIEknbGwgcG9zdCBhIHJlc3BvbnNlLCBidXQgbGlr ZWx5IG5vdCB1bnRpbCB0b21vcnJvdyB3aGVuIEknbGwgYmUgc2VxdWVzdGVyZWQgaW5kb29ycyBt b3N0IG9mIHRoZSBkYXksIGFueXdheS4NCg0KLSBSYWxwaA0KDQpPbiBNYXIgMjQsIDIwMTIsIGF0 IDEyOjE3IFBNLCAiRnJlZCBCYWtlciIgPGZyZWRAY2lzY28uY29tPiB3cm90ZToNCg0KPiANCj4g T24gTWFyIDI0LCAyMDEyLCBhdCAxMDozMSBBTSwgSGVtYW50IFNpbmdoIChzaGVtYW50KSB3cm90 ZToNCj4gDQo+PiBGdXJ0aGVyLCBpc27igJl0IGRyYWZ0LXRvd25zbGV5LXRyb2FuLWlwdjYtY2Ut dHJhbnNpdGlvbmluZy0wMiBzcGVjaWZ5aW5nIHRlY2hub2xvZ3kgb3IgaXMgdGhlcmUgYW5vdGhl ciBkb2N1bWVudCB0aGF0IGNvdmVycyB0aGUgdGVjaG5vbG9neSBpbiBtb3JlIGRldGFpbD8gIFRl Y2hub2xvZ3kgZG9jdW1lbnRzIG5lZWQgdG8gbW92ZSB0byBhIGRpZmZlcmVudCBXRy4gDQo+IA0K PiBJJ20gcmVhZGluZyB5b3VyIHN0YXRlbWVudCBhYm92ZSwgYW5kIGluIG90aGVyIGVtYWlsIHJl YWRpbmcgc3RhdGVtZW50cyBieSBzb21lb25lIHVzaW5nIHRoZSBzYW1lIGVtYWlsIGFkZHJlc3Mg dGhhdCBnbyBpbnRvIHNvbWUgZGV0YWlsIG9uIHRoZSBpbXBsaWNhdGlvbnMgb2YgYmluYXJ5IGZs YWdzIGluIG1lc3NhZ2VzLiBJJ20gd29uZGVyaW5nIHdoZXJlIHRoZSBsaW5lIGlzIGRyYXduIGFu ZCB3aHkgb25lIGRyYXdzIGl0Lg0KPiANCj4gSSBoYXZlIGFza2VkIGEgc2VsZWN0aW9uIG9mIEFE cyBhbmQgV0cgQ2hhaXJzIHRvIHdlaWdoIGluIG9uIHdoZXJlIHRoZSBkb2N1bWVudCBzaG91bGQg YmUgZGlzY3Vzc2VkOyBpZiBzb21lb25lIGNvbWVzIGJhY2sgdG8gSm9lbCBhbmQgSSB3aXRoICJ0 aGlzIG9idmlvdXNseSBiZWxvbmdzIGluIDw+Iiwgd2UnbGwgc2VuZCBpdCB0aGVyZSBvciBzZW5k IHRoZSByZWxldmFudCBzdWJzZXQgdGhlcmUuIFBlcnNvbmFsbHksIEkgdGhpbmsgaXQgZmFsbHMg d2l0aGluIHRoZSBjaGFydGVyIG9mIG9wZXJhdGlvbmFsIHByb2NlZHVyZXMgdXNlZCBpbiBJUHY2 IG5ldHdvcmtzLg0KPiANCj4gV2hlcmUgSSBkcmF3IHRoZSBsaW5lIG9uIHRoZSBub3JtYXRpdmUg cmVmZXJlbmNlIHRoYXQgT2xlIGFuZCBNYXJrIHdvdWxkIGxpa2UgaXMgaG93IHdlbGwgYmFrZWQg dGhlIHByb3Bvc2VkIHByb2NlZHVyZXMgYXJlLiBXZSB3aWxsIGRldGVybWluZSB0aGF0IE1vbmRh eS4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g djZvcHMgbWFpbGluZyBsaXN0DQo+IHY2b3BzQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMNCg== From mark@townsley.net Sat Mar 24 04:33:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5BE21F8705 for ; Sat, 24 Mar 2012 04:33:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 wMV29FcReifp for ; Sat, 24 Mar 2012 04:33:30 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id DB0E521F86FD for ; Sat, 24 Mar 2012 04:33:29 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so2356393wib.13 for ; Sat, 24 Mar 2012 04:33:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to:x-mailer:x-gm-message-state:content-type :content-transfer-encoding; bh=c9Ri25+SSnWOD/r9XqcdV2+Usg/xndBsKkBJvJcfYrU=; b=TVEqH0nq8SBMeWTAzY8baJP/HvhW+WLIBXhdxEYVwNNy0ruxohWyepLYJFM2PJF+Ne AkUMI/VVK4gQ6TNHHTTbcG1jbnryEUyqvUMl6NyjYylQD/pKc9wYYCQAsUXU+MHBXiv3 GuDnr6UyDC2O7BFfRqfTDtrdczUO21YKnZv6rOcmSjGdehnxc4psXI+EN76nOyqkGS9+ B/JqRjDx6spakswqW0XFHqSJ11LC8XO7YkSZFXzRd4dVIIWuJRCzNP1tpH7xxBs8ZKgA 2lDzdtWteiWOnY/YgHoyjPN1JvGAxtyU5jBdLte8dJbQwdgOh5WbECxqqtuzzUzMSJdR r3MQ== Received: by 10.180.14.103 with SMTP id o7mr1221617wic.7.1332588808933; Sat, 24 Mar 2012 04:33:28 -0700 (PDT) Received: from ams-townsley-8914.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id j3sm36498057wiw.1.2012.03.24.04.33.21 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 24 Mar 2012 04:33:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) From: Mark Townsley In-Reply-To: Date: Sat, 24 Mar 2012 12:33:19 +0100 Message-Id: References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30444B2D2@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30444B2E1@XMB-RCD-109.cisco.com> <3723BC44-931F-4852-88A4-716931770F85@cisco.com> To: "Ralph Droms (rdroms)" X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQnygQj+23QCBezf0EDwkF1d9jSpaECccM8o/Zu67TyabLjc9s6OI0r7cwBlgKJ2Fow4FRR1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 11:33:31 -0000 On Mar 24, 2012, at 12:26 PM, Ralph Droms (rdroms) wrote: > it's way too nice a day to give the issue the consideration it = deserves. =20 Enjoy Spring in Paris, Ralph. Wish I was :-) > So, I'll post a response, but likely not until tomorrow when I'll be = sequestered indoors most of the day, anyway. FWIW, it seem the chairs have given airtime for us to talk about this = Monday morning if you want to wait until you have heard the real-time = part of the discussion. - Mark >=20 > - Ralph >=20 > On Mar 24, 2012, at 12:17 PM, "Fred Baker" wrote: >=20 >>=20 >> On Mar 24, 2012, at 10:31 AM, Hemant Singh (shemant) wrote: >>=20 >>> Further, isn=92t draft-townsley-troan-ipv6-ce-transitioning-02 = specifying technology or is there another document that covers the = technology in more detail? Technology documents need to move to a = different WG.=20 >>=20 >> I'm reading your statement above, and in other email reading = statements by someone using the same email address that go into some = detail on the implications of binary flags in messages. I'm wondering = where the line is drawn and why one draws it. >>=20 >> I have asked a selection of ADs and WG Chairs to weigh in on where = the document should be discussed; if someone comes back to Joel and I = with "this obviously belongs in <>", we'll send it there or send the = relevant subset there. Personally, I think it falls within the charter = of operational procedures used in IPv6 networks. >>=20 >> Where I draw the line on the normative reference that Ole and Mark = would like is how well baked the proposed procedures are. We will = determine that Monday. >> _______________________________________________ >> v6ops mailing list >> v6ops@ietf.org >> https://www.ietf.org/mailman/listinfo/v6ops > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From rdroms@cisco.com Sat Mar 24 04:40:21 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7573321F8716 for ; Sat, 24 Mar 2012 04:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.449 X-Spam-Level: X-Spam-Status: No, score=-8.449 tagged_above=-999 required=5 tests=[AWL=-0.517, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 Nkf9V4NNRPVb for ; Sat, 24 Mar 2012 04:40:20 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0C621F870F for ; Sat, 24 Mar 2012 04:40:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rdroms@cisco.com; l=3026; q=dns/txt; s=iport; t=1332589220; x=1333798820; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=0iqvYXSb3TaWOXmJh7YsFF8q8xrv5pvq95nzObyonzQ=; b=LsTx8xvsduK6oR0rNLdLQovnAAggsDXU6zF78wjpp7VfxxIDys4JbIM9 SlEESdtNeGyrSCXfEfS+fVYGged9dEUHRhYSg7fb6Q4RLX4Ne2Hba34Iy K6UJbb877nCiKWUbrgZoe8bNd0ZvUHuZ2MJmYS7bDatFcv6MqBdc5F+iz w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsMJAISxbU+tJV2a/2dsb2JhbABEhT+xYX4CgQeCCQEBAQMBAQEBDwEQEToLEAIBCBgCAiYCAgIlMAEBBBMih2MFC5lVjQiRVwSBL45hNWMElWCORYFogmiBWw X-IronPort-AV: E=Sophos;i="4.73,641,1325462400"; d="scan'208";a="69096607" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 24 Mar 2012 11:40:20 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2OBeKZt001412; Sat, 24 Mar 2012 11:40:20 GMT Received: from xmb-rcd-202.cisco.com ([72.163.62.209]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 24 Mar 2012 06:40:19 -0500 Received: from 72.163.43.39 ([72.163.43.39]) by XMB-RCD-202.cisco.com ([72.163.62.209]) with Microsoft Exchange Server HTTP-DAV ; Sat, 24 Mar 2012 11:40:19 +0000 References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30444B2D2@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30444B2E1@XMB-RCD-109.cisco.com> <3723BC44-931F-4852-88A4-716931770F85@cisco.com> Content-Transfer-Encoding: base64 From: "Ralph Droms (rdroms)" Content-Type: text/plain; charset="utf-8" Thread-Topic: [v6ops] draft-ietf-v6ops-6204bis WGLC Thread-Index: Ac0JsuPR2glI91MtR1mRuqvCEr/a5g== In-Reply-To: Message-ID: <2131186D-4C82-418A-A359-C568F78CD19B@cisco.com> Date: Sat, 24 Mar 2012 12:40:13 +0100 To: "Mark Townsley" MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 24 Mar 2012 11:40:19.0748 (UTC) FILETIME=[E3FD7640:01CD09B2] Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 11:40:21 -0000 DQoNCg0KDQpPbiBNYXIgMjQsIDIwMTIsIGF0IDEyOjMzIFBNLCAiTWFyayBUb3duc2xleSIgPG1h cmtAdG93bnNsZXkubmV0PiB3cm90ZToNCg0KPiANCj4gT24gTWFyIDI0LCAyMDEyLCBhdCAxMjoy NiBQTSwgUmFscGggRHJvbXMgKHJkcm9tcykgd3JvdGU6DQo+IA0KPj4gaXQncyB3YXkgdG9vIG5p Y2UgYSBkYXkgdG8gZ2l2ZSB0aGUgaXNzdWUgdGhlIGNvbnNpZGVyYXRpb24gaXQgZGVzZXJ2ZXMu ICAgDQo+IA0KPiBFbmpveSBTcHJpbmcgaW4gUGFyaXMsIFJhbHBoLiBXaXNoIEkgd2FzIDotKQ0K DQpUaGUgd2VhdGhlciBpcyBhIGxpdHRsZSBiZXR0ZXIgdGhhbiB3aGVuIEkgd2FzIGhlcmUgZm9y IHRoZSBJUHY2IFdvcmxkIENvbmdyZXNzLi4uDQoNCj4gDQo+PiBTbywgSSdsbCBwb3N0IGEgcmVz cG9uc2UsIGJ1dCBsaWtlbHkgbm90IHVudGlsIHRvbW9ycm93IHdoZW4gSSdsbCBiZSBzZXF1ZXN0 ZXJlZCBpbmRvb3JzIG1vc3Qgb2YgdGhlIGRheSwgYW55d2F5Lg0KPiANCj4gRldJVywgaXQgc2Vl bSB0aGUgY2hhaXJzIGhhdmUgZ2l2ZW4gYWlydGltZSBmb3IgdXMgdG8gdGFsayBhYm91dCB0aGlz IE1vbmRheSBtb3JuaW5nIGlmIHlvdSB3YW50IHRvIHdhaXQgdW50aWwgeW91IGhhdmUgaGVhcmQg dGhlIHJlYWwtdGltZSBwYXJ0IG9mIHRoZSBkaXNjdXNzaW9uLg0KDQpXaHkgZG8gSSBuZWVkIHRv IGhlYXIgYWxsIHRoZSBkYXRhIGJlZm9yZSBnaXZpbmcgYW4gb3Bpbmlvbj8NCg0KLSBSYWxwaA0K DQo+IA0KPiAtIE1hcmsNCj4gDQo+IA0KPj4gDQo+PiAtIFJhbHBoDQo+PiANCj4+IE9uIE1hciAy NCwgMjAxMiwgYXQgMTI6MTcgUE0sICJGcmVkIEJha2VyIiA8ZnJlZEBjaXNjby5jb20+IHdyb3Rl Og0KPj4gDQo+Pj4gDQo+Pj4gT24gTWFyIDI0LCAyMDEyLCBhdCAxMDozMSBBTSwgSGVtYW50IFNp bmdoIChzaGVtYW50KSB3cm90ZToNCj4+PiANCj4+Pj4gRnVydGhlciwgaXNu4oCZdCBkcmFmdC10 b3duc2xleS10cm9hbi1pcHY2LWNlLXRyYW5zaXRpb25pbmctMDIgc3BlY2lmeWluZyB0ZWNobm9s b2d5IG9yIGlzIHRoZXJlIGFub3RoZXIgZG9jdW1lbnQgdGhhdCBjb3ZlcnMgdGhlIHRlY2hub2xv Z3kgaW4gbW9yZSBkZXRhaWw/ICBUZWNobm9sb2d5IGRvY3VtZW50cyBuZWVkIHRvIG1vdmUgdG8g YSBkaWZmZXJlbnQgV0cuIA0KPj4+IA0KPj4+IEknbSByZWFkaW5nIHlvdXIgc3RhdGVtZW50IGFi b3ZlLCBhbmQgaW4gb3RoZXIgZW1haWwgcmVhZGluZyBzdGF0ZW1lbnRzIGJ5IHNvbWVvbmUgdXNp bmcgdGhlIHNhbWUgZW1haWwgYWRkcmVzcyB0aGF0IGdvIGludG8gc29tZSBkZXRhaWwgb24gdGhl IGltcGxpY2F0aW9ucyBvZiBiaW5hcnkgZmxhZ3MgaW4gbWVzc2FnZXMuIEknbSB3b25kZXJpbmcg d2hlcmUgdGhlIGxpbmUgaXMgZHJhd24gYW5kIHdoeSBvbmUgZHJhd3MgaXQuDQo+Pj4gDQo+Pj4g SSBoYXZlIGFza2VkIGEgc2VsZWN0aW9uIG9mIEFEcyBhbmQgV0cgQ2hhaXJzIHRvIHdlaWdoIGlu IG9uIHdoZXJlIHRoZSBkb2N1bWVudCBzaG91bGQgYmUgZGlzY3Vzc2VkOyBpZiBzb21lb25lIGNv bWVzIGJhY2sgdG8gSm9lbCBhbmQgSSB3aXRoICJ0aGlzIG9idmlvdXNseSBiZWxvbmdzIGluIDw+ Iiwgd2UnbGwgc2VuZCBpdCB0aGVyZSBvciBzZW5kIHRoZSByZWxldmFudCBzdWJzZXQgdGhlcmUu IFBlcnNvbmFsbHksIEkgdGhpbmsgaXQgZmFsbHMgd2l0aGluIHRoZSBjaGFydGVyIG9mIG9wZXJh dGlvbmFsIHByb2NlZHVyZXMgdXNlZCBpbiBJUHY2IG5ldHdvcmtzLg0KPj4+IA0KPj4+IFdoZXJl IEkgZHJhdyB0aGUgbGluZSBvbiB0aGUgbm9ybWF0aXZlIHJlZmVyZW5jZSB0aGF0IE9sZSBhbmQg TWFyayB3b3VsZCBsaWtlIGlzIGhvdyB3ZWxsIGJha2VkIHRoZSBwcm9wb3NlZCBwcm9jZWR1cmVz IGFyZS4gV2Ugd2lsbCBkZXRlcm1pbmUgdGhhdCBNb25kYXkuDQo+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiB2Nm9wcyBtYWlsaW5nIGxpc3QN Cj4+PiB2Nm9wc0BpZXRmLm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdjZvcHMNCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+PiB2Nm9wcyBtYWlsaW5nIGxpc3QNCj4+IHY2b3BzQGlldGYub3JnDQo+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo+IA0K From mark@townsley.net Sat Mar 24 04:53:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE75221F8714 for ; Sat, 24 Mar 2012 04:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.906 X-Spam-Level: X-Spam-Status: No, score=-2.906 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 oG0C3UiY+qLI for ; Sat, 24 Mar 2012 04:53:09 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 43B7D21F8700 for ; Sat, 24 Mar 2012 04:53:04 -0700 (PDT) Received: by werb10 with SMTP id b10so3862975wer.31 for ; Sat, 24 Mar 2012 04:53:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=DfJ7suMBQpkPXSBay+b0mXe876Wl6BUNpZxHK5zCPbQ=; b=GiLYdoC1QZJtAqgkLKZYeK6PKn64nJI648kP6JyloPVOCLXlk9RkN2eJRlQNX037qR N5IqtqllYP3IcqLV1djDHpQRAfhXUrwZZEoQkaMnInAsY4ZKCNRG/hbSgzeHsvPTX3sK PiLwb9glWdVEN8TE6ykYFTC3TokVA4/APZyjn2uJzcRTS9stiZLZKTGXnftGrlNd209u UbOzwSYQoRBM9xhOBJrUndkAyiqUN1mXIksXugKEMBh2pPMEGs+pv2vZ6bHHalUwe3wo 1Be9TtiGnc3rUYjyc4Mbny77JHrNyp1RJiGzfi4QejRlUwAAhn4wPxtFvvpjnueAym/G YVRA== Received: by 10.180.106.9 with SMTP id gq9mr4453224wib.17.1332589983098; Sat, 24 Mar 2012 04:53:03 -0700 (PDT) Received: from ams-townsley-8914.cisco.com (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id ff2sm36615652wib.9.2012.03.24.04.52.55 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 24 Mar 2012 04:53:02 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Mark Townsley In-Reply-To: <2131186D-4C82-418A-A359-C568F78CD19B@cisco.com> Date: Sat, 24 Mar 2012 12:52:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6A0BFABB-225C-4D14-83F5-4398AF0E5CC3@cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30444B2D2@XMB-RCD-109.cisco.com> <5B6B2B64C9FE2A489045EEEADDAFF2C30444B2E1@XMB-RCD-109.cisco.com> <3723BC44-931F-4852-88A4-716931770F85@cisco.com> <2131186D-4C82-418A-A359-C568F78CD19B@cisco.com> To: "Ralph Droms (rdroms)" X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQmOs3rC1i8xP1KsR76o79ub119kQVZ9ktLNtDqdotTZDrLGElJ3R8XAlv83318rgsJf7mPr Cc: v6ops@ietf.org, v6ops-chairs@tools.ietf.org, Ron Bonica Subject: Re: [v6ops] draft-ietf-v6ops-6204bis WGLC X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 11:53:11 -0000 On Mar 24, 2012, at 12:40 PM, Ralph Droms (rdroms) wrote: >=20 >=20 >=20 >=20 > On Mar 24, 2012, at 12:33 PM, "Mark Townsley" = wrote: >=20 >>=20 >> On Mar 24, 2012, at 12:26 PM, Ralph Droms (rdroms) wrote: >>=20 >>> it's way too nice a day to give the issue the consideration it = deserves. =20 >>=20 >> Enjoy Spring in Paris, Ralph. Wish I was :-) >=20 > The weather is a little better than when I was here for the IPv6 World = Congress=85 Yes, that was embarrassing. We're trying to make up for it.=20 >=20 >>=20 >>> So, I'll post a response, but likely not until tomorrow when I'll be = sequestered indoors most of the day, anyway. >>=20 >> FWIW, it seem the chairs have given airtime for us to talk about this = Monday morning if you want to wait until you have heard the real-time = part of the discussion. >=20 > Why do I need to hear all the data before giving an opinion? No comment. - Mark >=20 > - Ralph >=20 >>=20 >> - Mark >>=20 >>=20 >>>=20 >>> - Ralph >>>=20 >>> On Mar 24, 2012, at 12:17 PM, "Fred Baker" wrote: >>>=20 >>>>=20 >>>> On Mar 24, 2012, at 10:31 AM, Hemant Singh (shemant) wrote: >>>>=20 >>>>> Further, isn=92t draft-townsley-troan-ipv6-ce-transitioning-02 = specifying technology or is there another document that covers the = technology in more detail? Technology documents need to move to a = different WG.=20 >>>>=20 >>>> I'm reading your statement above, and in other email reading = statements by someone using the same email address that go into some = detail on the implications of binary flags in messages. I'm wondering = where the line is drawn and why one draws it. >>>>=20 >>>> I have asked a selection of ADs and WG Chairs to weigh in on where = the document should be discussed; if someone comes back to Joel and I = with "this obviously belongs in <>", we'll send it there or send the = relevant subset there. Personally, I think it falls within the charter = of operational procedures used in IPv6 networks. >>>>=20 >>>> Where I draw the line on the normative reference that Ole and Mark = would like is how well baked the proposed procedures are. We will = determine that Monday. >>>> _______________________________________________ >>>> v6ops mailing list >>>> v6ops@ietf.org >>>> https://www.ietf.org/mailman/listinfo/v6ops >>> _______________________________________________ >>> v6ops mailing list >>> v6ops@ietf.org >>> https://www.ietf.org/mailman/listinfo/v6ops >>=20 From wesley.george@twcable.com Sat Mar 24 05:58:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C9E21F8700 for ; Sat, 24 Mar 2012 05:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.098 X-Spam-Level: X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5 tests=[AWL=0.365, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 xL+o0E+hw+KB for ; Sat, 24 Mar 2012 05:58:22 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 0EAD021F86DD for ; Sat, 24 Mar 2012 05:58:21 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.73,641,1325480400"; d="scan'208";a="358397234" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 24 Mar 2012 08:57:30 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Sat, 24 Mar 2012 08:58:21 -0400 From: "George, Wes" To: Cameron Byrne Date: Sat, 24 Mar 2012 08:58:20 -0400 Thread-Topic: [v6ops] Nomative language in draft-ietf-v6ops-464xlat-00 Thread-Index: Acz8d2ryVWgdJs3WRqC/Auhv1XMPXQNEacTA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Ops WG Subject: Re: [v6ops] Nomative language in draft-ietf-v6ops-464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 12:58:23 -0000 I've read and support this draft. One comment after having read the draft a= nd this thread: Currently in 6.1 the draft says "The format is defined in Section 2.2 of [RFC6052]. However, 464XLAT does not use the Well- Known IPv6 Prefix "64:ff9b::/96"." However, it does not explicitly explain why it does not use the WKP, and un= less I'm being thick (which is entirely possible), the discussion you've ha= d with Woj does not either. I assume that there's a valid reason, which sho= uld be explained following that statement. Thanks, Wes > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Cameron Byrne > > > What more it contains specific text in Section 6.1 like > > > > " > > > > IPv6 address format in 464XLAT is presented in the following format. > > > > +-----------------------------------------------+---------------= + > > | XLAT prefix(96) | IPv4(32) = | > > +-----------------------------------------------+---------------= + > > > > Source address and destination address have IPv4 address embedded in th= e > > low-order 32 bits of the IPv6 address. " > > This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From wesley.george@twcable.com Sat Mar 24 05:58:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0150021F8705 for ; Sat, 24 Mar 2012 05:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.104 X-Spam-Level: X-Spam-Status: No, score=-1.104 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, 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 7WqkC72Kvizd for ; Sat, 24 Mar 2012 05:58:22 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 8173521F86E0 for ; Sat, 24 Mar 2012 05:58:22 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.73,641,1325480400"; d="scan'208";a="358397235" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 24 Mar 2012 08:57:31 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Sat, 24 Mar 2012 08:58:22 -0400 From: "George, Wes" To: GangChen , "v6ops@ietf.org" Date: Sat, 24 Mar 2012 08:58:21 -0400 Thread-Topic: [v6ops] I-D Action: draft-chen-v6ops-nat64-experience-00.txt Thread-Index: Ac0AxUhZMomnCVswR2+0oYS47gpI0gIxedBw Message-ID: References: <11ECC355-6FAC-4D69-A615-AB43F2180CEE@laposte.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] I-D Action: draft-chen-v6ops-nat64-experience-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 12:58:24 -0000 Some additional comments on this new version Section 2.3 - This only briefly mentions logging translation events and off= line traceability. The amount of logging data generated by other NAT implem= entations such as NAT444 is potentially onerous. It would be helpful to dis= cuss whether this shares a similar concern, and characterize the amount of = logging generated in typical usage by comparison, whether optimizations are= possible similar to draft-donley-behave-deterministic-cgn to reduce the lo= gging, etc. Also in this same section, I disagree with the statements " Lawful intercep= t[RFC3924] is normally part of the access network, in which an optical splitter is used to bypass all traffic for subsequent filtering process." And "even if that may not a major case in current practices" Optical split is actually a fairly uncommon method to do LI in most broadba= nd access networks, and is also not really the method defined in 3924. I do= n't think that the second half of this phrase (the part talking about optic= al splits and whether LI of one sort or another is common) is actually addi= ng much to the discussion, and it should probably just be removed. That sai= d, you assert that LI is easily added, and I think that it would be better = to expand on that, either with a reference to where this is discussed in de= tail elsewhere, or additional text to explain how. Thanks, Wes George > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > GangChen > Sent: Monday, March 12, 2012 10:59 PM > To: v6ops@ietf.org > Subject: Re: [v6ops] I-D Action: draft-chen-v6ops-nat64-experience-00.txt > > Hello all, > > Replying the comments received on the list, we updated the draft and > published -01 for NAT64 experiences. Please check the side-by-side > diff as below > > http://tools.ietf.org/rfcdiff?url1=3Ddraft-chen-v6ops-nat64-experience- > 00&difftype=3D--html&submit=3DGo%21&url2=3Ddraft-chen-v6ops-nat64-experie= nce-01 > > Your further comments are appreciated > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : NAT64 Operational Experiences > Author(s) : Gang Chen > Zhen Cao > Cameron Byrne > QiBo Niu > Filename : draft-chen-v6ops-nat64-experience-01.txt > Pages : 11 > Date : 2012-03-12 > > This document summarizes some stateful NAT64 deployment scenarios and > operational experiences for NAT64-CGN and NAT64-CE. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-experience-01.= txt > > > BRs > > Gang > > This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From wesley.george@twcable.com Sat Mar 24 05:58:25 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2DF21F8705 for ; Sat, 24 Mar 2012 05:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[AWL=-0.747, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=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 hpH+LfB+AoM9 for ; Sat, 24 Mar 2012 05:58:24 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id EE23221F86E4 for ; Sat, 24 Mar 2012 05:58:23 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.73,641,1325480400"; d="scan'208";a="341973940" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 24 Mar 2012 08:57:50 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Sat, 24 Mar 2012 08:58:23 -0400 From: "George, Wes" To: Brian E Carpenter , IPv6 Operations Date: Sat, 24 Mar 2012 08:58:22 -0400 Thread-Topic: [v6ops] draft-liu-v6ops-ula-usage-analysis-02 Thread-Index: Ac0Io7UnaAoC/T3bTQOsdWYg0oW4MAA6mNjA Message-ID: References: <4F6BEB95.60608@gmail.com> In-Reply-To: <4F6BEB95.60608@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [v6ops] draft-liu-v6ops-ula-usage-analysis-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 12:58:25 -0000 A comment of my own: 3.1, Regarding: "Generally, this draft doesn't consider the ULA+NAT a good = model of IPv6 deployment in normal cases. When thinking about ULA, we should eliminate the misunderstanding that ULA means the IPv6 version of rfc1918 deployment model." I would clarify this by saying "...the IPv6 version of using RFC1918 + NAT = [with RFC reference for NAT44/NAPT] as a means to provide hosts with privat= e addresses with a means of accessing hosts beyond the local network." Strictly speaking, the RFC1918 deployment model as defined in 1918 itself d= oes not include NAT, and is actually a reasonable equivalent to ULA. You could probably even go on to discuss the fact that since it will be com= mon to have hosts with multiple IPv6 addresses, the expected solution for c= ases where hosts with ULA need to interact with hosts beyond the ULA scope = is to provide them with a global-scope address in addition to any ULA. Thanks, Wes George > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > Brian E Carpenter > Sent: Thursday, March 22, 2012 11:19 PM > To: IPv6 Operations > Subject: [v6ops] draft-liu-v6ops-ula-usage-analysis-02 > > Hi, > > I think this draft is a considerable improvement on the -00 version. > It still needs some work on the English, but I think the main points > are covered now and the work should continue. > > However, there is clearly a complication, which is that this document > needs to be aligned with whatever consensus appears in homenet about > ULAs, and with whatever consensus appears in 6man about RFC3484bis. > > In particular, homenet is hitting the problem of what happens when > multiple ULA prefixes show up automatically in the same network. That > may not be recommended practice, but it seems very likely to happen, > and raises routing and address-selection questions. > > I think the various WG Chairs need to agree how the discussion should > be managed, because it might get complicated with three WGs involved > (or four, if you count 6renum). > > Regards > Brian > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From wesley.george@twcable.com Sat Mar 24 05:58:28 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2B821F872D for ; Sat, 24 Mar 2012 05:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.86 X-Spam-Level: X-Spam-Status: No, score=0.86 tagged_above=-999 required=5 tests=[AWL=-1.593, BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315] 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 y4eC5w5vSRVk for ; Sat, 24 Mar 2012 05:58:25 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id A1D4821F8718 for ; Sat, 24 Mar 2012 05:58:24 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.73,641,1325480400"; d="scan'208,217";a="341973941" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 24 Mar 2012 08:57:51 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Sat, 24 Mar 2012 08:58:24 -0400 From: "George, Wes" To: Sri Gundavelli , "v6ops@ietf.org" Date: Sat, 24 Mar 2012 08:58:23 -0400 Thread-Topic: [v6ops] Comments on draft-gundavelli-v6ops-community-wifi-svcs-03 Thread-Index: Ac0HzJ/WhR/2gF+/REWfL3S+CCuhkwByeDtA Message-ID: References: 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_DCC302FAA9FE5F4BBA4DCAD465693779173D27621DPRVPEXVS03cor_" MIME-Version: 1.0 Subject: Re: [v6ops] Comments on draft-gundavelli-v6ops-community-wifi-svcs-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 12:58:28 -0000 --_000_DCC302FAA9FE5F4BBA4DCAD465693779173D27621DPRVPEXVS03cor_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of S= ri Gundavelli Sent: Wednesday, March 21, 2012 9:40 PM To: Hui Deng; v6ops@ietf.org Subject: Re: [v6ops] Comments on draft-gundavelli-v6ops-community-wifi-svcs= -03 how many million hotspots you guys have deployed last year ? The spec tries= to identify what it takes to enable that service, the protocol choice, mob= ility considerations, IPv6 transitioning and other aspects. We are still wo= rking on additional updates, that should complete all the IPv6 consideratio= ns. [WEG] Allow me to provide some more specific feedback about what's missing = in terms of IPv6 considerations. A deployment of this type MUST be planning for IPv6 on day one, and we'd be= doing a disservice to not explicitly state that so that those using this a= s a guide include this in their requirements to their vendors. When you are deploying "millions of hotspots" you had better be prepared to= manage them via IPv6... ONLY. By manage, I mean everything from remote con= figuration, OSS/polling, software management, etc. This also extends to if you are using something like GRE or L2TP tunneling = to carry traffic from an AP back to a wifi core to manage mobility and othe= r things -- that tunneling MUST be done over IPv6. These deployments are si= mply too large and there are already too many overlapping uses of 1918 spac= e for it to be realistic to think that it will be possible to give these AP= s even one IPv4 address for those uses. This consideration will seem very f= amiliar to those of us who have been on the wrong end of a discussion invol= ving trying to make 50K cell towers IP-reachable, and stunned to find out t= hat key pieces of equipment and software say, "huh? What's IPv6?" And of course, it MUST be able to carry IPv6 data from end hosts (the actua= l users). While Wifi is a layer 2 protocol, there are enough interactions b= etween Layer 2 and 3 that IPv6 support should be explicitly indicated. I've= been personally burned by this in such a way as to not want to simply assu= me that it'll just work because wifi vendors will be smart enough to do the= right thing. Naturally, if you'd like to be backwards compatible, you SHOULD support IPv= 4 for all of the above, but you MUST support IPv6 and you MUST NOT require = IPv4 for proper and complete function. RFC6540 (in AUTH48) says more or les= s exactly this. You're welcome to cite it :-) Thanks, Wes George ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. --_000_DCC302FAA9FE5F4BBA4DCAD465693779173D27621DPRVPEXVS03cor_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [v6ops] Comments on draft-gundavelli-v6ops-community-wifi-svcs-0= 3

From: v6ops-bo= unces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Sri Gundavelli
Sent: Wednesday, March 21, 2012 9:40 PM
To: Hui Deng; v6ops@ietf.org
Subject: Re: [v6ops] Comments on draft-gundavelli-v6ops-community-wi= fi-svcs-03

 

how many million hotspots you guys have deployed last year ? T= he spec tries to identify what it takes to enable that service, the protoco= l choice, mobility considerations, IPv6 transitioning and other aspects. We are still working on additional updates, that should= complete all the IPv6 considerations.

[WEG] Allow me to provide some more specific feed= back about what’s missing in terms of IPv6 considerations.=

 

A deployment of this type MUST be planning for IP= v6 on day one, and we’d be doing a disservice to not explicitly state= that so that those using this as a guide include this in their requirement= s to their vendors.

 

When you are deploying "millions of hotspots= " you had better be prepared to manage them via IPv6... ONLY. By manag= e, I mean everything from remote configuration, OSS/polling, software manag= ement, etc.

This also extends to if you are using something l= ike GRE or L2TP tunneling to carry traffic from an AP back to a wifi core t= o manage mobility and other things -- that tunneling MUST be done over IPv6= . These deployments are simply too large and there are already too many overlapping uses of 1918 space for it= to be realistic to think that it will be possible to give these APs even o= ne IPv4 address for those uses. This consideration will seem very familiar = to those of us who have been on the wrong end of a discussion involving trying to make 50K cell towers IP-= reachable, and stunned to find out that key pieces of equipment and softwar= e say, “huh? What’s IPv6?”

 

And of course, it MUST be able to carry IPv6 data= from end hosts (the actual users). While Wifi is a layer 2 protocol, there= are enough interactions between Layer 2 and 3 that IPv6 support should be = explicitly indicated. I've been personally burned by this in such a way as to not want to simply assume that it'll ju= st work because wifi vendors will be smart enough to do the right thing.

 

Naturally, if you'd like to be backwards compatib= le, you SHOULD support IPv4 for all of the above, but you MUST support IPv6= and you MUST NOT require IPv4 for proper and complete function. RFC6540 (i= n AUTH48) says more or less exactly this. You're welcome to cite it :-)

 

Thanks,

Wes George


This E-mail and any of its a= ttachments may contain Time Warner Cable proprietary information, which is = privileged, confidential, or subject to copyright belonging to Time Warner = Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you a= re not the intended recipient of this E-mail, you are hereby notified that = any dissemination, distribution, copying, or action taken in relation to th= e contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have receiv= ed this E-mail in error, please notify the sender immediately and permanent= ly delete the original and any copy of this E-mail and any printout.
 --_000_DCC302FAA9FE5F4BBA4DCAD465693779173D27621DPRVPEXVS03cor_-- From cb.list6@gmail.com Sat Mar 24 07:28:37 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E9F21F8729 for ; Sat, 24 Mar 2012 07:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.464 X-Spam-Level: X-Spam-Status: No, score=-3.464 tagged_above=-999 required=5 tests=[AWL=0.134, 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 42FeI76EK5pi for ; Sat, 24 Mar 2012 07:28:34 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 58F4C21F8725 for ; Sat, 24 Mar 2012 07:28:34 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so3841634pbb.31 for ; Sat, 24 Mar 2012 07:28:34 -0700 (PDT) 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=yEHotcxCBI7LMxlj/5URMkQh6EIHZ9A7EEzMXb8GFbE=; b=g7DSZEnycM1g7jM2UYuw5kFzV2AJB2sBu2C3XWjI1K9FUZXDJvVAIMoTZUqqhKVve0 V7i2KRl2IZ37+WpUIdubugvdtVrE8dzNlF1ht5I1LPlCv9JBEoN4N3sxFtRKeTkTJYcH jaV/I4hG2IOydnEh1NKFU7DjfyeaGRhUb0VMFeOyyszn1CDmp0QCdtzEzc7f0fRb0Dt5 4Mfma+ELGgWff1vXh9K6LY6VPxQfl04TAlWKKdaS9MwDVqrSibhz4uzblzwANNnXBO3n 9oAiudQa3KZp9TAvuqR7kpGXeKgAuOPKoXy5DWUQyqVSSU9q827p2h+LgXf7WlD1LGtM QjnQ== MIME-Version: 1.0 Received: by 10.68.220.39 with SMTP id pt7mr869426pbc.166.1332599314025; Sat, 24 Mar 2012 07:28:34 -0700 (PDT) Received: by 10.143.160.13 with HTTP; Sat, 24 Mar 2012 07:28:33 -0700 (PDT) Received: by 10.143.160.13 with HTTP; Sat, 24 Mar 2012 07:28:33 -0700 (PDT) In-Reply-To: References: Date: Sat, 24 Mar 2012 07:28:33 -0700 Message-ID: From: Cameron Byrne To: "George, Wes" Content-Type: multipart/alternative; boundary=e89a8ff249d5bd8bc704bbfdf4ab Cc: IPv6 Ops WG Subject: Re: [v6ops] Nomative language in draft-ietf-v6ops-464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 14:28:37 -0000 --e89a8ff249d5bd8bc704bbfdf4ab Content-Type: text/plain; charset=ISO-8859-1 On Mar 24, 2012 5:58 AM, "George, Wes" wrote: > > I've read and support this draft. One comment after having read the draft and this thread: Thanks for the support > Currently in 6.1 the draft says "The format is defined in > Section 2.2 of [RFC6052]. However, 464XLAT does not use the Well- > Known IPv6 Prefix "64:ff9b::/96"." > > However, it does not explicitly explain why it does not use the WKP, and unless I'm being thick (which is entirely possible), the discussion you've had with Woj does not either. I assume that there's a valid reason, which should be explained following that statement. > Wkp constrains the architecture too much. Wkp does not work well at large scale where it is desired to specifically traffic engineer load using unique NSP to load and unload a given PLAT. One could anycast the wkp, but anycast clashes with stateful behavior at the PLAT... I'd rather not tightly couple PLAT load with routing topology. In the case where the PLAT is located in a different administrative domain, wkp is not possible .... as where NSP may be carried even in the DFZ to allow CLAT on the internet to communicate with internet hosted PLATs We can boil the above down to a sentence and add it to the draft to increase clarity. Thanks again for the review and support. Cb > Thanks, > > Wes > > > > > -----Original Message----- > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of > > Cameron Byrne > > > > > What more it contains specific text in Section 6.1 like > > > > > > " > > > > > > IPv6 address format in 464XLAT is presented in the following format. > > > > > > +-----------------------------------------------+---------------+ > > > | XLAT prefix(96) | IPv4(32) | > > > +-----------------------------------------------+---------------+ > > > > > > Source address and destination address have IPv4 address embedded in the > > > low-order 32 bits of the IPv6 address. " > > > > > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. On Mar 24, 2012 5:58 AM, "George, Wes" wrote: > I've read and support this draft. One comment after having read the draft > and this thread: > Currently in 6.1 the draft says "The format is defined in > Section 2.2 of [RFC6052]. However, 464XLAT does not use the Well- > Known IPv6 Prefix "64:ff9b::/96"." > > However, it does not explicitly explain why it does not use the WKP, and > unless I'm being thick (which is entirely possible), the discussion you've > had with Woj does not either. I assume that there's a valid reason, which > should be explained following that statement. > > Thanks, > > Wes > > > > > -----Original Message----- > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of > > Cameron Byrne > > > > > What more it contains specific text in Section 6.1 like > > > > > > " > > > > > > IPv6 address format in 464XLAT is presented in the following format. > > > > > > > +-----------------------------------------------+---------------+ > > > | XLAT prefix(96) | IPv4(32) > | > > > > +-----------------------------------------------+---------------+ > > > > > > Source address and destination address have IPv4 address embedded in > the > > > low-order 32 bits of the IPv6 address. " > > > > > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely > for the use of the individual or entity to which it is addressed. If you > are not the intended recipient of this E-mail, you are hereby notified that > any dissemination, distribution, copying, or action taken in relation to > the contents of and attachments to this E-mail is strictly prohibited and > may be unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any copy of > this E-mail and any printout. > --e89a8ff249d5bd8bc704bbfdf4ab Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mar 24, 2012 5:58 AM, "George, Wes" <wesley.george@twcable.com> wrote:
>
> I've read and support this draft. One comment after having read th= e draft and this thread:

Thanks for the support

> Currently in 6.1 the draft says "The format is defined in
> =A0 Section 2.2 of [RFC6052]. =A0However, 464XLAT does not use the Wel= l-
> =A0 Known IPv6 Prefix "64:ff9b::/96"."
>
> However, it does not explicitly explain why it does not use the WKP, a= nd unless I'm being thick (which is entirely possible), the discussion = you've had with Woj does not either. I assume that there's a valid = reason, which should be explained following that statement.
>

Wkp constrains the architecture too much.

Wkp does not work well at large scale where it is desired to specificall= y traffic engineer load=A0 using unique NSP to load and unload a given PLAT= .

One could anycast the wkp, but anycast clashes with stateful behavior at= the PLAT... I'd rather not tightly couple PLAT load with routing topol= ogy.

In the case where the PLAT is located in a different administrative doma= in, wkp is not possible .... as where NSP may be carried even in the DFZ to= allow CLAT on the internet to communicate with internet hosted PLATs

We can boil the above down to a sentence and add it to the draft to incr= ease clarity.

Thanks again for the review and support.

Cb

> Thanks,
>
> Wes
>
>
>
> > -----Original Message-----
> > From: v6ops-bounces@iet= f.org [mailto:v6ops-bounces@i= etf.org] On Behalf Of
> > Cameron Byrne
> >
> > > What more it contains specific text in Section 6.1 like
> > >
> > > "
> > >
> > > IPv6 address format in 464XLAT is presented in the following= format.
> > >
> > > =A0 =A0 =A0 =A0+--------------------------------------------= ---+---------------+
> > > =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0XLAT prefix(96) = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0IPv4(32) =A0 |
> > > =A0 =A0 =A0 =A0+--------------------------------------------= ---+---------------+
> > >
> > > Source address and destination address have IPv4 address emb= edded in the
> > > low-order 32 bits of the IPv6 address. "
> > >
>
>
> This E-mail and any of its attachments may contain Time Warner Cable p= roprietary information, which is privileged, confidential, or subject to co= pyright belonging to Time Warner Cable. This E-mail is intended solely for = the use of the individual or entity to which it is addressed. If you are no= t the intended recipient of this E-mail, you are hereby notified that any d= issemination, distribution, copying, or action taken in relation to the con= tents of and attachments to this E-mail is strictly prohibited and may be u= nlawful. If you have received this E-mail in error, please notify the sende= r immediately and permanently delete the original and any copy of this E-ma= il and any printout.

On Mar 24, 2012 5:58 AM, "George, Wes"= <wesley.george@twcable.com= > wrote:
I've read and support this draft. One comment after having read the dra= ft and this thread:
Currently in 6.1 the draft says "The format is defined in
=A0 Section 2.2 of [RFC6052]. =A0However, 464XLAT does not use the Well- =A0 Known IPv6 Prefix "64:ff9b::/96"."

However, it does not explicitly explain why it does not use the WKP, and un= less I'm being thick (which is entirely possible), the discussion you&#= 39;ve had with Woj does not either. I assume that there's a valid reaso= n, which should be explained following that statement.

Thanks,

Wes



> -----Original Message-----
> From: v6ops-bounces@ietf.org= [mailto:v6ops-bounces@ietf.o= rg] On Behalf Of
> Cameron Byrne
>
> > What more it contains specific text in Section 6.1 like
> >
> > "
> >
> > IPv6 address format in 464XLAT is presented in the following form= at.
> >
> > =A0 =A0 =A0 =A0+-----------------------------------------------+-= --------------+
> > =A0 =A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0 =A0 =A0XLAT prefix(96) =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0IPv4(32) =A0 |
> > =A0 =A0 =A0 =A0+-----------------------------------------------+-= --------------+
> >
> > Source address and destination address have IPv4 address embedded= in the
> > low-order 32 bits of the IPv6 address. "
> >


This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout.
--e89a8ff249d5bd8bc704bbfdf4ab-- From cb.list6@gmail.com Sat Mar 24 07:35:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1824B21F86B2 for ; Sat, 24 Mar 2012 07:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.008 X-Spam-Level: X-Spam-Status: No, score=-3.008 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 WZM-zFGTtMK1 for ; Sat, 24 Mar 2012 07:35:53 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2CE6D21F8675 for ; Sat, 24 Mar 2012 07:35:53 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so3847154pbb.31 for ; Sat, 24 Mar 2012 07:35:53 -0700 (PDT) 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=HKM75qFOjCofIcW/H3kZDfvaWRwrZPMSnUCAXOzAPis=; b=0MW2th4qJYo+a+8W7BO10uB8i37AlDNiXNFGuFJPtSIecpFmguu67U3twbCfzwo714 nHMSJljRIO/Hdih1TNrGAVNCqLJIkJqIn2HI/KGiftC+/hsNw+gTs4h0a/PREKyERQX8 fBLVLyc29JQZy68Vu76OWf3doG/24+GPzeL7Wry9GaGvRbY3qKnQaqHTrmNQsqA3oa6K eC4ZULRxCVe84cRAtj/LrQ167n/nnEkuQl1lz6T+Mdm5GChsyQxtYxj6UiHpR5hsG342 nej5th5zsGbL31sOs4uC3DrmSNp42Lonsf2CzvoY9QMfWdixsxUdgJLTe9K86JuKWRwP NzqQ== MIME-Version: 1.0 Received: by 10.68.136.162 with SMTP id qb2mr38552976pbb.67.1332599753012; Sat, 24 Mar 2012 07:35:53 -0700 (PDT) Received: by 10.143.160.13 with HTTP; Sat, 24 Mar 2012 07:35:52 -0700 (PDT) Received: by 10.143.160.13 with HTTP; Sat, 24 Mar 2012 07:35:52 -0700 (PDT) In-Reply-To: References: Date: Sat, 24 Mar 2012 07:35:52 -0700 Message-ID: From: Cameron Byrne To: "George, Wes" Content-Type: multipart/alternative; boundary=047d7b10cfefe7f57b04bbfe0eab Cc: "v6ops@ietf.org" Subject: Re: [v6ops] Comments on draft-gundavelli-v6ops-community-wifi-svcs-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 14:35:54 -0000 --047d7b10cfefe7f57b04bbfe0eab Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Mar 24, 2012 5:59 AM, "George, Wes" wrote: > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Sri Gundavelli > Sent: Wednesday, March 21, 2012 9:40 PM > To: Hui Deng; v6ops@ietf.org > Subject: Re: [v6ops] Comments on draft-gundavelli-v6ops-community-wifi-svcs-03 > > > > how many million hotspots you guys have deployed last year ? The spec tries to identify what it takes to enable that service, the protocol choice, mobility considerations, IPv6 transitioning and other aspects. We are still working on additional updates, that should complete all the IPv6 considerations. > > [WEG] Allow me to provide some more specific feedback about what=92s missing in terms of IPv6 considerations. > > > > A deployment of this type MUST be planning for IPv6 on day one, and we=92= d be doing a disservice to not explicitly state that so that those using this as a guide include this in their requirements to their vendors. > > > > When you are deploying "millions of hotspots" you had better be prepared to manage them via IPv6... ONLY. By manage, I mean everything from remote configuration, OSS/polling, software management, etc. > > This also extends to if you are using something like GRE or L2TP tunneling to carry traffic from an AP back to a wifi core to manage mobility and other things -- that tunneling MUST be done over IPv6. These deployments are simply too large and there are already too many overlapping uses of 1918 space for it to be realistic to think that it will be possible to give these APs even one IPv4 address for those uses. This consideration will seem very familiar to those of us who have been on the wrong end of a discussion involving trying to make 50K cell towers IP-reachable, and stunned to find out that key pieces of equipment and software say, =93huh? What=92s IPv6?=94 > > > > And of course, it MUST be able to carry IPv6 data from end hosts (the actual users). While Wifi is a layer 2 protocol, there are enough interactions between Layer 2 and 3 that IPv6 support should be explicitly indicated. I've been personally burned by this in such a way as to not want to simply assume that it'll just work because wifi vendors will be smart enough to do the right thing. > > > > Naturally, if you'd like to be backwards compatible, you SHOULD support IPv4 for all of the above, but you MUST support IPv6 and you MUST NOT require IPv4 for proper and complete function. RFC6540 (in AUTH48) says more or less exactly this. You're welcome to cite it :-) > > > > Thanks, > > Wes George > > ^^^^^^^^ Yes, please add ALL of that. Wes hit the nail on the head. Cb > ________________________________ > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --047d7b10cfefe7f57b04bbfe0eab Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable


On Mar 24, 2012 5:59 AM, "George, Wes" <wesley.george@twcable.com> wrote:
>
> From: v6ops-bounces@ietf.org= [mailto:v6ops-bounces@ietf.o= rg] On Behalf Of Sri Gundavelli
> Sent: Wednesday, March 21, 2012 9:40 PM
> To: Hui Deng; v6ops@ietf.org
> Subject: Re: [v6ops] Comments on draft-gundavelli-v6ops-community-wifi= -svcs-03
>
> =A0
>
> how many million hotspots you guys have deployed last year ? The spec = tries to identify what it takes to enable that service, the protocol choice= , mobility considerations, IPv6 transitioning and other aspects. We are sti= ll working on additional updates, that should complete all the IPv6 conside= rations.
>
> [WEG] Allow me to provide some more specific feedback about what=92s m= issing in terms of IPv6 considerations.
>
> =A0
>
> A deployment of this type MUST be planning for IPv6 on day one, and we= =92d be doing a disservice to not explicitly state that so that those using= this as a guide include this in their requirements to their vendors.
>
> =A0
>
> When you are deploying "millions of hotspots" you had better= be prepared to manage them via IPv6... ONLY. By manage, I mean everything = from remote configuration, OSS/polling, software management, etc.
>
> This also extends to if you are using something like GRE or L2TP tunne= ling to carry traffic from an AP back to a wifi core to manage mobility and= other things -- that tunneling MUST be done over IPv6. These deployments a= re simply too large and there are already too many overlapping uses of 1918= space for it to be realistic to think that it will be possible to give the= se APs even one IPv4 address for those uses. This consideration will seem v= ery familiar to those of us who have been on the wrong end of a discussion = involving trying to make 50K cell towers IP-reachable, and stunned to find = out that key pieces of equipment and software say, =93huh? What=92s IPv6?= =94
>
> =A0
>
> And of course, it MUST be able to carry IPv6 data from end hosts (the = actual users). While Wifi is a layer 2 protocol, there are enough interacti= ons between Layer 2 and 3 that IPv6 support should be explicitly indicated.= I've been personally burned by this in such a way as to not want to si= mply assume that it'll just work because wifi vendors will be smart eno= ugh to do the right thing.
>
> =A0
>
> Naturally, if you'd like to be backwards compatible, you SHOULD su= pport IPv4 for all of the above, but you MUST support IPv6 and you MUST NOT= require IPv4 for proper and complete function. RFC6540 (in AUTH48) says mo= re or less exactly this. You're welcome to cite it :-)
>
> =A0
>
> Thanks,
>
> Wes George
>
>

^^^^^^^^

Yes, please add ALL of that. Wes hit the nail on the head.

Cb
> ________________________________
> This E-mail and any of its attachments may contain Time Warner Cable p= roprietary information, which is privileged, confidential, or subject to co= pyright belonging to Time Warner Cable. This E-mail is intended solely for = the use of the individual or entity to which it is addressed. If you are no= t the intended recipient of this E-mail, you are hereby notified that any d= issemination, distribution, copying, or action taken in relation to the con= tents of and attachments to this E-mail is strictly prohibited and may be u= nlawful. If you have received this E-mail in error, please notify the sende= r immediately and permanently delete the original and any copy of this E-ma= il and any printout.
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ie= tf.org/mailman/listinfo/v6ops
>

--047d7b10cfefe7f57b04bbfe0eab-- From phdgang@gmail.com Sat Mar 24 15:37:43 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED33321F8517 for ; Sat, 24 Mar 2012 15:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.46 X-Spam-Level: X-Spam-Status: No, score=-3.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 t5oRfTDHV+nl for ; Sat, 24 Mar 2012 15:37:43 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id A75C921F8516 for ; Sat, 24 Mar 2012 15:37:42 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so2613171wib.13 for ; Sat, 24 Mar 2012 15:37:41 -0700 (PDT) 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=BIxh5/52Z+czbUzF4KxgVagH1Tz7/E1pi6Qr28M8Z2g=; b=gtYVT792RegxNuABxlWcxu6g+UdCzDVX2UD4/Mf7TSG17PdHyApsQpmc2Hgw+QUjqz 0kyaRF0AAATMFpvfZOeHqe0y/pxq6XAUQNvxoOoEqgUMhHiVCoRq7klUXZFgm0af4Mk9 vc/gvo0GPFC6PBsKjYIpSE5fgByXxmdNcy4FOrTLh6vJMdsZ38tfzBiE5usKaC3Vmirs C0FcsGsVTtUywKJ9+X8q34GQKExOQ06+h3RZ8mjXKKM2l8WbJflrMyPxxQ8ebl8/qZ3o SAL+/6VzLI7yFobZTC7HWnM2cTlfXZQMWQGJPFqV6J2CR35uOSqH3yZ5cdJSh/M9Lgi8 9J/A== MIME-Version: 1.0 Received: by 10.180.107.164 with SMTP id hd4mr7275437wib.18.1332628661570; Sat, 24 Mar 2012 15:37:41 -0700 (PDT) Received: by 10.180.7.105 with HTTP; Sat, 24 Mar 2012 15:37:41 -0700 (PDT) In-Reply-To: References: <11ECC355-6FAC-4D69-A615-AB43F2180CEE@laposte.net> Date: Sun, 25 Mar 2012 06:37:41 +0800 Message-ID: From: GangChen To: "George, Wes" Content-Type: text/plain; charset=ISO-8859-1 Cc: "v6ops@ietf.org" Subject: Re: [v6ops] I-D Action: draft-chen-v6ops-nat64-experience-00.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 22:37:44 -0000 Hello George, Thanks for the comments. Reply is in line. 2012/3/24, George, Wes : > Some additional comments on this new version > > Section 2.3 - This only briefly mentions logging translation events and > offline traceability. The amount of logging data generated by other NAT > implementations such as NAT444 is potentially onerous. It would be helpful > to discuss whether this shares a similar concern, and characterize the > amount of logging generated in typical usage by comparison, whether > optimizations are possible similar to draft-donley-behave-deterministic-cgn > to reduce the logging, etc. Good suggestions. That are useful arguments to strengthen the discussion. We would add texts on the tradeoff between address multiplexing efficiency & logging storage compression in next version. > Also in this same section, I disagree with the statements " Lawful > intercept[RFC3924] is normally part of the access network, in > which an optical splitter is used to bypass all traffic for > subsequent filtering process." And "even if that > may not a major case in current practices" > > Optical split is actually a fairly uncommon method to do LI in most > broadband access networks, I guess that is a vendor-specific situation >and is also not really the method defined in 3924. Yes. rfc3924 is focusing on LI framework. Not implementation-specific > I don't think that the second half of this phrase (the part talking > about optical splits and whether LI of one sort or another is common) is > actually adding much to the discussion, and it should probably just be > removed. That said, you assert that LI is easily added, and I think that it > would be better to expand on that, either with a reference to where this is > discussed in detail elsewhere, or additional text to explain how. Acknowledged. I guess the statement should be modified from generalized views other than deriving from a particular implementation case. I would prefer to update texts to compliant with draft-ietf-behave-lsn-requirements BRs Gang > > Thanks, > > Wes George > > > >> -----Original Message----- >> From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of >> GangChen >> Sent: Monday, March 12, 2012 10:59 PM >> To: v6ops@ietf.org >> Subject: Re: [v6ops] I-D Action: draft-chen-v6ops-nat64-experience-00.txt >> >> Hello all, >> >> Replying the comments received on the list, we updated the draft and >> published -01 for NAT64 experiences. Please check the side-by-side >> diff as below >> >> http://tools.ietf.org/rfcdiff?url1=draft-chen-v6ops-nat64-experience- >> 00&difftype=--html&submit=Go%21&url2=draft-chen-v6ops-nat64-experience-01 >> >> Your further comments are appreciated >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : NAT64 Operational Experiences >> Author(s) : Gang Chen >> Zhen Cao >> Cameron Byrne >> QiBo Niu >> Filename : draft-chen-v6ops-nat64-experience-01.txt >> Pages : 11 >> Date : 2012-03-12 >> >> This document summarizes some stateful NAT64 deployment scenarios and >> operational experiences for NAT64-CGN and NAT64-CE. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-chen-v6ops-nat64-experience-01.txt >> >> >> BRs >> >> Gang >> >> > > > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely for > the use of the individual or entity to which it is addressed. If you are not > the intended recipient of this E-mail, you are hereby notified that any > dissemination, distribution, copying, or action taken in relation to the > contents of and attachments to this E-mail is strictly prohibited and may be > unlawful. If you have received this E-mail in error, please notify the > sender immediately and permanently delete the original and any copy of this > E-mail and any printout. > From rajiva@cisco.com Sat Mar 24 17:56:27 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0DF121F850C for ; Sat, 24 Mar 2012 17:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.986 X-Spam-Level: X-Spam-Status: No, score=-7.986 tagged_above=-999 required=5 tests=[AWL=-1.451, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 hGXwdCmybfdu for ; Sat, 24 Mar 2012 17:56:26 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE7B21F850B for ; Sat, 24 Mar 2012 17:56:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rajiva@cisco.com; l=17226; q=dns/txt; s=iport; t=1332636986; x=1333846586; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=gJnywOWRsjBA9/C9ujHuAoDsdcSgbNOsO9bEgivKlQY=; b=Rq05UZvAUpLcC1wSn5hurvm560yGGnQIcMzaPyKtWk42jQoIJFTiyl3f 2slCNkuJQTuv9Caj7R/4JAGI7lu/NRa2BEn18KFB9qQd2iKYn5kvQyx85 uWfVQEbRh+AuY2mCPiOCTS9gkPZLv8WoaaVg6jkh/s7jwN7hXP4iKxRre Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgJAFVsbk+tJV2Z/2dsb2JhbABEhT+xZH4CgQeCCQEBAQMBAQEBDwEQRAcEBwUHBAIBCA4EAwMnAwICAh8GHwMOAQEEEyKHYwULmUqNCJEBBIlxdoUpNWMEiCSNPIsxgxSBaIMDgUA X-IronPort-AV: E=Sophos;i="4.73,644,1325462400"; d="scan'208,217";a="69173924" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 25 Mar 2012 00:56:25 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2P0uPfQ004810; Sun, 25 Mar 2012 00:56:25 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 24 Mar 2012 19:56:25 -0500 Received: from 72.163.62.136 ([72.163.62.136]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Sun, 25 Mar 2012 00:56:24 +0000 References: Content-Transfer-Encoding: 7bit From: "Rajiv Asati (rajiva)" Content-Type: multipart/alternative; boundary="Apple-Mail-0A24070B-127B-4A7D-A63E-1BEA3683F9FB"; charset="iso-8859-1" Thread-Topic: [v6ops] Nomative language in draft-ietf-v6ops-464xlat-00 In-Reply-To: Thread-Index: Ac0KIhnyHb+UvDoFSzaDdCdZingUhg== Message-ID: <1BBBDA7B-FC15-43BE-B08E-BE2F13FDBC5A@cisco.com> Date: Sat, 24 Mar 2012 20:56:15 -0400 To: "Cameron Byrne" MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 25 Mar 2012 00:56:25.0244 (UTC) FILETIME=[1A71BDC0:01CD0A22] Cc: IPv6 Ops WG Subject: Re: [v6ops] Nomative language in draft-ietf-v6ops-464xlat-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 00:56:28 -0000 --Apple-Mail-0A24070B-127B-4A7D-A63E-1BEA3683F9FB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Cameron, I agree with you, if we assume that PLAT function is not enabled on the UE's= IP next-hope e.g. GGSN/P-GW.=20 Of course, if that assumption weren't true in any deployment, then WKP could= well be used without any of those concerns you rightly pointed out. Just an (obvious) observation that may be worth including. Cheers, Rajiv Sent from my Phone On Mar 24, 2012, at 10:28 AM, "Cameron Byrne" wrote: >=20 > On Mar 24, 2012 5:58 AM, "George, Wes" wrote: > > > > I've read and support this draft. One comment after having read the draf= t and this thread: >=20 > Thanks for the support >=20 > > Currently in 6.1 the draft says "The format is defined in > > Section 2.2 of [RFC6052]. However, 464XLAT does not use the Well- > > Known IPv6 Prefix "64:ff9b::/96"." > > > > However, it does not explicitly explain why it does not use the WKP, and= unless I'm being thick (which is entirely possible), the discussion you've h= ad with Woj does not either. I assume that there's a valid reason, which sho= uld be explained following that statement. > > >=20 > Wkp constrains the architecture too much. >=20 > Wkp does not work well at large scale where it is desired to specifically t= raffic engineer load using unique NSP to load and unload a given PLAT. >=20 > One could anycast the wkp, but anycast clashes with stateful behavior at t= he PLAT... I'd rather not tightly couple PLAT load with routing topology. >=20 > In the case where the PLAT is located in a different administrative domain= , wkp is not possible .... as where NSP may be carried even in the DFZ to al= low CLAT on the internet to communicate with internet hosted PLATs >=20 > We can boil the above down to a sentence and add it to the draft to increa= se clarity. >=20 > Thanks again for the review and support. >=20 > Cb >=20 >=20 > > Thanks, > > > > Wes > > > > > > > > > -----Original Message----- > > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf= Of > > > Cameron Byrne > > > > > > > What more it contains specific text in Section 6.1 like > > > > > > > > " > > > > > > > > IPv6 address format in 464XLAT is presented in the following format.= > > > > > > > > +-----------------------------------------------+------------= ---+ > > > > | XLAT prefix(96) | IPv4(32)= | > > > > +-----------------------------------------------+------------= ---+ > > > > > > > > Source address and destination address have IPv4 address embedded in= the > > > > low-order 32 bits of the IPv6 address. " > > > > > > > > > > This E-mail and any of its attachments may contain Time Warner Cable pro= prietary information, which is privileged, confidential, or subject to copyr= ight belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the i= ntended recipient of this E-mail, you are hereby notified that any dissemina= tion, distribution, copying, or action taken in relation to the contents of a= nd attachments to this E-mail is strictly prohibited and may be unlawful. If= you have received this E-mail in error, please notify the sender immediatel= y and permanently delete the original and any copy of this E-mail and any pr= intout. > On Mar 24, 2012 5:58 AM, "George, Wes" wrote: > I've read and support this draft. One comment after having read the draft a= nd this thread: > Currently in 6.1 the draft says "The format is defined in > Section 2.2 of [RFC6052]. However, 464XLAT does not use the Well- > Known IPv6 Prefix "64:ff9b::/96"." >=20 > However, it does not explicitly explain why it does not use the WKP, and u= nless I'm being thick (which is entirely possible), the discussion you've ha= d with Woj does not either. I assume that there's a valid reason, which shou= ld be explained following that statement. >=20 > Thanks, >=20 > Wes >=20 >=20 >=20 > > -----Original Message----- > > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf O= f > > Cameron Byrne > > > > > What more it contains specific text in Section 6.1 like > > > > > > " > > > > > > IPv6 address format in 464XLAT is presented in the following format. > > > > > > +-----------------------------------------------+--------------= -+ > > > | XLAT prefix(96) | IPv4(32) = | > > > +-----------------------------------------------+--------------= -+ > > > > > > Source address and destination address have IPv4 address embedded in t= he > > > low-order 32 bits of the IPv6 address. " > > > >=20 >=20 > This E-mail and any of its attachments may contain Time Warner Cable propr= ietary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the us= e of the individual or entity to which it is addressed. If you are not the i= ntended recipient of this E-mail, you are hereby notified that any dissemina= tion, distribution, copying, or action taken in relation to the contents of a= nd attachments to this E-mail is strictly prohibited and may be unlawful. If= you have received this E-mail in error, please notify the sender immediatel= y and permanently delete the original and any copy of this E-mail and any pr= intout. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops --Apple-Mail-0A24070B-127B-4A7D-A63E-1BEA3683F9FB Content-Transfer-Encoding: base64 Content-Type: text/html; charset=utf-8 PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IGJnY29sb3I9IiNGRkZGRkYiPjxkaXY+Q2FtZXJvbiw8 L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkkgYWdyZWUgd2l0aCB5b3UsIGlmIHdlIGFzc3VtZSB0 aGF0Jm5ic3A7PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSItd2Via2l0LXRh cC1oaWdobGlnaHQtY29sb3I6IHJnYmEoMjYsIDI2LCAyNiwgMC4yOTI5NjkpOyAtd2Via2l0LWNv bXBvc2l0aW9uLWZpbGwtY29sb3I6IHJnYmEoMTc1LCAxOTIsIDIyNywgMC4yMzA0NjkpOyAtd2Vi a2l0LWNvbXBvc2l0aW9uLWZyYW1lLWNvbG9yOiByZ2JhKDc3LCAxMjgsIDE4MCwgMC4yMzA0Njkp OyAiPlBMQVQgZnVuY3Rpb24gaXMgbm90IGVuYWJsZWQgb24gdGhlIFVFJ3MgSVAgbmV4dC1ob3Bl IGUuZy4gR0dTTi9QLUdXLiZuYnNwOzwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIGNsYXNzPSJBcHBs ZS1zdHlsZS1zcGFuIiBzdHlsZT0iLXdlYmtpdC10YXAtaGlnaGxpZ2h0LWNvbG9yOiByZ2JhKDI2 LCAyNiwgMjYsIDAuMjkyOTY5KTsgLXdlYmtpdC1jb21wb3NpdGlvbi1maWxsLWNvbG9yOiByZ2Jh KDE3NSwgMTkyLCAyMjcsIDAuMjMwNDY5KTsgLXdlYmtpdC1jb21wb3NpdGlvbi1mcmFtZS1jb2xv cjogcmdiYSg3NywgMTI4LCAxODAsIDAuMjMwNDY5KTsgIj48YnI+PC9zcGFuPjwvZGl2PjxkaXY+ PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSItd2Via2l0LXRhcC1oaWdobGln aHQtY29sb3I6IHJnYmEoMjYsIDI2LCAyNiwgMC4yOTI5NjkpOyAtd2Via2l0LWNvbXBvc2l0aW9u LWZpbGwtY29sb3I6IHJnYmEoMTc1LCAxOTIsIDIyNywgMC4yMzA0NjkpOyAtd2Via2l0LWNvbXBv c2l0aW9uLWZyYW1lLWNvbG9yOiByZ2JhKDc3LCAxMjgsIDE4MCwgMC4yMzA0NjkpOyAiPk9mIGNv dXJzZSwgaWYgdGhhdCBhc3N1bXB0aW9uIHdlcmVuJ3QgdHJ1ZSBpbiBhbnkgZGVwbG95bWVudCwg dGhlbiBXS1AgY291bGQgd2VsbCBiZSB1c2VkIHdpdGhvdXQgYW55IG9mIHRob3NlIGNvbmNlcm5z IHlvdSByaWdodGx5IHBvaW50ZWQgb3V0Ljwvc3Bhbj48L2Rpdj48ZGl2PjxzcGFuIGNsYXNzPSJB cHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iLXdlYmtpdC10YXAtaGlnaGxpZ2h0LWNvbG9yOiByZ2Jh KDI2LCAyNiwgMjYsIDAuMjkyOTY5KTsgLXdlYmtpdC1jb21wb3NpdGlvbi1maWxsLWNvbG9yOiBy Z2JhKDE3NSwgMTkyLCAyMjcsIDAuMjMwNDY5KTsgLXdlYmtpdC1jb21wb3NpdGlvbi1mcmFtZS1j b2xvcjogcmdiYSg3NywgMTI4LCAxODAsIDAuMjMwNDY5KTsgIj48YnI+PC9zcGFuPjwvZGl2Pjxk aXY+SnVzdCBhbiAob2J2aW91cykgb2JzZXJ2YXRpb24gdGhhdCBtYXkgYmUgd29ydGggaW5jbHVk aW5nLjxicj48YnI+Q2hlZXJzLDxkaXY+UmFqaXY8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlNl bnQgZnJvbSBteSBQaG9uZTwvZGl2PjwvZGl2PjxkaXY+PGJyPk9uIE1hciAyNCwgMjAxMiwgYXQg MTA6MjggQU0sICJDYW1lcm9uIEJ5cm5lIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNiLmxpc3Q2QGdt YWlsLmNvbSI+Y2IubGlzdDZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPjxicj48L2Rpdj48 ZGl2PjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+PHA+PGJyPg0KT24gTWFyIDI0 LCAyMDEyIDU6NTggQU0sICJHZW9yZ2UsIFdlcyIgJmx0OzxhIGhyZWY9Im1haWx0bzp3ZXNsZXku Z2VvcmdlQHR3Y2FibGUuY29tIj53ZXNsZXkuZ2VvcmdlQHR3Y2FibGUuY29tPC9hPiZndDsgd3Jv dGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgSSd2ZSByZWFkIGFuZCBzdXBwb3J0IHRoaXMgZHJhZnQu IE9uZSBjb21tZW50IGFmdGVyIGhhdmluZyByZWFkIHRoZSBkcmFmdCBhbmQgdGhpcyB0aHJlYWQ6 PC9wPg0KPHA+VGhhbmtzIGZvciB0aGUgc3VwcG9ydDwvcD4NCjxwPiZndDsgQ3VycmVudGx5IGlu IDYuMSB0aGUgZHJhZnQgc2F5cyAiVGhlIGZvcm1hdCBpcyBkZWZpbmVkIGluPGJyPg0KJmd0OyAm bmJzcDsgU2VjdGlvbiAyLjIgb2YgW1JGQzYwNTJdLiAmbmJzcDtIb3dldmVyLCA0NjRYTEFUIGRv ZXMgbm90IHVzZSB0aGUgV2VsbC08YnI+DQomZ3Q7ICZuYnNwOyBLbm93biBJUHY2IFByZWZpeCAi NjQ6ZmY5Yjo6Lzk2Ii4iPGJyPg0KJmd0Ozxicj4NCiZndDsgSG93ZXZlciwgaXQgZG9lcyBub3Qg ZXhwbGljaXRseSBleHBsYWluIHdoeSBpdCBkb2VzIG5vdCB1c2UgdGhlIFdLUCwgYW5kIHVubGVz cyBJJ20gYmVpbmcgdGhpY2sgKHdoaWNoIGlzIGVudGlyZWx5IHBvc3NpYmxlKSwgdGhlIGRpc2N1 c3Npb24geW91J3ZlIGhhZCB3aXRoIFdvaiBkb2VzIG5vdCBlaXRoZXIuIEkgYXNzdW1lIHRoYXQg dGhlcmUncyBhIHZhbGlkIHJlYXNvbiwgd2hpY2ggc2hvdWxkIGJlIGV4cGxhaW5lZCBmb2xsb3dp bmcgdGhhdCBzdGF0ZW1lbnQuPGJyPg0KDQomZ3Q7PC9wPg0KPHA+V2twIGNvbnN0cmFpbnMgdGhl IGFyY2hpdGVjdHVyZSB0b28gbXVjaC4gPC9wPg0KPHA+V2twIGRvZXMgbm90IHdvcmsgd2VsbCBh dCBsYXJnZSBzY2FsZSB3aGVyZSBpdCBpcyBkZXNpcmVkIHRvIHNwZWNpZmljYWxseSB0cmFmZmlj IGVuZ2luZWVyIGxvYWQmbmJzcDsgdXNpbmcgdW5pcXVlIE5TUCB0byBsb2FkIGFuZCB1bmxvYWQg YSBnaXZlbiBQTEFULjwvcD4NCjxwPk9uZSBjb3VsZCBhbnljYXN0IHRoZSB3a3AsIGJ1dCBhbnlj YXN0IGNsYXNoZXMgd2l0aCBzdGF0ZWZ1bCBiZWhhdmlvciBhdCB0aGUgUExBVC4uLiBJJ2QgcmF0 aGVyIG5vdCB0aWdodGx5IGNvdXBsZSBQTEFUIGxvYWQgd2l0aCByb3V0aW5nIHRvcG9sb2d5LiA8 L3A+DQo8cD5JbiB0aGUgY2FzZSB3aGVyZSB0aGUgUExBVCBpcyBsb2NhdGVkIGluIGEgZGlmZmVy ZW50IGFkbWluaXN0cmF0aXZlIGRvbWFpbiwgd2twIGlzIG5vdCBwb3NzaWJsZSAuLi4uIGFzIHdo ZXJlIE5TUCBtYXkgYmUgY2FycmllZCBldmVuIGluIHRoZSBERlogdG8gYWxsb3cgQ0xBVCBvbiB0 aGUgaW50ZXJuZXQgdG8gY29tbXVuaWNhdGUgd2l0aCBpbnRlcm5ldCBob3N0ZWQgUExBVHM8L3A+ DQoNCjxwPldlIGNhbiBib2lsIHRoZSBhYm92ZSBkb3duIHRvIGEgc2VudGVuY2UgYW5kIGFkZCBp dCB0byB0aGUgZHJhZnQgdG8gaW5jcmVhc2UgY2xhcml0eS4gPC9wPg0KPHA+VGhhbmtzIGFnYWlu IGZvciB0aGUgcmV2aWV3IGFuZCBzdXBwb3J0LiA8L3A+DQo8cD5DYjxicj48YnI+PC9wPg0KPHA+ Jmd0OyBUaGFua3MsPGJyPg0KJmd0Ozxicj4NCiZndDsgV2VzPGJyPg0KJmd0Ozxicj4NCiZndDs8 YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0K Jmd0OyAmZ3Q7IEZyb206IDxhIGhyZWY9Im1haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnIj52 Nm9wcy1ib3VuY2VzQGlldGYub3JnPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzp2Nm9wcy1i b3VuY2VzQGlldGYub3JnIj52Nm9wcy1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9m PGJyPg0KJmd0OyAmZ3Q7IENhbWVyb24gQnlybmU8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgJmd0OyBXaGF0IG1vcmUgaXQgY29udGFpbnMgc3BlY2lmaWMgdGV4dCBpbiBTZWN0aW9uIDYu MSBsaWtlPGJyPg0KJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAiPGJyPg0KJmd0 OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyBJUHY2IGFkZHJlc3MgZm9ybWF0IGluIDQ2 NFhMQVQgaXMgcHJlc2VudGVkIGluIHRoZSBmb2xsb3dpbmcgZm9ybWF0Ljxicj4NCiZndDsgJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Ky0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0t LS0tLSs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1hMQVQgcHJlZml4 KDk2KSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwO0lQdjQoMzIpICZuYnNwOyB8PGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSs8YnI+DQomZ3Q7ICZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IFNvdXJjZSBhZGRyZXNzIGFuZCBkZXN0aW5hdGlvbiBh ZGRyZXNzIGhhdmUgSVB2NCBhZGRyZXNzIGVtYmVkZGVkIGluIHRoZTxicj4NCiZndDsgJmd0OyAm Z3Q7IGxvdy1vcmRlciAzMiBiaXRzIG9mIHRoZSBJUHY2IGFkZHJlc3MuICI8YnI+DQomZ3Q7ICZn dDsgJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGlzIEUtbWFpbCBhbmQgYW55 IG9mIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmll dGFyeSBpbmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBz dWJqZWN0IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMg RS1tYWlsIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBv ciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0 aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0 YWtlbiBpbiByZWxhdGlvbiB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRo aXMgRS1tYWlsIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBh bmQgYW55IGNvcHkgb2YgdGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC48YnI+DQoNCjwvcD4N CjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBNYXIgMjQsIDIwMTIgNTo1OCBBTSwgIkdlb3Jn ZSwgV2VzIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOndlc2xleS5nZW9yZ2VAdHdjYWJsZS5jb20iPndl c2xleS5nZW9yZ2VAdHdjYWJsZS5jb208L2E+Jmd0OyB3cm90ZTo8YnIgdHlwZT0iYXR0cmlidXRp b24iPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAu OGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KSSd2ZSBy ZWFkIGFuZCBzdXBwb3J0IHRoaXMgZHJhZnQuIE9uZSBjb21tZW50IGFmdGVyIGhhdmluZyByZWFk IHRoZSBkcmFmdCBhbmQgdGhpcyB0aHJlYWQ6PGJyPg0KQ3VycmVudGx5IGluIDYuMSB0aGUgZHJh ZnQgc2F5cyAiVGhlIGZvcm1hdCBpcyBkZWZpbmVkIGluPGJyPg0KICZuYnNwOyBTZWN0aW9uIDIu MiBvZiBbUkZDNjA1Ml0uICZuYnNwO0hvd2V2ZXIsIDQ2NFhMQVQgZG9lcyBub3QgdXNlIHRoZSBX ZWxsLTxicj4NCiAmbmJzcDsgS25vd24gSVB2NiBQcmVmaXggIjY0OmZmOWI6Oi85NiIuIjxicj4N Cjxicj4NCkhvd2V2ZXIsIGl0IGRvZXMgbm90IGV4cGxpY2l0bHkgZXhwbGFpbiB3aHkgaXQgZG9l cyBub3QgdXNlIHRoZSBXS1AsIGFuZCB1bmxlc3MgSSdtIGJlaW5nIHRoaWNrICh3aGljaCBpcyBl bnRpcmVseSBwb3NzaWJsZSksIHRoZSBkaXNjdXNzaW9uIHlvdSd2ZSBoYWQgd2l0aCBXb2ogZG9l cyBub3QgZWl0aGVyLiBJIGFzc3VtZSB0aGF0IHRoZXJlJ3MgYSB2YWxpZCByZWFzb24sIHdoaWNo IHNob3VsZCBiZSBleHBsYWluZWQgZm9sbG93aW5nIHRoYXQgc3RhdGVtZW50Ljxicj4NCg0KPGJy Pg0KVGhhbmtzLDxicj4NCjxicj4NCldlczxicj4NCjxicj4NCjxicj4NCjxicj4NCiZndDsgLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IDxhIGhyZWY9Im1haWx0bzp2 Nm9wcy1ib3VuY2VzQGlldGYub3JnIj52Nm9wcy1ib3VuY2VzQGlldGYub3JnPC9hPiBbbWFpbHRv OjxhIGhyZWY9Im1haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3JnIj52Nm9wcy1ib3VuY2VzQGll dGYub3JnPC9hPl0gT24gQmVoYWxmIE9mPGJyPg0KJmd0OyBDYW1lcm9uIEJ5cm5lPGJyPg0KJmd0 Ozxicj4NCiZndDsgJmd0OyBXaGF0IG1vcmUgaXQgY29udGFpbnMgc3BlY2lmaWMgdGV4dCBpbiBT ZWN0aW9uIDYuMSBsaWtlPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICI8YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDsgSVB2NiBhZGRyZXNzIGZvcm1hdCBpbiA0NjRYTEFUIGlzIHBy ZXNlbnRlZCBpbiB0aGUgZm9sbG93aW5nIGZvcm1hdC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSs8YnI+DQomZ3Q7ICZndDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtYTEFUIHByZWZpeCg5NikgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDtJ UHY0KDMyKSAmbmJzcDsgfDxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsrLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tKzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBTb3VyY2UgYWRkcmVzcyBh bmQgZGVzdGluYXRpb24gYWRkcmVzcyBoYXZlIElQdjQgYWRkcmVzcyBlbWJlZGRlZCBpbiB0aGU8 YnI+DQomZ3Q7ICZndDsgbG93LW9yZGVyIDMyIGJpdHMgb2YgdGhlIElQdjYgYWRkcmVzcy4gIjxi cj4NCiZndDsgJmd0Ozxicj4NCjxicj4NCjxicj4NClRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRz IGF0dGFjaG1lbnRzIG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0YXJ5IGlu Zm9ybWF0aW9uLCB3aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3Qg dG8gY29weXJpZ2h0IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwg aXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0 eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55 IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2VuIGlu IHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8gdGhpcyBFLW1h aWwgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3ZnVsLiBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIEUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGltbWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbnkg Y29weSBvZiB0aGlzIEUtbWFpbCBhbmQgYW55IHByaW50b3V0Ljxicj4NCg0KPC9ibG9ja3F1b3Rl PjwvZGl2Pg0KPC9kaXY+PC9ibG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+ PHNwYW4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3Nw YW4+PGJyPjxzcGFuPnY2b3BzIG1haWxpbmcgbGlzdDwvc3Bhbj48YnI+PHNwYW4+PGEgaHJlZj0i bWFpbHRvOnY2b3BzQGlldGYub3JnIj52Nm9wc0BpZXRmLm9yZzwvYT48L3NwYW4+PGJyPjxzcGFu PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHM8L2E+PC9zcGFuPjxicj48 L2Rpdj48L2Jsb2NrcXVvdGU+PC9ib2R5PjwvaHRtbD4= --Apple-Mail-0A24070B-127B-4A7D-A63E-1BEA3683F9FB-- From leo.liubing@huawei.com Sun Mar 25 00:24:01 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC5321F842C for ; Sun, 25 Mar 2012 00:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.563 X-Spam-Level: *** X-Spam-Status: No, score=3.563 tagged_above=-999 required=5 tests=[AWL=-4.686, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345] 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 W9fwrEOg0Uug for ; Sun, 25 Mar 2012 00:24:00 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8219521F8455 for ; Sun, 25 Mar 2012 00:23:56 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEJ15156; Sun, 25 Mar 2012 03:23:56 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 25 Mar 2012 00:23:43 -0700 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by dfweml404-hub.china.huawei.com (10.193.5.203) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 25 Mar 2012 00:23:51 -0700 Received: from SZXEML509-MBX.china.huawei.com ([10.82.67.37]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.003; Sun, 25 Mar 2012 15:23:47 +0800 From: "Liubing (Leo)" To: "George, Wes" , Brian E Carpenter , IPv6 Operations Thread-Topic: [v6ops] draft-liu-v6ops-ula-usage-analysis-02 Thread-Index: AQHNCKO8Z4KSGk/lHk+mkdEjskALJpZ45DEAgAG2WNc= Date: Sun, 25 Mar 2012 07:23:46 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F452927A842@szxeml509-mbx> References: <4F6BEB95.60608@gmail.com>, In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.68] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [v6ops] =?gb2312?b?tPC4tDogIGRyYWZ0LWxpdS12Nm9wcy11bGEtdXNhZ2Ut?= =?gb2312?b?YW5hbHlzaXMtMDI=?= X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 07:24:01 -0000 SGksIFdlcw0KDQpUaGFua3MgZm9yIHRoZSBjb21tZW50Lg0KDQo+IFN0cmljdGx5IHNwZWFraW5n LCB0aGUgUkZDMTkxOCBkZXBsb3ltZW50IG1vZGVsIGFzIGRlZmluZWQgaW4gMTkxOCBpdHNlbGYg ZG9lcyBub3QgaW5jbHVkZSBOQVQsIGFuZCBpcyBhY3R1YWxseSBhIHJlYXNvbmFibGUgZXF1aXZh bGVudCB0byBVTEEuDQoNCltCaW5nXSBZZXMsIHRoaXMgaXMgYSBtb3JlIGFjY3VyYXRlIGRlc2Ny aXB0aW9uLCBJJ2xsIHVwZGF0ZSB0aGUgZHJhZnQuIA0KVUxBIGlzIGVxdWl2YWxlbnQgdG8gMTkx OCBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiBpbmRlcGVuZGVudCBhZGRyIGFsbG9jYXRpb24uIEJ1 dCBzaW5jZSAxOTE4IGlzIGFsd2F5cyB1c2VkIGJpbmRpbmcgd2l0aCBOQVQsIHNvbWUgcGVvcGxl IG1heSB0cmVhdCBVTEEgYXMgdGhlIHNhbWUgbWFubmVyLiBXZSBzaG91bGQgZWxpbWluYXRlIHRo ZSBtaXN1bmRlcnN0YW5kaW5nLg0KDQo+IFlvdSBjb3VsZCBwcm9iYWJseSBldmVuIGdvIG9uIHRv IGRpc2N1c3MgdGhlIGZhY3QgdGhhdCBzaW5jZSBpdCB3aWxsIGJlIGNvbW1vbiB0byBoYXZlIGhv c3RzIHdpdGggbXVsdGlwbGUgSVB2NiBhZGRyZXNzZXMsIHRoZSBleHBlY3RlZCBzb2x1dGlvbiBm b3IgY2FzZXMgd2hlcmUgaG9zdHMgd2l0aCBVTEEgbmVlZCB0byBpbnRlcmFjdCB3aXRoIGhvc3Rz IGJleW9uZCB0aGUgVUxBIHNjb3BlIGlzIHRvIHByb3ZpZGUgdGhlbSB3aXRoIGEgZ2xvYmFsLXNj b3BlIGFkZHJlc3MgaW4gYWRkaXRpb24gdG8gYW55IFVMQS4NCg0KW0JpbmddIFRoYXQgaXMgZXhh Y3RseSB3aGF0IHdlIGFyZ3VlZCBpbiB0aGUgZHJhZnQuIEJ1dCBVTEErUEEgaGFzIGV4cGxpY3Qg Y29udHJvdmVyc2lhbCwgSSB0aGluZCBpdCBpcyBhbiBpbXBvcnRhbnQgaXNzdWUgbmVlZCB0byBi ZSBkaXNjdXNzZWQgaW4gdGhlIFdHLg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCreivP7IyzogdjZvcHMtYm91bmNlc0BpZXRmLm9yZyBbdjZvcHMtYm91bmNl c0BpZXRmLm9yZ10gtPqx7SBHZW9yZ2UsIFdlcyBbd2VzbGV5Lmdlb3JnZUB0d2NhYmxlLmNvbV0N Creiy83KsbzkOiAyMDEyxOoz1MIyNMjVIDIwOjU4DQq1vTogQnJpYW4gRSBDYXJwZW50ZXI7IElQ djYgT3BlcmF0aW9ucw0K1vfM4jogUmU6IFt2Nm9wc10gZHJhZnQtbGl1LXY2b3BzLXVsYS11c2Fn ZS1hbmFseXNpcy0wMg0KDQpBIGNvbW1lbnQgb2YgbXkgb3duOg0KDQozLjEsIFJlZ2FyZGluZzog IkdlbmVyYWxseSwgdGhpcyBkcmFmdCBkb2Vzbid0IGNvbnNpZGVyIHRoZSBVTEErTkFUIGEgZ29v ZCBtb2RlbCBvZg0KICAgSVB2NiBkZXBsb3ltZW50IGluIG5vcm1hbCBjYXNlcy4gV2hlbiB0aGlu a2luZyBhYm91dCBVTEEsIHdlIHNob3VsZA0KICAgZWxpbWluYXRlIHRoZSBtaXN1bmRlcnN0YW5k aW5nIHRoYXQgVUxBIG1lYW5zIHRoZSBJUHY2IHZlcnNpb24gb2YNCiAgIHJmYzE5MTggZGVwbG95 bWVudCBtb2RlbC4iDQoNCkkgd291bGQgY2xhcmlmeSB0aGlzIGJ5IHNheWluZyAiLi4udGhlIElQ djYgdmVyc2lvbiBvZiB1c2luZyBSRkMxOTE4ICsgTkFUIFt3aXRoIFJGQyByZWZlcmVuY2UgZm9y IE5BVDQ0L05BUFRdIGFzIGEgbWVhbnMgdG8gcHJvdmlkZSBob3N0cyB3aXRoIHByaXZhdGUgYWRk cmVzc2VzIHdpdGggYSBtZWFucyBvZiBhY2Nlc3NpbmcgaG9zdHMgYmV5b25kIHRoZSBsb2NhbCBu ZXR3b3JrLiINClN0cmljdGx5IHNwZWFraW5nLCB0aGUgUkZDMTkxOCBkZXBsb3ltZW50IG1vZGVs IGFzIGRlZmluZWQgaW4gMTkxOCBpdHNlbGYgZG9lcyBub3QgaW5jbHVkZSBOQVQsIGFuZCBpcyBh Y3R1YWxseSBhIHJlYXNvbmFibGUgZXF1aXZhbGVudCB0byBVTEEuDQpZb3UgY291bGQgcHJvYmFi bHkgZXZlbiBnbyBvbiB0byBkaXNjdXNzIHRoZSBmYWN0IHRoYXQgc2luY2UgaXQgd2lsbCBiZSBj b21tb24gdG8gaGF2ZSBob3N0cyB3aXRoIG11bHRpcGxlIElQdjYgYWRkcmVzc2VzLCB0aGUgZXhw ZWN0ZWQgc29sdXRpb24gZm9yIGNhc2VzIHdoZXJlIGhvc3RzIHdpdGggVUxBIG5lZWQgdG8gaW50 ZXJhY3Qgd2l0aCBob3N0cyBiZXlvbmQgdGhlIFVMQSBzY29wZSBpcyB0byBwcm92aWRlIHRoZW0g d2l0aCBhIGdsb2JhbC1zY29wZSBhZGRyZXNzIGluIGFkZGl0aW9uIHRvIGFueSBVTEEuDQoNClRo YW5rcywNCg0KV2VzIEdlb3JnZQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IHY2b3BzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzp2Nm9wcy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YNCj4gQnJpYW4gRSBDYXJwZW50ZXINCj4gU2VudDogVGh1cnNkYXksIE1h cmNoIDIyLCAyMDEyIDExOjE5IFBNDQo+IFRvOiBJUHY2IE9wZXJhdGlvbnMNCj4gU3ViamVjdDog W3Y2b3BzXSBkcmFmdC1saXUtdjZvcHMtdWxhLXVzYWdlLWFuYWx5c2lzLTAyDQo+DQo+IEhpLA0K Pg0KPiBJIHRoaW5rIHRoaXMgZHJhZnQgaXMgYSBjb25zaWRlcmFibGUgaW1wcm92ZW1lbnQgb24g dGhlIC0wMCB2ZXJzaW9uLg0KPiBJdCBzdGlsbCBuZWVkcyBzb21lIHdvcmsgb24gdGhlIEVuZ2xp c2gsIGJ1dCBJIHRoaW5rIHRoZSBtYWluIHBvaW50cw0KPiBhcmUgY292ZXJlZCBub3cgYW5kIHRo ZSB3b3JrIHNob3VsZCBjb250aW51ZS4NCj4NCj4gSG93ZXZlciwgdGhlcmUgaXMgY2xlYXJseSBh IGNvbXBsaWNhdGlvbiwgd2hpY2ggaXMgdGhhdCB0aGlzIGRvY3VtZW50DQo+IG5lZWRzIHRvIGJl IGFsaWduZWQgd2l0aCB3aGF0ZXZlciBjb25zZW5zdXMgYXBwZWFycyBpbiBob21lbmV0IGFib3V0 DQo+IFVMQXMsIGFuZCB3aXRoIHdoYXRldmVyIGNvbnNlbnN1cyBhcHBlYXJzIGluIDZtYW4gYWJv dXQgUkZDMzQ4NGJpcy4NCj4NCj4gSW4gcGFydGljdWxhciwgaG9tZW5ldCBpcyBoaXR0aW5nIHRo ZSBwcm9ibGVtIG9mIHdoYXQgaGFwcGVucyB3aGVuDQo+IG11bHRpcGxlIFVMQSBwcmVmaXhlcyBz aG93IHVwIGF1dG9tYXRpY2FsbHkgaW4gdGhlIHNhbWUgbmV0d29yay4gVGhhdA0KPiBtYXkgbm90 IGJlIHJlY29tbWVuZGVkIHByYWN0aWNlLCBidXQgaXQgc2VlbXMgdmVyeSBsaWtlbHkgdG8gaGFw cGVuLA0KPiBhbmQgcmFpc2VzIHJvdXRpbmcgYW5kIGFkZHJlc3Mtc2VsZWN0aW9uIHF1ZXN0aW9u cy4NCj4NCj4gSSB0aGluayB0aGUgdmFyaW91cyBXRyBDaGFpcnMgbmVlZCB0byBhZ3JlZSBob3cg dGhlIGRpc2N1c3Npb24gc2hvdWxkDQo+IGJlIG1hbmFnZWQsIGJlY2F1c2UgaXQgbWlnaHQgZ2V0 IGNvbXBsaWNhdGVkIHdpdGggdGhyZWUgV0dzIGludm9sdmVkDQo+IChvciBmb3VyLCBpZiB5b3Ug Y291bnQgNnJlbnVtKS4NCj4NCj4gUmVnYXJkcw0KPiAgICBCcmlhbg0KPg0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiB2Nm9wcyBtYWlsaW5nIGxp c3QNCj4gdjZvcHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby92Nm9wcw0KDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2htZW50cyBtYXkg Y29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbiwgd2hpY2gg aXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHlyaWdodCBiZWxv bmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVuZGVkIHNvbGVs eSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hpY2ggaXQgaXMg YWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IG9mIHRoaXMg RS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBk aXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlvbiB0byB0aGUg Y29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBF LW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlhdGVseSBhbmQg cGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2YgdGhpcyBFLW1h aWwgYW5kIGFueSBwcmludG91dC4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQp2Nm9wcyBtYWlsaW5nIGxpc3QNCnY2b3BzQGlldGYub3JnDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzDQo= From sgundave@cisco.com Sun Mar 25 03:12:34 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A6121F8594 for ; Sun, 25 Mar 2012 03:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.229 X-Spam-Level: X-Spam-Status: No, score=-8.229 tagged_above=-999 required=5 tests=[AWL=0.658, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315] 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 gM6i0Z0HQ0FX for ; Sun, 25 Mar 2012 03:12:31 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9D121F8589 for ; Sun, 25 Mar 2012 03:12:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=sgundave@cisco.com; l=9319; q=dns/txt; s=iport; t=1332670351; x=1333879951; h=date:subject:from:to:message-id:in-reply-to:mime-version; bh=9SWLIIL7hJdZOuIy+N94KsaQyD+E0qQC0c+1OowcoW4=; b=SKwoA/QO4CZ6eOiq+snxQgEcW+Icj/NZXPkVnyyag/FgXPrk2n2TAMtd 0PwGNJIWsJhqlY6V5jkM3JH7XFPI64Bjvk34IsyH3HuukFa5e0hnm0AIC aDI9AQAUECTVfkfT91imjkmLAEUbzFYdEV63HgwD8RYF1FqlpbVrmi2K0 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAGDvbk+rRDoJ/2dsb2JhbAA4CoJPtGV3gQeCCQEBAQMBEgEqNQwNAQgRBAEBKE0JCAEBBAESFA6HYwQBnlyWJ4peCYZBBIgkM40JjkWBaIMHgTw X-IronPort-AV: E=Sophos;i="4.73,646,1325462400"; d="scan'208,217";a="37476031" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 25 Mar 2012 10:12:30 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2PACU9t012168; Sun, 25 Mar 2012 10:12:30 GMT Received: from xmb-sjc-214.amer.cisco.com ([171.70.151.145]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Mar 2012 03:12:30 -0700 Received: from 10.21.66.101 ([10.21.66.101]) by xmb-sjc-214.amer.cisco.com ([171.70.151.145]) with Microsoft Exchange Server HTTP-DAV ; Sun, 25 Mar 2012 10:12:30 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Sun, 25 Mar 2012 03:12:00 -0700 From: Sri Gundavelli To: "George, Wes" , "v6ops@ietf.org" , Cameron Byrne Message-ID: Thread-Topic: [v6ops] Comments on draft-gundavelli-v6ops-community-wifi-svcs-03 Thread-Index: Ac0HzJ/WhR/2gF+/REWfL3S+CCuhkwByeDtAADZNr8I= In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3415489920_44985095" X-OriginalArrivalTime: 25 Mar 2012 10:12:30.0904 (UTC) FILETIME=[C9ED6B80:01CD0A6F] Subject: Re: [v6ops] Comments on draft-gundavelli-v6ops-community-wifi-svcs-03 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 10:12:34 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3415489920_44985095 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Wes/Cameron, I agree with your comments. The use of IPv6 should be a day-1 requirement; all the considerations around addressing models (Per mobile OR shared IPv6 prefix), IPv6 tunnel transport, or even IPv6-based control plane when used ... all are important considerations. I agree with this. Regards Sri On 3/24/12 5:58 AM, "George, Wes" wrote: > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of= Sri > Gundavelli > Sent: Wednesday, March 21, 2012 9:40 PM > To: Hui Deng; v6ops@ietf.org > Subject: Re: [v6ops] Comments on draft-gundavelli-v6ops-community-wifi-sv= cs-03 > =20 > how many million hotspots you guys have deployed last year ? The spec tri= es to > identify what it takes to enable that service, the protocol choice, mobil= ity > considerations, IPv6 transitioning and other aspects. We are still workin= g on > additional updates, that should complete all the IPv6 considerations. > [WEG] Allow me to provide some more specific feedback about what=B9s missin= g in > terms of IPv6 considerations. > =20 > A deployment of this type MUST be planning for IPv6 on day one, and we=B9d = be > doing a disservice to not explicitly state that so that those using this = as a > guide include this in their requirements to their vendors. > =20 > When you are deploying "millions of hotspots" you had better be prepared = to > manage them via IPv6... ONLY. By manage, I mean everything from remote > configuration, OSS/polling, software management, etc. > This also extends to if you are using something like GRE or L2TP tunnelin= g to > carry traffic from an AP back to a wifi core to manage mobility and other > things -- that tunneling MUST be done over IPv6. These deployments are si= mply > too large and there are already too many overlapping uses of 1918 space f= or it > to be realistic to think that it will be possible to give these APs even = one > IPv4 address for those uses. This consideration will seem very familiar t= o > those of us who have been on the wrong end of a discussion involving tryi= ng to > make 50K cell towers IP-reachable, and stunned to find out that key piece= s of > equipment and software say, =B3huh? What=B9s IPv6?=B2 > =20 > And of course, it MUST be able to carry IPv6 data from end hosts (the act= ual > users). While Wifi is a layer 2 protocol, there are enough interactions > between Layer 2 and 3 that IPv6 support should be explicitly indicated. I= 've > been personally burned by this in such a way as to not want to simply ass= ume > that it'll just work because wifi vendors will be smart enough to do the = right > thing. > =20 > Naturally, if you'd like to be backwards compatible, you SHOULD support I= Pv4 > for all of the above, but you MUST support IPv6 and you MUST NOT require = IPv4 > for proper and complete function. RFC6540 (in AUTH48) says more or less > exactly this. You're welcome to cite it :-) > =20 > Thanks, > Wes George >=20 >=20 > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely = for > the use of the individual or entity to which it is addressed. If you are = not > the intended recipient of this E-mail, you are hereby notified that any > dissemination, distribution, copying, or action taken in relation to the > contents of and attachments to this E-mail is strictly prohibited and may= be > unlawful. If you have received this E-mail in error, please notify the se= nder > immediately and permanently delete the original and any copy of this E-ma= il > and any printout. >=20 --B_3415489920_44985095 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [v6ops] Comments on draft-gundavelli-v6ops-community-wifi-svcs-0= 3 Hi Wes/Cameron,

I agree with your comments. The use of IPv6 should be a day-1 requirement; = all the considerations around addressing models (Per mobile OR shared IPv6 p= refix), IPv6 tunnel transport, or even IPv6-based control plane when used ..= . all are important considerations. I agree with this.


Regards
Sri



On 3/24/12 5:58 AM, "George, Wes" <wesley.george@twcable.com> wrote:

<= FONT SIZE=3D"2">From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf Of Sri Gundavelli Sent: Wednesday, March 21, 2012 9:40 PM
To: Hui Deng; v6ops@ietf.org
Subject: Re: [v6ops] Comments on draft-gundavelli-v6ops-community-wi= fi-svcs-03
how many million hotspots you guys have deployed last year ?= The spec tries to identify what it takes to enable that service, the protoc= ol choice, mobility considerations, IPv6 transitioning and other aspects. We= are still working on additional updates, that should complete all the IPv6 = considerations.
[WEG] Allow me to provide some more specific feedback about what&= #8217;s missing in terms of IPv6 considerations.
 
A deployment of this type MUST be planning for IPv6 on day one, and we̵= 7;d be doing a disservice to not explicitly state that so that those using t= his as a guide include this in their requirements to their vendors.
 
When you are deploying "millions of hotspots" you had better be p= repared to manage them via IPv6... ONLY. By manage, I mean everything from r= emote configuration, OSS/polling, software management, etc.
This also extends to if you are using something like GRE or L2TP tunneling = to carry traffic from an AP back to a wifi core to manage mobility and other= things -- that tunneling MUST be done over IPv6. These deployments are simp= ly too large and there are already too many overlapping uses of 1918 space f= or it to be realistic to think that it will be possible to give these APs ev= en one IPv4 address for those uses. This consideration will seem very famili= ar to those of us who have been on the wrong end of a discussion involving t= rying to make 50K cell towers IP-reachable, and stunned to find out that key= pieces of equipment and software say, “huh? What’s IPv6?”=
 
And of course, it MUST be able to carry IPv6 data from end hosts (the actua= l users). While Wifi is a layer 2 protocol, there are enough interactions be= tween Layer 2 and 3 that IPv6 support should be explicitly indicated. I've b= een personally burned by this in such a way as to not want to simply assume = that it'll just work because wifi vendors will be smart enough to do the rig= ht thing.
 
Naturally, if you'd like to be backwards compatible, you SHOULD support IPv= 4 for all of the above, but you MUST support IPv6 and you MUST NOT require I= Pv4 for proper and complete function. RFC6540 (in AUTH48) says more or less = exactly this. You're welcome to cite it :-)
 
Thanks,
Wes George

= This E-mail a= nd any of its attachments may contain Time Warner Cable proprietary informat= ion, which is privileged, confidential, or subject to copyright belonging to= Time Warner Cable. This E-mail is intended solely for the use of the indivi= dual or entity to which it is addressed. If you are not the intended recipie= nt of this E-mail, you are hereby notified that any dissemination, distribut= ion, copying, or action taken in relation to the contents of and attachments= to this E-mail is strictly prohibited and may be unlawful. If you have rece= ived this E-mail in error, please notify the sender immediately and permanen= tly delete the original and any copy of this E-mail and any printout.

--B_3415489920_44985095-- From dthaler@microsoft.com Sun Mar 25 09:49:57 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E02721F84A5 for ; Sun, 25 Mar 2012 09:49:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.592 X-Spam-Level: X-Spam-Status: No, score=-103.592 tagged_above=-999 required=5 tests=[AWL=-0.593, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, 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 7XmV3fp02JUa for ; Sun, 25 Mar 2012 09:49:56 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id A29B121F84A6 for ; Sun, 25 Mar 2012 09:49:56 -0700 (PDT) Received: from mail150-va3-R.bigfish.com (10.7.14.237) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.23; Sun, 25 Mar 2012 16:49:44 +0000 Received: from mail150-va3 (localhost [127.0.0.1]) by mail150-va3-R.bigfish.com (Postfix) with ESMTP id 56B841404BF; Sun, 25 Mar 2012 16:49:44 +0000 (UTC) X-SpamScore: -35 X-BigFish: VS-35(zz9371I542M1432N98dKzz1202hzz1033IL8275bhz2fh2a8h668h839h944hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail150-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail150-va3 (localhost.localdomain [127.0.0.1]) by mail150-va3 (MessageSwitch) id 133269418291723_30119; Sun, 25 Mar 2012 16:49:42 +0000 (UTC) Received: from VA3EHSMHS002.bigfish.com (unknown [10.7.14.243]) by mail150-va3.bigfish.com (Postfix) with ESMTP id 04E87300049; Sun, 25 Mar 2012 16:49:42 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS002.bigfish.com (10.7.99.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 25 Mar 2012 16:49:39 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.2.283.4; Sun, 25 Mar 2012 16:49:48 +0000 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.57]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0283.004; Sun, 25 Mar 2012 09:49:48 -0700 From: Dave Thaler To: "Hemant Singh (shemant)" , "v6ops@ietf.org" Thread-Topic: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) Thread-Index: AQHNBaiYFDpGjhip9E+2dki3iWZ80ZZ7QXwg Date: Sun, 25 Mar 2012 16:49:48 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B4C2059@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> References: Your message of Mon, 19 Mar 2012 08:44:46 +0100. <94C682931C08B048B7A8645303FDC9F36E28557C68@PUEXCB1B.nanterre.francetelecom.fr> <201203190816.q2J8GXsi097549@givry.fdupont.fr> In-Reply-To: <201203190816.q2J8GXsi097549@givry.fdupont.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CRA-Verdict: 131.107.125.8$juniper.net%12218%4%microsoft.com%False%False%0$ X-OriginatorOrg: microsoft.com Cc: Alain Durand , "Dan Wang \(danwan\)" Subject: Re: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 16:49:57 -0000 > -----Original Message----- > From: Francis.Dupont@fdupont.fr [mailto:Francis.Dupont@fdupont.fr] > Sent: Monday, March 19, 2012 9:17 AM > To: mohamed.boucadair@orange.com > Cc: Hemant Singh (shemant); v6ops@ietf.org; Alain Durand; Dan Wang > (danwan); Dave Thaler > Subject: Re: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) >=20 > In your previous mail you wrote: >=20 > > >=3D> I am still strongly opposed to this SHOULD for PCP. > > >For the other comments I'll consider this is nevertheless kept. > > > > Med: The requirement is coherent with the requriement in the > > server's side specified in draft-behave-lsn-*. >=20 > =3D> the v6ops spec is supposed to be used in the real world so has more > constraints than draft-behave*. >=20 > > >> In DS-Lite context, if PCP messages are exchanged using native > > >> IPv6 (i.e., IPv4-in-IPv6 is not used) and no PCP server is > > >> configured, the PCP client MUST use the address of the AFTR as > > >> its PCP server. > > > > > >=3D> it is bad, I propose: > > > > Med: The text is generic on purpose and it applies to both PCP > > encapsulation mode and IPv6 plain mode. Selecting between these two > > modes is deployment-specific. I don't see a reason to cite your draft > > here. >=20 > =3D> for me it looks like an attempt to overrule a choice which is in the= scope of > the PCP WG and this WG only. > Note without a particular requirement for PCP none of the details about h= ow > to use PCP is needed. To add to that, I don't believe it is appropriate for 6204bis to make state= ments=20 about how to use PCP that are not in a normative reference. As MED mentio= ned, PCP proxy is not a normative reference so cannot be required in this iterat= ion. Similarly I don't believe discussion of how to use PCP with DS-Lite is appr= opriate in 6204bis itself either. It should only state what normative references = are required and leave details on how they work to the normative references. -Dave From shemant@cisco.com Sun Mar 25 10:18:51 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A8FE21F8448 for ; Sun, 25 Mar 2012 10:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.942 X-Spam-Level: X-Spam-Status: No, score=-9.942 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 WOOo1GvQQH0D for ; Sun, 25 Mar 2012 10:18:50 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 7276D21F8447 for ; Sun, 25 Mar 2012 10:18:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=shemant@cisco.com; l=10650; q=dns/txt; s=iport; t=1332695930; x=1333905530; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=OQ8BLXJ6dCpvEcTPbCdEjhlQQOYgwANaGpT2tZpbGXg=; b=d79HV1/HDW2UvUmPX+e7XqwaFbN4b6jH/xwTtqirkUn8Ldwi6DpmlXYE p2bVyR3LHDNoQ6fqg1vMzHf/VigTYhAyqiFuXaq6KvbQkYUstnyMjcbC9 GyrjW/uqJ7oHRlmme1hMweoP3jf5Bq3N4wuAkkzt3+VNBoCXxpWqADJZo w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAClTb0+tJV2a/2dsb2JhbABEgka1XoEHggkBAQEEEgEJEQNJDAQCAQgOAwQBAQsGFwEGAUUIAQgCBAESCBqHaJl0ngyQRWMEiFebToFogwU X-IronPort-AV: E=Sophos;i="4.73,646,1325462400"; d="scan'208,217";a="69240521" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP; 25 Mar 2012 17:18:47 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2PHIloq020386; Sun, 25 Mar 2012 17:18:47 GMT Received: from xmb-rcd-109.cisco.com ([72.163.62.151]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Mar 2012 12:18:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD0AAB.565D1028" Date: Sun, 25 Mar 2012 12:18:45 -0500 Message-ID: <5B6B2B64C9FE2A489045EEEADDAFF2C30444B34A@XMB-RCD-109.cisco.com> In-Reply-To: <9B57C850BB53634CACEC56EF4853FF653B4C2059@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) Thread-Index: AQHNBaiYFDpGjhip9E+2dki3iWZ80ZZ7QXwggAAHScA= References: Your message of Mon, 19 Mar 2012 08:44:46 +0100. <94C682931C08B048B7A8645303FDC9F36E28557C68@PUEXCB1B.nanterre.francetelecom.fr> <201203190816.q2J8GXsi097549@givry.fdupont.fr> <9B57C850BB53634CACEC56EF4853FF653B4C2059@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> From: "Hemant Singh (shemant)" To: "Dave Thaler" , X-OriginalArrivalTime: 25 Mar 2012 17:18:47.0530 (UTC) FILETIME=[56C8D4A0:01CD0AAB] Cc: Alain Durand , "Dan Wang \(danwan\)" Subject: Re: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC) X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 17:18:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CD0AAB.565D1028 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dave, =20 -----Original Message----- From: Dave Thaler [mailto:dthaler@microsoft.com]=20 Sent: Sunday, March 25, 2012 12:50 PM To: Hemant Singh (shemant); v6ops@ietf.org Cc: Alain Durand; Dan Wang (danwan) Subject: RE: [v6ops] FW: PCP (RE: draft-ietf-v6ops-6204bis WGLC)=20 =20 =20 >To add to that, I don't believe it is appropriate for 6204bis to make statements=20 >about how to use PCP that are not in a normative reference. As MED mentioned, >PCP proxy is not a normative reference so cannot be required in this iteration. >Similarly I don't believe discussion of how to use PCP with DS-Lite is appropriate >in 6204bis itself either. It should only state what normative references are >required and leave details on how they work to the normative references. =20 Appreciate the comments. I mostly agree with you. There is one caveat in that rfc6204bis is specifying requirements for a single device in the IPv6 CE Router and thus rfc6204bis has some flexibility to tighten the rules specified in a protocol that is being used in the requirement. Since you have a slide to be presented in the PCP session tomorrow, we can wait and see the outcome of that discussion. The rfc6204bis v6ops presentation may also move to Thursday. For reference, the current PCP text in rfc6204bis is included below. =20 W-6: The WAN interface of the CE router SHOULD support a PCP client as specified in [I-D.ietf-pcp-base] for use by applications on the CE Router. The PCP client SHOULD follow the procedure specified in Section 8.1 of [I-D.ietf-pcp-base] to discover its PCP server. This document takes no position on whether such functionality is enabled by default or mechanisms by which users would configure the functionality. Handling PCP requests from PCP clients in the LAN side of the CE Router is out of scope. =20 W-7: In DS-Lite context, if PCP messages are exchanged using native IPv6 (i.e., IPv4-in-IPv6 is not used) and no PCP server is configured, the PCP client MUST use the address of the AFTR as its PCP server. =20 Thanks, =20 Hemant =20 =20 ------_=_NextPart_001_01CD0AAB.565D1028 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dave,

 

-----Original Message-----
From: = Dave Thaler [mailto:dthaler@microsoft.com]
Sent: Sunday, March 25, = 2012 12:50 PM
To: Hemant Singh (shemant); v6ops@ietf.org
Cc: Alain = Durand; Dan Wang (danwan)
Subject: RE: [v6ops] FW: PCP (RE: = draft-ietf-v6ops-6204bis WGLC)

 

 

>To = add to that, I don't believe it is appropriate for 6204bis to make = statements

>about how to use PCP that are = not in a normative reference.   As MED = mentioned,

>PCP proxy is not a normative = reference so cannot be required in this = iteration.

>Similarly I don't believe = discussion of how to use PCP with DS-Lite is = appropriate

>in 6204bis itself = either.   It should only state what normative references = are

>required and leave details on = how they work to the normative references.

 

Appreciate the = comments.  I mostly agree with you.  There is one caveat in = that rfc6204bis is specifying requirements for a single device in the = IPv6 CE Router and thus rfc6204bis has some flexibility to tighten the = rules specified in a protocol that is being used in the = requirement.   Since you have a slide to be presented in the = PCP session tomorrow, we can wait and see the outcome of that = discussion.  The rfc6204bis v6ops presentation may also move to = Thursday.  For reference, the current PCP text in rfc6204bis is = included below.

 

W-6:  The WAN interface of the CE router SHOULD = support a PCP client

         as = specified in [I-D.ietf-pcp-base] for use by applications = on

         the = CE Router.  The PCP client SHOULD follow the = procedure

         = specified in Section 8.1 of [I-D.ietf-pcp-base] to discover = its

         PCP = server.  This document takes no position on whether = such

         = functionality is enabled by default or mechanisms by = which

         users = would configure the functionality.  Handling PCP = requests

         from = PCP clients in the LAN side of the CE Router is out = of

         = scope.

 

   W-7:  In DS-Lite context, if PCP = messages are exchanged using native

         IPv6 = (i.e., IPv4-in-IPv6 is not used) and no PCP server = is

         = configured, the PCP client MUST use the address of the AFTR = as

         its = PCP server.

 

Thanks,

 

Hemant 

 

------_=_NextPart_001_01CD0AAB.565D1028-- From Francis.Dupont@fdupont.fr Sun Mar 25 23:49:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D39921E8089 for ; Sun, 25 Mar 2012 23:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.239 X-Spam-Level: X-Spam-Status: No, score=-2.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_13=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 M1EbcpBg85Qj for ; Sun, 25 Mar 2012 23:49:24 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id F077D21E808F for ; Sun, 25 Mar 2012 23:49:23 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2Q6nKU6006277; Mon, 26 Mar 2012 08:49:21 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203260649.q2Q6nKU6006277@givry.fdupont.fr> From: Francis Dupont To: mohamed.boucadair@orange.com In-reply-to: Your message of Mon, 19 Mar 2012 15:53:16 +0100. <94C682931C08B048B7A8645303FDC9F36E28557F30@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 26 Mar 2012 08:49:20 +0200 Sender: Francis.Dupont@fdupont.fr Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 6204bis W-6 new text proposal X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 06:49:24 -0000 In your previous mail you wrote: > Could you please explain why? Thanks. => I explained it many time: W-7 is in the scope of the PCP WG, it has nothing to do in a v6ops document. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Sun Mar 25 23:51:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6525621F84AA for ; Sun, 25 Mar 2012 23:51:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 XBpiG4l4ouFt for ; Sun, 25 Mar 2012 23:51:53 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id A76B321F84A6 for ; Sun, 25 Mar 2012 23:51:52 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2Q6pobM006421; Mon, 26 Mar 2012 08:51:50 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203260651.q2Q6pobM006421@givry.fdupont.fr> From: Francis Dupont To: mohamed.boucadair@orange.com In-reply-to: Your message of Mon, 19 Mar 2012 15:56:58 +0100. <94C682931C08B048B7A8645303FDC9F36E28557F35@PUEXCB1B.nanterre.francetelecom.fr> Date: Mon, 26 Mar 2012 08:51:50 +0200 Sender: Francis.Dupont@fdupont.fr Cc: "v6ops@ietf.org" Subject: Re: [v6ops] 6204bis W-6 new text proposal X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 06:51:53 -0000 In your previous mail you wrote: > A concrete example is a user-interface (application) to configure mappings = > (e.g., for a webcam, a local server) or even an IGD-PCP IWF... => this is clearly at the benefit of hosts connected to the CPE so was already discussed and agreed to not add to the requirements. So please show an application genuine to the CPE which needs W-6. Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Mon Mar 26 00:00:23 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB04621E8034 for ; Mon, 26 Mar 2012 00:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, 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 OSHjzdh91fFq for ; Mon, 26 Mar 2012 00:00:23 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id 034F621F844F for ; Mon, 26 Mar 2012 00:00:22 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2Q6wumV006874; Mon, 26 Mar 2012 08:58:56 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203260658.q2Q6wumV006874@givry.fdupont.fr> From: Francis Dupont To: Ray Hunter In-reply-to: Your message of Mon, 19 Mar 2012 17:52:28 +0100. <4F67644C.3070007@globis.net> Date: Mon, 26 Mar 2012 08:58:56 +0200 Sender: Francis.Dupont@fdupont.fr Cc: v6ops@ietf.org Subject: Re: [v6ops] 6204bis W-6 new text proposal X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 07:00:24 -0000 In your previous mail you wrote: > +1 on disagreeing proposed W-6 text. > > IMHO An LSN will likely be a shared resource located deep within the > Internet infrastructure, so no individual end user nor single > organization will likely have sufficient power to unilaterally specify > which control protocol is preferred for both client and server. Inbound > access is also a function that should be available to all Internet users. > > Any specification stating "client MAY support X OR Y" effectively > implies in practice that the server (in this case the client is clearly > targeted for future use with LSN) "MUST support X AND Y" in order for > the desired functionality (inbound access) to be available to all users. > > Proposed text, which includes the wording "such as", would also not rule > out having to support protocol Z (or anything else similar to X or Y) on > the server side. > > I'm neutral on the choice of protocol(s), but having too many protocols > covering the same function would likely be harmful in this case. => but we have no base for an arbitrary choice of one protocol. As this requirement (W-6) has a dubious usage and not in the original RFC 6204 perhaps the simplest is to remove it from 6204bis and to reconsider it for 6204ter (or later). Regards Francis.Dupont@fdupont.fr From Francis.Dupont@fdupont.fr Mon Mar 26 00:03:18 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8C521F8454 for ; Mon, 26 Mar 2012 00:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 A3FFjp5w7tmW for ; Mon, 26 Mar 2012 00:03:18 -0700 (PDT) Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by ietfa.amsl.com (Postfix) with ESMTP id F2DAB21F842A for ; Mon, 26 Mar 2012 00:03:17 -0700 (PDT) Received: from givry.fdupont.fr (localhost [127.0.0.1]) by givry.fdupont.fr (8.14.3/8.14.3) with ESMTP id q2Q73F0s007302; Mon, 26 Mar 2012 09:03:15 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr) Message-Id: <201203260703.q2Q73F0s007302@givry.fdupont.fr> From: Francis Dupont To: "Hemant Singh (shemant)" In-reply-to: Your message of Mon, 19 Mar 2012 12:36:54 EST. <5B6B2B64C9FE2A489045EEEADDAFF2C3043A25B9@XMB-RCD-109.cisco.com> Date: Mon, 26 Mar 2012 09:03:15 +0200 Sender: Francis.Dupont@fdupont.fr Cc: Ray Hunter , v6ops@ietf.org Subject: Re: [v6ops] 6204bis W-6 new text proposal X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 07:03:18 -0000 In your previous mail you wrote: > Med and I agree on this text below. Does that work for you? => in the case you are interested by my opinion, it doesn't work for me. Regards Francis.Dupont@fdupont.fr From victor.kuarsingh@gmail.com Mon Mar 26 04:41:48 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83BE821F85B1 for ; Mon, 26 Mar 2012 04:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_6CONS_WORD=0.356] 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 ZiNhyNpVkkvB for ; Mon, 26 Mar 2012 04:41:47 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id B669F21F8646 for ; Mon, 26 Mar 2012 04:41:43 -0700 (PDT) Received: by wibhq7 with SMTP id hq7so3466185wib.13 for ; Mon, 26 Mar 2012 04:41:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic:in-reply-to :mime-version:content-type:content-transfer-encoding; bh=zV6oNVMTEGlqU1vHaAoWuQ54iL/FL95w5t7Lk/c+pTI=; b=MB+3IPtkSM0iiGadHXroIYR6Q52s9Sf1z69sGAir535r9RK2dewgWF2hPISuCAWMgA THWIbzd3uRGQzNzQ5Imd3lefnRAMA31s0GK+/mA30RCAJxi/MG/0J42n0dEWmDZDsfVi AipmXATTyOstr6yL74QcXOteA6bWMme07rkOTrvlyU3Mk8WO4LsA5ajOtApN2otYWhvP /Od7V6DVp1a3KJ51SkgIx4IBKHiAFdtGZymcc1I+KoPOoc8Efrj80syQqcaQgXDY5mL3 e8ramHR4K/Dl2DQhRsRK4VLPvdP2bY44fGEn507WNLk+7KtobN4pRi+Q7RdMxNbLY0sQ 1Vlg== Received: by 10.180.81.166 with SMTP id b6mr17902450wiy.0.1332762101065; Mon, 26 Mar 2012 04:41:41 -0700 (PDT) Received: from [10.59.90.251] (access-50.80.rev.fr.colt.net. [213.41.80.50]) by mx.google.com with ESMTPS id o2sm66074348wiv.11.2012.03.26.04.41.39 (version=SSLv3 cipher=OTHER); Mon, 26 Mar 2012 04:41:40 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Mon, 26 Mar 2012 13:41:39 +0200 From: Victor Kuarsingh To: IPv6 Operations Message-ID: Thread-Topic: [v6ops] draft-chkpvc-enterprise-incremental-ipv6-00 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [v6ops] draft-chkpvc-enterprise-incremental-ipv6-00 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 11:41:48 -0000 IPv6 WG, I would like to kick off some comments on this draft for other group members to comment. I do think (Bias noted) that this material is useful for Enterprises who need to being and/or move their IPv6 deployments. Many (of those I have worked with thus far) are bogged down with personnel who are overwhelmed with what it may take to get IPv6 moving on their networks. The draft breaks the challenge down by areas of focus (rolled into "Phases") which can help put this large challenge into bite size chunks for them. The draft also provides some valid contextual information around IPv6 and highlights areas which should be looked at. Given the good momentum we now have in the operator space, it would be good to see this move forward into the Enterprise space. I think such documents can help many of those still waffling (too many to count) to start acting. Regards, Victor K On 12-03-22 8:02 AM, "Tim Chown" wrote: >Hi, > >Due to a typo in the draft name, this draft didn't hit Fred's automated >WG tools, so the authors would like to raise the draft on the list now >with a view to securing a slot in Paris to discuss its value and content. > >In Taipei there was a comment in the WG session that there is no >up-to-date v6ops guidance on enterprise networks, while other scenarios >do have such texts. So at the mic I invited people to join an effort to >put something together. There is a good breadth of experience across the >people who stepped forward, and the result is available as > http://www.ietf.org/id/draft-chkpvc-enterprise-incremental-ipv6-00.txt > >Does the WG think the subject matter of this draft is one we should >pursue in the WG? If so, is the structure and content appropriate? We >need some positive feedback and comments in order for Fred to schedule us >time in Paris. > >We have had a couple of people contact us off-list offering to help >develop the content. But we'd like some feedback from the WG before >investing more time in doing so. The -00 text is somewhat "rough", but >we feel it could be polished into something quite useful for the >community. > >Tim > >_______________________________________________ >v6ops mailing list >v6ops@ietf.org >https://www.ietf.org/mailman/listinfo/v6ops From fred@cisco.com Mon Mar 26 19:34:53 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A56E21E8028 for ; Mon, 26 Mar 2012 19:34:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.251 X-Spam-Level: X-Spam-Status: No, score=-110.251 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 tm+Qvzw85Z0D for ; Mon, 26 Mar 2012 19:34:52 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 29A5321E804E for ; Mon, 26 Mar 2012 19:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=4307; q=dns/txt; s=iport; t=1332815692; x=1334025292; h=mime-version:subject:from:date:cc:message-id:to: content-transfer-encoding; bh=eJGoSjeah2Q1XIQ8tdUAbwgp6rcpFa1VVDCN+htpf98=; b=Svsw0CKJGqui5Qb88aSVqfQNe++y/zRNS7+TiiEjQh9s+3sH8vMhdl9o cq1GAfBQdu4HBFpWQ/MqAtzPUCEp+3//4vZMLMxiOBzMmPOoQ4yvbYAXK Xisb4UY3a12e8/zV6/tOm0M5SziDKtc/OcbnFiJsQuUcRuLkLl+J1aDdK I=; X-IronPort-AV: E=Sophos;i="4.73,654,1325462400"; d="scan'208";a="133424636" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 27 Mar 2012 02:34:51 +0000 Received: from Freds-Computer.local (dhcp-10-61-97-224.cisco.com [10.61.97.224]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q2R2YlbX009270; Tue, 27 Mar 2012 02:34:47 GMT Received: from [127.0.0.1] by Freds-Computer.local (PGP Universal service); Tue, 27 Mar 2012 04:34:50 +0200 X-PGP-Universal: processed; by Freds-Computer.local on Tue, 27 Mar 2012 04:34:50 +0200 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker Date: Tue, 27 Mar 2012 04:34:32 +0200 Message-Id: To: draft-ietf-v6ops-464xlat@tools.ietf.org X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , Softwire Chairs , v6ops-ads@tools.ietf.org Subject: [v6ops] A way forward for 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 02:34:53 -0000 I won't say "chair hat off", but "chair hat fashionably tipped to one = side." I'm trying to figure out the best way forward for the 464XLAT = specification in view of comments by the authors of=20 http://datatracker.ietf.org/doc/draft-despres-softwire-4rd-u http://datatracker.ietf.org/doc/draft-fu-softwire-4rd-mib http://datatracker.ietf.org/doc/draft-fu-softwire-map-mib http://datatracker.ietf.org/doc/draft-jiang-softwire-map-radius = http://datatracker.ietf.org/doc/draft-mdt-softwire-map-deployment = http://datatracker.ietf.org/doc/draft-mdt-softwire-map-dhcp-option = http://datatracker.ietf.org/doc/draft-mdt-softwire-map-encapsulation = http://datatracker.ietf.org/doc/draft-mdt-softwire-map-translation = http://datatracker.ietf.org/doc/draft-mdt-softwire-mapping-address-and-por= t http://datatracker.ietf.org/doc/draft-murakami-softwire-4rd = http://datatracker.ietf.org/doc/draft-sarikaya-softwire-4rdmulticast and notably the comments in the working group meeting Monday morning. = Why do I comment on the "chair hat"? Well, I'm not "giving instruction", = as chair; I'm floating an idea. If the idea is acceptable, the idea may = become instruction; if it needs to be modified, I want to have that = conversation. The objections raised in the working group come down to: - the authors of said other documents would like to have a = conversation with the 464XLAT folks - What's this about a prefix::/96? - What's this about a proxy service? - What's this about normative language? - How does it fit the the mdt-softwire-map specifications, which appear to have a growing consensus behind them in softwire? Before you continue reading this note, please stop and read these two = sections: http://tools.ietf.org/html/rfc2026#section-4.2.2 http://tools.ietf.org/html/rfc2026#section-5 =46rom my perspective, and from reading those definitions, an = Informational Document is a white paper, while a BCP is something that a = significant and relevant part of the Internet COmmunity agrees to, and ...since the Internet itself is composed of networks operated by a great variety of organizations, with diverse goals and rules, good user service requires that the operators and administrators of the Internet follow some common guidelines for policies and operations. In other words, operational service models, while not strictly speaking = "protocols", can be described in a BCP *standard* as "how to implement a = certain service". This is in no sense "the best" or "only way to deploy = RFCs 6145/6146", but it might be "the best way to deploy the CLAT = service". v6ops is authorized, by charter, to write informational and = BCP documents. And since a BCP describes the set of things that one MUST or SHOULD do = in deploying such a service, RFC 2119 language regarding that specific = service may be acceptable in a BCP describing that service. With that preparatory reasoning, it seems to me that we need to separate = the contentious parts of the specification so that uncontentious parts = can go forward, and other parts can be discussed - whether in this = working group or another one. Given the points of contention, it seems that the separation needs to be = among three documents. The first is a specification - a BCP - for the CLAT service. It refers = to RFCs 6052/6144/6145/6146/6147, and describes how translation is used = in this context using normative language. It does not refer to a = prefix::/96; it refers to RFC 6052. My understanding is that several = people have said that this specification is interesting and useful. The second is a separate specification for the proxy service, which is = contentious. Being separated, it can be discussed and beaten to death as = needed. The first specification says that the CLAT service MAY implement = this proxy service. I'm not sure whether that is BCP or Informational; = we can discuss that in the context of the rest of the discussion of the = proxy service. The third is a report on the trial deployment of the CLAT service by the = various companies in question. This is an informational document. Am I making sense? Would this be an acceptable way forward?= From cb.list6@gmail.com Mon Mar 26 21:25:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD19A21E805E for ; Mon, 26 Mar 2012 21:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-1.471, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315] 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 89x-Tf36Zxv1 for ; Mon, 26 Mar 2012 21:25:08 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7D321E8053 for ; Mon, 26 Mar 2012 21:25:07 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so7147116pbb.31 for ; Mon, 26 Mar 2012 21:25:07 -0700 (PDT) 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:content-transfer-encoding; bh=ceTboG5reJs2jgGnc57bCmgrU/R1eztdWFaS7zFS5D8=; b=m03xQSfLtBfsH2sJPXfgscwxcnuHEH2UQu2dLzAFvSjnoS71dlqGLHszik2G7X0EIm WBvbukV+85/LKPJdSBmqnCCB91N+jRV5xjFs8E4hWfQC1HR7f9CblIp8PBbF4ZwELej9 DefMnDTGIir3wZtMUki6XF1/kdBuT5fjSSnXBLhA1/oipF/VArGvnSARx7F6zh+Eer0V tJc+N3Py5NNyhKiBI6fyw8D2Gi0lqdS1VSWeLI9YAxmRwi0ehr/2y8m0kfV4o7BfWPl9 TUClFKdDD+T7dPFYWJhS+Bpcf85JNrro0cHRd0+tYJEhUxRMtDc6ZDXNe/Ka2gZRGk2e zKYw== MIME-Version: 1.0 Received: by 10.68.220.39 with SMTP id pt7mr21502582pbc.166.1332822306959; Mon, 26 Mar 2012 21:25:06 -0700 (PDT) Received: by 10.143.160.13 with HTTP; Mon, 26 Mar 2012 21:25:06 -0700 (PDT) In-Reply-To: References: Date: Mon, 26 Mar 2012 21:25:06 -0700 Message-ID: From: Cameron Byrne To: Fred Baker Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , Softwire Chairs , v6ops-ads@tools.ietf.org, draft-ietf-v6ops-464xlat@tools.ietf.org Subject: Re: [v6ops] A way forward for 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 04:25:10 -0000 Fred, Speaking for myself, as i have not consulted with my co-authors prior to writing this. On Mon, Mar 26, 2012 at 7:34 PM, Fred Baker wrote: > I won't say "chair hat off", but "chair hat fashionably tipped to one sid= e." I'm trying to figure out the best way forward for the 464XLAT specifica= tion in view of comments by the authors of > > =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-despres-softwire-4rd= -u > =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-fu-softwire-4rd-mib > =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-fu-softwire-map-mib > =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-jiang-softwire-map-r= adius > =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-mdt-softwire-map-dep= loyment > =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-mdt-softwire-map-dhc= p-option > =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-mdt-softwire-map-enc= apsulation > =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-mdt-softwire-map-tra= nslation > =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-mdt-softwire-mapping= -address-and-port > =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-murakami-softwire-4r= d > =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-sarikaya-softwire-4r= dmulticast > > and notably the comments in the working group meeting Monday morning. Why= do I comment on the "chair hat"? Well, I'm not "giving instruction", as ch= air; I'm floating an idea. If the idea is acceptable, the idea may become i= nstruction; if it needs to be modified, I want to have that conversation. > > The objections raised in the working group come down to: > =A0 =A0- the authors of said other documents would like to have a convers= ation with the 464XLAT folks > =A0 =A0- What's this about a prefix::/96? The /96 is defined here http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-01#section-6.1 We chose to use a /96 instead of all the possible variants within RFC6052 since it is the common and logical way to deploy uniformly, and this predictability allows draft-ietf-behave-nat64-discovery-heuristic to execute quicker and the devices within the 464XLAT architecture to operate more smoothly since the prefix size is known ahead of time. Constraining RFC6052 seems like a logical step that is prudent, why have variables in places they are not needed?? To this list, there has been no scenario presented where /96 is harmful in 464XLAT scenarios, aside from Woj... i believe his concerns were that CLAT with /96 will clash with his MAP-T CPE, which requires /128. MAP-T is not a dependency for 464XLAT. If it is the WG consensus that the /96 section be removed, it shall be removed. If it is just Woj and he is only concerned about MAP-T, i don't see that is WG consensus or in scope. This much should be well documented in the mailing list archives. > =A0 =A0- What's this about a proxy service? I assume you mean DNS proxy http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-01#section-6.4 It was discussed on this list a few times. I believe the WG understood the idea and some clarifying language was added to 01 rev. But, the DNS proxy functions is yet another logical thing that an operator would want. It is not required, and if the WG requires it to be removed, that section too can be deleted. It is my understanding that many CPE today set themselves as the DNS server and proxy DNS to the ISP DNS server, that is all that is being done here. The goal is saving DNS queries from having to go across the stateful PLAT from IPv4 clients by having the CPE proxy the IPv4 request as a native IPv6 query to the native IPv6 DNS server without crossing the PLAT. > =A0 =A0- What's this about normative language? RFC2119 language was removed in the 01 rev. Woj, i believe, is still thinking that the /96 constrains RFC6052, and that constitutes normative language. I disagree with his logic, but once again, the WG has the choice to make a call here and that call will be reflected in the draft. My hope is that the decisions are driven based on operator needs for operating a 464XLAT architecture, not on interoperability with an alternate transition solutions. > =A0 =A0- How does it fit the the mdt-softwire-map specifications, which > =A0 =A0 =A0appear to have a growing consensus behind them in softwire? > Yes, i follow softwires. Anyhow, as stated here http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-00#section-4 In summary, the 464XLAT architecture works today for service providers that require large-scale strategic IPv6 deployments to overcome the challenges of IPv4 address scarcity. Unlike other transition architectures associated with tunneling or [I-D.mdt-softwire-mapping-address-and-port], 464XLAT properly assumes that IPv4 is scarce and IPv6 must work with today's existing systems as much as possible. In the case of tunneling, the tunneling solutions like Dual-Stack Lite [RFC6333] are known to break existing network based deep packet inspection solutions like 3GPP standardized Policy and Charging Control (PCC). 464XLAT does not require much IPv4 address space to enable the stateful translation [RFC6146] function in the PLAT while providing global IPv4 and IPv6 reachability to IPv6-only wireline and wireless subscribers. It is also worth noting that 464XLAT allows for port-overloading, meaning that 1 IPv4 address can support millions (n * 64,000 ports) of translations sessions, which MAP cannot do. This is a very important point that should not be taken lightly. New entrants may only get /22s in APNIC today and in RIPE very soon, after that ... they can get nothing unless you pay some private party $$$$ for something they acquired for free. It is not possible to, for example, launch a new LTE service in large country using stateless translation... the benefits of IPv4 address fixed sharing (MAP) vs statistical multiplexing (NAPT) vs statistical multiplexing and overloading (NAPT * N) should be clear w.r.t scaling. It is a matter of being in business or not being in business..... and if the LEC / PTT has all the IPv4 address since creation... and you are a new entrant... well, you are at a substantial disadvantage... unless you can get a small chunk of IPv4 and overload such that each IPv4 address can support millions of sessions. And, 464XLAT does not rely on stateful DHCP. This is important to me since 3GPP does not support any stateful DHCP solutions. "Stateful DHCPv6-based address configuration [RFC3315] is not supported by 3GPP specifications." http://tools.ietf.org/html/rfc6459#section-5.2 So, MAP solutions do not fit 3GPP (GSM/UMTS/LTE) networks, AFAIK. On the other hand, what we have specified in 464XLAT demonstrably works in 3GPP networks. It also demonstrably works in wireline networks, and will be needed in any network where aggregate subscribers sessions exceed IPv4 holdings available for CGN * 64,000 > Before you continue reading this note, please stop and read these two sec= tions: > =A0 =A0http://tools.ietf.org/html/rfc2026#section-4.2.2 > =A0 =A0http://tools.ietf.org/html/rfc2026#section-5 > ACK, what stands out most for me is that informational documents are "timel= y". > From my perspective, and from reading those definitions, an Informational= Document is a white paper, while a BCP is something that a significant and= relevant part of the Internet COmmunity agrees to, and > > ...since the Internet itself is composed of networks operated by a great > =A0 variety of organizations, with diverse goals and rules, good user > =A0 service requires that the operators and administrators of the > =A0 Internet follow some common guidelines for policies and operations. > > In other words, operational service models, while not strictly speaking "= protocols", can be described in a BCP *standard* as "how to implement a cer= tain service". This is in no sense "the best" or "only way to deploy RFCs 6= 145/6146", but it might be "the best way to deploy the CLAT service". v6ops= is authorized, by charter, to write informational and BCP documents. > > And since a BCP describes the set of things that one MUST or SHOULD do in= deploying such a service, RFC 2119 language regarding that specific servic= e may be acceptable in a BCP describing that service. > > > With that preparatory reasoning, it seems to me that we need to separate = the contentious parts of the specification so that uncontentious parts can = go forward, and other parts can be discussed - whether in this working grou= p or another one. > > > Given the points of contention, it seems that the separation needs to be = among three documents. > > The first is a specification - a BCP - for the CLAT service. It refers to= RFCs 6052/6144/6145/6146/6147, and describes how translation is used in th= is context using normative language. It does not refer to a prefix::/96; it= refers to RFC 6052. My understanding is that several people have said that= this specification is interesting and useful. > > The second is a separate specification for the proxy service, which is co= ntentious. Being separated, it can be discussed and beaten to death as need= ed. The first specification says that the CLAT service MAY implement this p= roxy service. I'm not sure whether that is BCP or Informational; we can dis= cuss that in the context of the rest of the discussion of the proxy service= . > Having a CPE optionally cache and proxy DNS requests should not be contentious. The rather generic CPE i use at home gives me a DNS server address of 192.168.1.1 ... this is the same thing CLAT would do. > The third is a report on the trial deployment of the CLAT service by the = various companies in question. This is an informational document. > > Am I making sense? Would this be an acceptable way forward? I am sorry i am not in Paris, and perhaps if i was there in person i could understand why some of these issues are contentious when they have been discussed to an end on the mailer. It was my understanding that the DNS proxy and /96 were addressed on the mailing list, and that the concerns about /96 were limited to Woj. I don't recall any other voices on this topic. Personally, i do not relish this sausage making that is standards works. I am eager to move forward with running my network. That said, i am open to any proposal that moves us forward quickly. Informational documents are "timely" and i believe the document is in good shape today and has rough consensus and running code and deployed network. If stripping /96 and DNS proxy moves us forward as BCP quick, while informational means more sausage making, lets roll with BCP. My assumption was that BCP was going to be steeper climb, and thus slower. To that end, i look to the chairs and WG for guidance. CB From despres.remi@laposte.net Tue Mar 27 01:17:36 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D090E21F8533 for ; Tue, 27 Mar 2012 01:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.777 X-Spam-Level: X-Spam-Status: No, score=-1.777 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3] 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 aHostQVnKBEe for ; Tue, 27 Mar 2012 01:17:34 -0700 (PDT) Received: from smtpout.laposte.net (smtpout1.laposte.net [193.253.67.226]) by ietfa.amsl.com (Postfix) with ESMTP id DB4AB21F8550 for ; Tue, 27 Mar 2012 01:17:30 -0700 (PDT) Received: from dhcp-13f8.meeting.ietf.org ([130.129.19.248]) by mwinf8501-out with ME id qYHM1i00F5M8erm03YHN1A; Tue, 27 Mar 2012 10:17:29 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: Date: Tue, 27 Mar 2012 10:17:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> References: To: Fred Baker X-Mailer: Apple Mail (2.1084) Cc: IPv6 Operations , Softwire Chairs , v6ops-ads@tools.ietf.org, draft-ietf-v6ops-464xlat@tools.ietf.org Subject: Re: [v6ops] A way forward for 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 08:17:36 -0000 Le 2012-03-27 =E0 04:34, Fred Baker a =E9crit : > I won't say "chair hat off", but "chair hat fashionably tipped to one = side." I'm trying to figure out the best way forward for the 464XLAT = specification in view of comments by the authors of=20 >=20 > http://datatracker.ietf.org/doc/draft-despres-softwire-4rd-u > http://datatracker.ietf.org/doc/draft-fu-softwire-4rd-mib > http://datatracker.ietf.org/doc/draft-fu-softwire-map-mib > http://datatracker.ietf.org/doc/draft-jiang-softwire-map-radius > = http://datatracker.ietf.org/doc/draft-mdt-softwire-map-deployment > = http://datatracker.ietf.org/doc/draft-mdt-softwire-map-dhcp-option > = http://datatracker.ietf.org/doc/draft-mdt-softwire-map-encapsulation > = http://datatracker.ietf.org/doc/draft-mdt-softwire-map-translation > = http://datatracker.ietf.org/doc/draft-mdt-softwire-mapping-address-and-por= t > http://datatracker.ietf.org/doc/draft-murakami-softwire-4rd > = http://datatracker.ietf.org/doc/draft-sarikaya-softwire-4rdmulticast I haven't seen comments in v6ops of authors of all these documents. OTOH, I read the 4X4XLAT spec, had a useful dialogue with Cameron Byrne = about it on the ML, and wish to pursue cooperation with 464XLAT author. Yet, this list gives me impression that this work isn't welcome in = v6ops, without understanding why. >=20 > and notably the comments in the working group meeting Monday morning. = Why do I comment on the "chair hat"? Well, I'm not "giving instruction", = as chair; I'm floating an idea. If the idea is acceptable, the idea may = become instruction; if it needs to be modified, I want to have that = conversation. >=20 > The objections raised in the working group come down to: > - the authors of said other documents would like to have a = conversation with the 464XLAT folks > - What's this about a prefix::/96? > - What's this about a proxy service? There was also a point about NAT44 in CLAT nodes or not (point discussed = on the ML) May I add that the relationship between 464XLAT and BIH (RFC6535) would = also be worth clarifying. (I see high similarity: v4 only applications = communicating in IPv6). > - What's this about normative language? > - How does it fit the the mdt-softwire-map specifications, which > appear to have a growing consensus behind them in softwire? The point made during the meeting was about the work in Softwire in = general. replacing this point by a reference to the mdt draft is a = biased interpretation. In Softwire, a choice between MAP and Unified is scheduled for Friday = morning. As chair of v6ops, it would be better to avoid making a = Softwire choice before the scheduled debate has taken place (IMHO). Thanks. regards, RD >=20 > Before you continue reading this note, please stop and read these two = sections: > http://tools.ietf.org/html/rfc2026#section-4.2.2 > http://tools.ietf.org/html/rfc2026#section-5 >=20 > =46rom my perspective, and from reading those definitions, an = Informational Document is a white paper, while a BCP is something that a = significant and relevant part of the Internet COmmunity agrees to, and >=20 > ...since the Internet itself is composed of networks operated by a = great > variety of organizations, with diverse goals and rules, good user > service requires that the operators and administrators of the > Internet follow some common guidelines for policies and operations. >=20 > In other words, operational service models, while not strictly = speaking "protocols", can be described in a BCP *standard* as "how to = implement a certain service". This is in no sense "the best" or "only = way to deploy RFCs 6145/6146", but it might be "the best way to deploy = the CLAT service". v6ops is authorized, by charter, to write = informational and BCP documents. >=20 > And since a BCP describes the set of things that one MUST or SHOULD do = in deploying such a service, RFC 2119 language regarding that specific = service may be acceptable in a BCP describing that service. >=20 >=20 > With that preparatory reasoning, it seems to me that we need to = separate the contentious parts of the specification so that = uncontentious parts can go forward, and other parts can be discussed - = whether in this working group or another one. >=20 >=20 > Given the points of contention, it seems that the separation needs to = be among three documents. >=20 > The first is a specification - a BCP - for the CLAT service. It refers = to RFCs 6052/6144/6145/6146/6147, and describes how translation is used = in this context using normative language. It does not refer to a = prefix::/96; it refers to RFC 6052. My understanding is that several = people have said that this specification is interesting and useful. >=20 > The second is a separate specification for the proxy service, which is = contentious. Being separated, it can be discussed and beaten to death as = needed. The first specification says that the CLAT service MAY implement = this proxy service. I'm not sure whether that is BCP or Informational; = we can discuss that in the context of the rest of the discussion of the = proxy service. >=20 > The third is a report on the trial deployment of the CLAT service by = the various companies in question. This is an informational document. >=20 > Am I making sense? Would this be an acceptable way forward? From simon.perreault@viagenie.ca Tue Mar 27 03:32:54 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F67821E8143 for ; Tue, 27 Mar 2012 03:32:54 -0700 (PDT) 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 iIkTsNj45CI5 for ; Tue, 27 Mar 2012 03:32:52 -0700 (PDT) Received: from jazz.viagenie.ca (unknown [IPv6:2620:0:230:8000:226:55ff:fe57:14db]) by ietfa.amsl.com (Postfix) with ESMTP id CDAC221E8101 for ; Tue, 27 Mar 2012 03:32:52 -0700 (PDT) Received: from banana.viagenie.ca (unknown [IPv6:2001:df8:0:16:1e4b:d6ff:fe20:6cfe]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 3EC2E400D5 for ; Tue, 27 Mar 2012 06:32:52 -0400 (EDT) Message-ID: <4F719752.4060601@viagenie.ca> Date: Tue, 27 Mar 2012 12:32:50 +0200 From: Simon Perreault User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0) Gecko/20120131 Thunderbird/10.0 MIME-Version: 1.0 To: v6ops@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [v6ops] BIH vs 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 10:32:54 -0000 I was thinking that bump-in-the-host (BIH) could be used for something like 464XLAT, and after some questioning I was pointed to the following extract from RFC6535: The IETF recommends using solutions based on dual stack or tunneling for IPv6 transition and specifically recommends against deployments utilizing double protocol translation. Use of BIH together with a NAT64 is NOT RECOMMENDED [RFC6180]. Wouldn't this anti-recommendation also apply to 464XLAT? Did the consensus on double translation change? Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca From Ray.Bellis@nominet.org.uk Tue Mar 27 03:34:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E548D21E8158 for ; Tue, 27 Mar 2012 03:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.361 X-Spam-Level: X-Spam-Status: No, score=-10.361 tagged_above=-999 required=5 tests=[AWL=0.238, 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 AOTjWV-2MjuT for ; Tue, 27 Mar 2012 03:34:09 -0700 (PDT) Received: from mx3.nominet.org.uk (mail.nominet.org.uk [213.248.199.23]) by ietfa.amsl.com (Postfix) with ESMTP id DEBEF21E8153 for ; Tue, 27 Mar 2012 03:34:08 -0700 (PDT) DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:Received:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:Content-Type: Content-ID:Content-Transfer-Encoding:MIME-Version; b=jlbFa/tuC3UrSROPF6AZuTxDj4RDsK8DKDj/rdrfac6WptyzZW3EQjeP nI/MjDkWlLDgn5gaA6qZPszkE13lJBK6+YmWcxuXN5vef8khmT9OyninZ Hb2sv8jl4fQaacY; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1332844449; x=1364380449; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray=20Bellis=20 |Subject:=20Re:=20[v6ops]=20A=20way=20forward=20for=20464 XLAT|Date:=20Tue,=2027=20Mar=202012=2010:34:08=20+0000 |Message-ID:=20|To:=20Cameron=20Byrne=20 |CC:=20IPv6=20Operations=20|MIME-Version: =201.0|Content-Transfer-Encoding:=20quoted-printable |Content-ID:=20 |In-Reply-To:=20|References:=20=0D=0A=20; bh=qTj7vz/jIvB0+4FlWXr2F+YpG/v/7NWa+lgATTQiWCg=; b=XtO1wIP34XkQ3Chw81/0ubbIdlXD65adTewsj7RSkY9OIteDPM2/cD2T 0f4V5Wa66o7ThyAIBMLRJmDSIaZjsMO0y/NNyjFjoFeZbFOSGRcs6RcRE VrnG+489RcC07BV; X-IronPort-AV: E=Sophos;i="4.75,325,1330905600"; d="scan'208";a="39348519" Received: from wds-exc1.okna.nominet.org.uk ([213.248.197.144]) by mx3.nominet.org.uk with ESMTP; 27 Mar 2012 11:34:07 +0100 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%19]) with mapi; Tue, 27 Mar 2012 11:34:06 +0100 From: Ray Bellis To: Cameron Byrne Thread-Topic: [v6ops] A way forward for 464XLAT Thread-Index: AQHNC8JBbYAhrh6x70WUT9BNNYOIYZZ9euQAgABnGwA= Date: Tue, 27 Mar 2012 10:34:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: IPv6 Operations Subject: Re: [v6ops] A way forward for 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 10:34:10 -0000 On 27 Mar 2012, at 06:25, Cameron Byrne wrote: > It is my understanding > that many CPE today set themselves as the DNS server and proxy DNS to > the ISP DNS server, that is all that is being done here. They do, but the main rationale is to defeat the chicken-and-egg problem of= not knowing which DNS servers to offer the client when you haven't yet lea= rnt any from your upstream WAN link. See RFC 5625. Ray From cb.list6@gmail.com Tue Mar 27 03:38:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D80621F89BC for ; Tue, 27 Mar 2012 03:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.994 X-Spam-Level: X-Spam-Status: No, score=-2.994 tagged_above=-999 required=5 tests=[AWL=-0.295, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, 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 gZhtID5mL9IP for ; Tue, 27 Mar 2012 03:38:28 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 469E021F89B8 for ; Tue, 27 Mar 2012 03:38:28 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so72359pbb.31 for ; Tue, 27 Mar 2012 03:38:28 -0700 (PDT) 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:content-transfer-encoding; bh=R9KXcCAKRi8jKGbiyr1OORg9P3IkAHeRc7QdySTCkxc=; b=YitX5SQUA8HUVsPrrzkhZYb2ZYXBa8d9p8bFyxz9ZAC03bmCuGqW68bsElULYFgxeW wuougEcytuAEOVhKp4E56t5zuPI3N6OHPwxoDtqWp2tUGWHm0l/BwWzcmkdfmP8wz3C9 npfSAqFbNDb+PAAD+A4fypwNnCHFYpnQHOfuxhx/2bGJL9BKICgw/Lim9Z2MyVpXYsvl Rs97PvEQyYa+1mqWgO0l0bWJ6YIEys1Ew+KF5YOixlWVBH436yUHJdCyafiaglr/Z/v3 wrwdAxRuJh/CbPMIfIVG5ylg19OxjGsXhesZNx14M3ap9OkeHkEt2xLD3oZajjnhBKFx 9Tgw== MIME-Version: 1.0 Received: by 10.68.211.135 with SMTP id nc7mr60994720pbc.113.1332844707789; Tue, 27 Mar 2012 03:38:27 -0700 (PDT) Received: by 10.143.160.13 with HTTP; Tue, 27 Mar 2012 03:38:27 -0700 (PDT) In-Reply-To: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> References: <7E1BD96D-E7EC-4C78-B382-66F0F694DAA4@laposte.net> Date: Tue, 27 Mar 2012 03:38:27 -0700 Message-ID: From: Cameron Byrne To: =?ISO-8859-1?B?UultaSBEZXNwculz?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , draft-ietf-v6ops-464xlat@tools.ietf.org, v6ops-ads@tools.ietf.org, Softwire Chairs Subject: Re: [v6ops] A way forward for 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 10:38:29 -0000 hi, On Tue, Mar 27, 2012 at 1:17 AM, R=E9mi Despr=E9s wrote: > > Le 2012-03-27 =E0 04:34, Fred Baker a =E9crit : > >> I won't say "chair hat off", but "chair hat fashionably tipped to one si= de." I'm trying to figure out the best way forward for the 464XLAT specific= ation in view of comments by the authors of >> >> =A0 =A0 =A0 http://datatracker.ietf.org/doc/draft-despres-softwire-4rd-u >> =A0 =A0 =A0 http://datatracker.ietf.org/doc/draft-fu-softwire-4rd-mib >> =A0 =A0 =A0 http://datatracker.ietf.org/doc/draft-fu-softwire-map-mib >> =A0 =A0 =A0 http://datatracker.ietf.org/doc/draft-jiang-softwire-map-rad= ius >> =A0 =A0 =A0 http://datatracker.ietf.org/doc/draft-mdt-softwire-map-deplo= yment >> =A0 =A0 =A0 http://datatracker.ietf.org/doc/draft-mdt-softwire-map-dhcp-= option >> =A0 =A0 =A0 http://datatracker.ietf.org/doc/draft-mdt-softwire-map-encap= sulation >> =A0 =A0 =A0 http://datatracker.ietf.org/doc/draft-mdt-softwire-map-trans= lation >> =A0 =A0 =A0 http://datatracker.ietf.org/doc/draft-mdt-softwire-mapping-a= ddress-and-port >> =A0 =A0 =A0 http://datatracker.ietf.org/doc/draft-murakami-softwire-4rd >> =A0 =A0 =A0 http://datatracker.ietf.org/doc/draft-sarikaya-softwire-4rdm= ulticast > > I haven't seen comments in v6ops of authors of all these documents. > OTOH, I read the 4X4XLAT spec, had a useful dialogue with Cameron Byrne a= bout it on the ML, and wish to pursue cooperation with 464XLAT author. > Yet, this list gives me impression that this work isn't welcome in v6ops,= without understanding why. > >> >> and notably the comments in the working group meeting Monday morning. Wh= y do I comment on the "chair hat"? Well, I'm not "giving instruction", as c= hair; I'm floating an idea. If the idea is acceptable, the idea may become = instruction; if it needs to be modified, I want to have that conversation. >> >> The objections raised in the working group come down to: >> =A0 - the authors of said other documents would like to have a conversat= ion with the 464XLAT folks >> =A0 - What's this about a prefix::/96? >> =A0 - What's this about a proxy service? > > There was also a point about NAT44 in CLAT nodes or not (point discussed = on the ML) > The NAT44 text on the CLAT has been integrated here: http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-01#section-6.5 "Alternatively, the CLAT may do NAT44 such that all private IPv4 sourced LAN packets appears from one private IPv4 address which is statelessly translated to one IPv6 address that the CLAT will own as a host IPv6 address from an IPv6 /64 interface." > May I add that the relationship between 464XLAT and BIH (RFC6535) would a= lso be worth clarifying. (I see high similarity: v4 only applications commu= nicating in IPv6). > BIH explicitly does not allow double translation, it's scope is explicitly limited to the case of using IPv4 applications to IPv6-only servers. I objected to this limitation in BEHAVE. But, it is what it is. That said, 464XLAT authors have found rfc6145 to be the best fit for IPv4->IPv6 translation, including support for the function in a more generic node such as a router (home gateway CPE, mobile phone as a host, mobile phone as a wifi router, ...) where BIH is constrained to a host only style implementation that relies on host level API modification and interaction >> =A0 - What's this about normative language? > >> =A0 - How does it fit the the mdt-softwire-map specifications, which >> =A0 =A0 appear to have a growing consensus behind them in softwire? > > The point made during the meeting was about the work in Softwire in gener= al. replacing this point by a reference to the mdt draft is a biased interp= retation. > In Softwire, a choice between MAP and Unified is scheduled for Friday mor= ning. As chair of v6ops, it would be better to avoid making a Softwire choi= ce before the scheduled debate has taken place (IMHO). > Thanks. > I hope my previous emails have made the case for a stateful solution clear and useful As it stands, there is no workable stateful (more IPv4 address efficient / intensive) IETF method of operating in an IPv6-only access network. NAT64/DNS64 is not workable, since 15% of applications on mobile (something similar for desktop) fail to work without some way to deal with IPv4 specific sockets and IPv4 literals. CB > regards, > RD > > >> >> Before you continue reading this note, please stop and read these two se= ctions: >> =A0 http://tools.ietf.org/html/rfc2026#section-4.2.2 >> =A0 http://tools.ietf.org/html/rfc2026#section-5 >> >> From my perspective, and from reading those definitions, an Informationa= l Document is a white paper, while a BCP is something that a significant an= d relevant part of the Internet COmmunity agrees to, and >> >> ...since the Internet itself is composed of networks operated by a great >> =A0variety of organizations, with diverse goals and rules, good user >> =A0service requires that the operators and administrators of the >> =A0Internet follow some common guidelines for policies and operations. >> >> In other words, operational service models, while not strictly speaking = "protocols", can be described in a BCP *standard* as "how to implement a ce= rtain service". This is in no sense "the best" or "only way to deploy RFCs = 6145/6146", but it might be "the best way to deploy the CLAT service". v6op= s is authorized, by charter, to write informational and BCP documents. >> >> And since a BCP describes the set of things that one MUST or SHOULD do i= n deploying such a service, RFC 2119 language regarding that specific servi= ce may be acceptable in a BCP describing that service. >> >> >> With that preparatory reasoning, it seems to me that we need to separate= the contentious parts of the specification so that uncontentious parts can= go forward, and other parts can be discussed - whether in this working gro= up or another one. >> >> >> Given the points of contention, it seems that the separation needs to be= among three documents. >> >> The first is a specification - a BCP - for the CLAT service. It refers t= o RFCs 6052/6144/6145/6146/6147, and describes how translation is used in t= his context using normative language. It does not refer to a prefix::/96; i= t refers to RFC 6052. My understanding is that several people have said tha= t this specification is interesting and useful. >> >> The second is a separate specification for the proxy service, which is c= ontentious. Being separated, it can be discussed and beaten to death as nee= ded. The first specification says that the CLAT service MAY implement this = proxy service. I'm not sure whether that is BCP or Informational; we can di= scuss that in the context of the rest of the discussion of the proxy servic= e. >> >> The third is a report on the trial deployment of the CLAT service by the= various companies in question. This is an informational document. >> >> Am I making sense? Would this be an acceptable way forward? > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From cb.list6@gmail.com Tue Mar 27 03:44:31 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB3A21E816E for ; Tue, 27 Mar 2012 03:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.441 X-Spam-Level: X-Spam-Status: No, score=-3.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 ECc1Vics+4xx for ; Tue, 27 Mar 2012 03:44:30 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id ADE4C21E816B for ; Tue, 27 Mar 2012 03:44:30 -0700 (PDT) Received: by ghbg16 with SMTP id g16so4982484ghb.31 for ; Tue, 27 Mar 2012 03:44:30 -0700 (PDT) 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=Aej8U1DPoz9KSTH1J6/ACky+MM3esHh4gHAryQbb/18=; b=UMP8Ac7x2eb+YxTBrtQstx27QGHYtGeCs6pZPuMVGfSCTMCR8GW+OdHpyDe6e/+zKQ FGaP8XBs8qAN603YkS9MCVYjiP/Tp6Q8QlVTclX3fWHuPOPIoHqdCV7N6+zxYVYUaKL+ SbYoIRcskpDT/RluuhTPmBP9kQ4id4CV9TjgU9tsh+ymzQbwdNoHbmQHEBM9SQgnp4SZ NVv6pDYx6xjQpgH/XNwUVm0pQD8QH26JipVjOE7eP01sQkF5dltJA46GF9F8hqsTIiiq nXe3bmsy70RGi5bLVp5gbVHtm745X7lzWuhv9Yph+XXMAdXvr8KT7egNIW7LNSyr6O3U 5qUA== MIME-Version: 1.0 Received: by 10.68.230.41 with SMTP id sv9mr61162425pbc.48.1332845069768; Tue, 27 Mar 2012 03:44:29 -0700 (PDT) Received: by 10.143.160.13 with HTTP; Tue, 27 Mar 2012 03:44:29 -0700 (PDT) In-Reply-To: References: Date: Tue, 27 Mar 2012 03:44:29 -0700 Message-ID: From: Cameron Byrne To: Ray Bellis Content-Type: text/plain; charset=ISO-8859-1 Cc: IPv6 Operations Subject: Re: [v6ops] A way forward for 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 10:44:31 -0000 Hi, On Tue, Mar 27, 2012 at 3:34 AM, Ray Bellis wrote: > > On 27 Mar 2012, at 06:25, Cameron Byrne wrote: > >> It is my understanding >> that many CPE today set themselves as the DNS server and proxy DNS to >> the ISP DNS server, that is all that is being done here. > > They do, but the main rationale is to defeat the chicken-and-egg problem of not knowing which DNS servers to offer the client when you haven't yet learnt any from your upstream WAN link. > > See RFC 5625. > ACK. http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-01#section-6.4 " The CLAT should allow for a client to query any DNS server of its choice and bypass the proxy." Does the current text of the draft not properly address the desired behavior? It is probably worth adding a reference to RFC5625 CB > Ray > From cb.list6@gmail.com Tue Mar 27 03:59:58 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47B721F89D8 for ; Tue, 27 Mar 2012 03:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.142 X-Spam-Level: X-Spam-Status: No, score=-3.142 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 Xuq2EpD8dFV7 for ; Tue, 27 Mar 2012 03:59:54 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5AAC921F89D6 for ; Tue, 27 Mar 2012 03:59:54 -0700 (PDT) Received: by yhkk25 with SMTP id k25so4956195yhk.31 for ; Tue, 27 Mar 2012 03:59:54 -0700 (PDT) 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:content-transfer-encoding; bh=n8PXHcLJ0IOdloSGbxdtwwcQslqZs1mSge/ikF6v6gs=; b=ghtRu51UuN65i6QylMq9s8ysziznUe1KfIOWBY7oWHmBl+PSLukVVf3MgEnHG7tynW BCpZgE8g7BTdX4osFsBRqkbj+XCDNVvcj/RUEsZQmBqzNEggZmYYyM5+tuSbUI5+WM/H GEWacaySg/ezoJKVDbVlUGluPdE+ZJumyWczHmqhO5Ihrk/bGoqVsGaiPeTODdAMdQnw QbqmPSZSd+NlVR1s2D1L5vkfwX4zud/2f0hJ0XBmVILF6dz//XJ0ZdLgTrCxCirY34Ur f1A3nDhbg29Xi6mf0vTCevhzkHK4BsIveP355IBTEi7fRSpTHGKq75fSPbIGW+vgbhQc Y8QA== MIME-Version: 1.0 Received: by 10.68.197.65 with SMTP id is1mr8525614pbc.70.1332845993305; Tue, 27 Mar 2012 03:59:53 -0700 (PDT) Received: by 10.143.160.13 with HTTP; Tue, 27 Mar 2012 03:59:53 -0700 (PDT) In-Reply-To: <4F719752.4060601@viagenie.ca> References: <4F719752.4060601@viagenie.ca> Date: Tue, 27 Mar 2012 03:59:53 -0700 Message-ID: From: Cameron Byrne To: Simon Perreault Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: v6ops@ietf.org Subject: Re: [v6ops] BIH vs 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 10:59:58 -0000 On Tue, Mar 27, 2012 at 3:32 AM, Simon Perreault wrote: > I was thinking that bump-in-the-host (BIH) could be used for something li= ke > 464XLAT, and after some questioning I was pointed to the following extrac= t from > RFC6535: > > =A0 The IETF recommends using solutions based on dual stack or tunneling > =A0 for IPv6 transition and specifically recommends against deployments > =A0 utilizing double protocol translation. =A0Use of BIH together with a > =A0 NAT64 is NOT RECOMMENDED [RFC6180]. > FYI -- i fought this restriction in BEHAVE. Lost. > Wouldn't this anti-recommendation also apply to 464XLAT? > > Did the consensus on double translation change? > I have to assume so since Softwires has mountain of work that is double translation, and in fact MAP-T is triple translation, NAT4464 It is perhaps the situation that BIH came a few months too soon for the IESG to be responsive to the realistic need of double translation. That said, 464XLAT seldom uses double translation in practice when used together with DNS64 http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-01#section-6.3 Double translation is only invoked in the case when NAT64/DNS64 alone would result in failure of communication due to IPv4-only sockets or IPv4 literals. So, the tradeoff is double translation or communication failure. Subscribers who don't know what IP is like the double translation solution that loads Skype. There is also the fact the IESG passed this http://tools.ietf.org/html/draft-weil-shared-transition-space-request-15 ... which is clearly a tip of the hat to NAT444. It would be unconscionable for the IESG to support NAT444 and not support something that required IPv6 and enabled IPv6 like 464XLAT CB > Simon > -- > DTN made easy, lean, and smart --> http://postellation.viagenie.ca > NAT64/DNS64 open-source =A0 =A0 =A0 =A0--> http://ecdysis.viagenie.ca > STUN/TURN server =A0 =A0 =A0 =A0 =A0 =A0 =A0 --> http://numb.viagenie.ca > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops From wwwrun@rfc-editor.org Tue Mar 27 04:07:45 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03E9D21F85C9; Tue, 27 Mar 2012 04:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.663 X-Spam-Level: X-Spam-Status: No, score=-104.663 tagged_above=-999 required=5 tests=[AWL=1.014, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_MED=-4, 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 T3jgzWgqxLcA; Tue, 27 Mar 2012 04:07:44 -0700 (PDT) Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47]) by ietfa.amsl.com (Postfix) with ESMTP id C487521F8810; Tue, 27 Mar 2012 04:07:32 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 67F5D72F4F6; Tue, 27 Mar 2012 04:06:12 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120327110612.67F5D72F4F6@rfc-editor.org> Date: Tue, 27 Mar 2012 04:06:12 -0700 (PDT) Cc: v6ops@ietf.org, rfc-editor@rfc-editor.org Subject: [v6ops] RFC 6583 on Operational Neighbor Discovery Problems X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 11:07:45 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6583 Title: Operational Neighbor Discovery Problems Author: I. Gashinsky, J. Jaeggli, W. Kumari Status: Informational Stream: IETF Date: March 2012 Mailbox: igor@yahoo-inc.com, jjaeggli@zynga.com, warren@kumari.net Pages: 12 Characters: 29480 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-v6nd-problems-04.txt URL: http://www.rfc-editor.org/rfc/rfc6583.txt In IPv4, subnets are generally small, made just large enough to cover the actual number of machines on the subnet. In contrast, the default IPv6 subnet size is a /64, a number so large it covers trillions of addresses, the overwhelming number of which will be unassigned. Consequently, simplistic implementations of Neighbor Discovery (ND) can be vulnerable to deliberate or accidental denial of service (DoS), whereby they attempt to perform address resolution for large numbers of unassigned addresses. Such denial-of-service attacks can be launched intentionally (by an attacker) or result from legitimate operational tools or accident conditions. As a result of these vulnerabilities, new devices may not be able to "join" a network, it may be impossible to establish new IPv6 flows, and existing IPv6 transported flows may be interrupted. This document describes the potential for DoS in detail and suggests possible implementation improvements as well as operational mitigation techniques that can, in some cases, be used to protect against or at least alleviate the impact of such attacks. [STANDARDS-TRACK] This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From joelja@bogus.com Tue Mar 27 04:53:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE6721F89D0 for ; Tue, 27 Mar 2012 04:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 arZ32gK4iqil for ; Tue, 27 Mar 2012 04:53:02 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by ietfa.amsl.com (Postfix) with ESMTP id C03A821F8831 for ; Tue, 27 Mar 2012 04:53:02 -0700 (PDT) Received: from dhcp-5710.meeting.ietf.org (dhcp-5710.meeting.ietf.org [130.129.87.16]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id q2RBqqaA046965 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Tue, 27 Mar 2012 11:52:54 GMT (envelope-from joelja@bogus.com) Message-ID: <4F71AA12.6080203@bogus.com> Date: Tue, 27 Mar 2012 13:52:50 +0200 From: Joel jaeggli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: IPv6 Ops WG References: <20120327110612.67F5D72F4F6@rfc-editor.org> In-Reply-To: <20120327110612.67F5D72F4F6@rfc-editor.org> X-Forwarded-Message-Id: <20120327110612.67F5D72F4F6@rfc-editor.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (nagasaki.bogus.com [147.28.0.81]); Tue, 27 Mar 2012 11:52:54 +0000 (UTC) Subject: [v6ops] Fwd: RFC 6583 on Operational Neighbor Discovery Problems X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 11:53:03 -0000 -------- Original Message -------- Subject: [v6ops] RFC 6583 on Operational Neighbor Discovery Problems Date: Tue, 27 Mar 2012 04:06:12 -0700 (PDT) From: rfc-editor@rfc-editor.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org CC: v6ops@ietf.org, rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 6583 Title: Operational Neighbor Discovery Problems Author: I. Gashinsky, J. Jaeggli, W. Kumari Status: Informational Stream: IETF Date: March 2012 Mailbox: igor@yahoo-inc.com, jjaeggli@zynga.com, warren@kumari.net Pages: 12 Characters: 29480 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-v6ops-v6nd-problems-04.txt URL: http://www.rfc-editor.org/rfc/rfc6583.txt In IPv4, subnets are generally small, made just large enough to cover the actual number of machines on the subnet. In contrast, the default IPv6 subnet size is a /64, a number so large it covers trillions of addresses, the overwhelming number of which will be unassigned. Consequently, simplistic implementations of Neighbor Discovery (ND) can be vulnerable to deliberate or accidental denial of service (DoS), whereby they attempt to perform address resolution for large numbers of unassigned addresses. Such denial-of-service attacks can be launched intentionally (by an attacker) or result from legitimate operational tools or accident conditions. As a result of these vulnerabilities, new devices may not be able to "join" a network, it may be impossible to establish new IPv6 flows, and existing IPv6 transported flows may be interrupted. This document describes the potential for DoS in detail and suggests possible implementation improvements as well as operational mitigation techniques that can, in some cases, be used to protect against or at least alleviate the impact of such attacks. [STANDARDS-TRACK] This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ v6ops mailing list v6ops@ietf.org https://www.ietf.org/mailman/listinfo/v6ops From mark@townsley.net Tue Mar 27 07:21:42 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C36921E8103 for ; Tue, 27 Mar 2012 07:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 pY5GcnhJ8IvA for ; Tue, 27 Mar 2012 07:21:41 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id B715D21E8091 for ; Tue, 27 Mar 2012 07:21:40 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so3345713wgb.13 for ; Tue, 27 Mar 2012 07:21:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:subject:date:references:to:message-id:mime-version:x-mailer :x-gm-message-state:content-type; bh=xfio/fnoDQi8uyFbOHNaIdXsnTGOJ26/ALZmGO+0Pck=; b=ZIAxx47EeVRe9KSi+kDg0XIWUY2yxIRAR4IFlYmOrFV/Fh+TydLbQntr5bBM/MpbEB T1UNaT/xKN5bxoXe/zBVpRQZGvkZKppXD7/Iu01kDeOKMSULGD3vYEgZUTx2A2Zrl/JI UOEba96Wwk5Xd8Iwv+2WHQTGcqh3cBH7eOIm9pShZOev0d5dzw85sMdiMNkAOUQd+emu DF7ledwvl8yBr2ZLfFL3T+3a3JOcAldiXUxR/uCPLZ0kZrPstUfLej3cBgOkUwE1FpPY bAAfc4rMwhN1ovQYNlwnMxrfoUv2QzDOnPF2MPBKxivNp5I9aXJm20IW3GvCfTBwZwBJ 596A== Received: by 10.180.95.74 with SMTP id di10mr32373760wib.1.1332858099770; Tue, 27 Mar 2012 07:21:39 -0700 (PDT) Received: from dhcp-47a0.meeting.ietf.org (dhcp-47a0.meeting.ietf.org. [130.129.71.160]) by mx.google.com with ESMTPS id fw5sm49824213wib.0.2012.03.27.07.21.32 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Mar 2012 07:21:39 -0700 (PDT) From: Mark Townsley Date: Tue, 27 Mar 2012 16:21:31 +0200 References: <138E0AE8-774A-4380-B891-CA6A908E6B32@isoc.org> To: v6ops@ietf.org Message-Id: <4B550D53-7F69-4571-92D9-29E33AB21252@townsley.net> Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQm+OmE3pTMy1gI01lCk9iU2uVrR+ve6xTToes2BecmQX0ArHLwHjZDeBQrdWPlavfp3e7I/ Content-Type: multipart/alternative; boundary="Apple-Mail=_48484E4F-4FD7-41EB-A90D-6FE77D47870D" Subject: [v6ops] IPv6 World Launch Day Panel X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Mar 2012 14:21:42 -0000 --Apple-Mail=_48484E4F-4FD7-41EB-A90D-6FE77D47870D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Apologies for the interruption.=20 In case you did not see the announcement elsewhere, there will be an = "IPv6 Launch Lunch" tomorrow afternoon.=20 - Mark Begin forwarded message: > From: Ray Pelletier > Subject: [83all] Cisco Presents: IPv6 World Launch Day Panel > Date: March 27, 2012 11:42:50 AM GMT+02:00 > To: 83all@ietf.org >=20 > Wednesday 28 March >=20 > CISCO presents: IPv6 World Launch Day Panel = www.worldipv6launch.org >=20 > John Brzozowski, Comcast Lee Howard, Time = Warner Cable > Alexandre Cassen, Free Telecom Erik Kline, Google > Lorenzo Colitti, Google Hans Liu, D-Link=20= > Igor Gashinsky, Yahoo! Mark Townsley, = Cisco >=20 > Moderated by Phil Roberts, Internet Society=20 >=20 > 12:00 to 12:45 in Room Maillot >=20 > Lunch: > Attendees can purchase lunch at the cash-and-carry lunch stand = directly in front of the room. Please note that credit cards are not = accepted.=20 >=20 > _______________________________________________ > 83all mailing list > 83all@ietf.org > https://www.ietf.org/mailman/listinfo/83all --Apple-Mail=_48484E4F-4FD7-41EB-A90D-6FE77D47870D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
- = Mark

Begin forwarded message:

From: Ray Pelletier = <rpelletier@isoc.org>
=
Subject: = [83all] Cisco Presents: IPv6 World Launch Day = Panel
Date: March 27, 2012 11:42:50 AM = GMT+02:00

Wednesday 28 March

CISCO presents:  IPv6 World = Launch Day Panel = www.worldipv6launch.org
= John Brzozowski, Comcast Lee Howard, Time Warner = Cable
= Alexandre Cassen, Free Telecom Erik Kline, Google
Lorenzo = Colitti, Google = = = = Hans Liu, D-Link
Igor Gashinsky, Yahoo! Mark = Townsley, Cisco

Moderated by Phil Roberts, = Internet Society

12:00 to 12:45 in Room = Maillot

Lunch:
Attendees can purchase lunch at the = cash-and-carry lunch stand directly in front of the room.  Please = note that credit cards are not accepted. =

_______________________________________________
83all mailing = list
83all@ietf.org
https://www.ietf.org/mailman/listinfo/83all
<= /div>

= --Apple-Mail=_48484E4F-4FD7-41EB-A90D-6FE77D47870D-- From wdec.ietf@gmail.com Wed Mar 28 08:22:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8030721E8158 for ; Wed, 28 Mar 2012 08:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.941 X-Spam-Level: X-Spam-Status: No, score=-2.941 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 n8JHaNCimDnz for ; Wed, 28 Mar 2012 08:22:33 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id B1ED721F8550 for ; Wed, 28 Mar 2012 08:22:32 -0700 (PDT) Received: by qaea16 with SMTP id a16so882241qae.10 for ; Wed, 28 Mar 2012 08:22:31 -0700 (PDT) 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=D+8DYxs3m4fMQkPGMvyYlRvcGaNE1ZrOY9ChZ96s8+E=; b=lqIIl4UVGux0lv3/2j/8kiskyYRybQFCk7Ifz9Lmh/OIKPL5rECMcS9t7gplLSK0Eq 4zBJEfyp9te6Oh8BjBy/abjpHqSNi5N/ciAldHR3vIu2B5OQjw1/GUcb+pyRa70uF+fi GFPdf/iQq5Lz4UpUFS/h99RrfCWJw4rcKUu4wbOyXLcZKhzQG2K4oKkzvcILQjJCePq3 pXTGG2ZwvlbyZlnTAJwQCTLfL2gDdNUhj1/r/N5sI+cv1VtofO9ZEBGxIzje95LoW8fM fFGLr1M/sJZ/ftgTunbI79Fc8ZZ8zMShDcgUxBVKOf6vPJ/nO/yLHR8r2FWoZsIKOuKi q4cw== MIME-Version: 1.0 Received: by 10.224.59.7 with SMTP id j7mr38855551qah.38.1332948151837; Wed, 28 Mar 2012 08:22:31 -0700 (PDT) Received: by 10.229.218.4 with HTTP; Wed, 28 Mar 2012 08:22:31 -0700 (PDT) In-Reply-To: References: Date: Wed, 28 Mar 2012 17:22:31 +0200 Message-ID: From: Wojciech Dec To: Fred Baker Content-Type: multipart/alternative; boundary=20cf306f74de1825ae04bc4f2dce Cc: IPv6 Operations , Softwire Chairs , v6ops-ads@tools.ietf.org, draft-ietf-v6ops-464xlat@tools.ietf.org Subject: Re: [v6ops] A way forward for 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 15:22:35 -0000 --20cf306f74de1825ae04bc4f2dce Content-Type: text/plain; charset=ISO-8859-1 Hi Fred, the proposed way forward makes sense to me. There appears to be a desire to have an "implementers spec" for a NAT64 client-device, along with some default settings, and assuming that this is based on existing NAT64 standards and not based on some "hard coded" values, it's fine to progress as a separate draft. Regards, Woj. On 27 March 2012 04:34, Fred Baker wrote: > I won't say "chair hat off", but "chair hat fashionably tipped to one > side." I'm trying to figure out the best way forward for the 464XLAT > specification in view of comments by the authors of > > http://datatracker.ietf.org/doc/draft-despres-softwire-4rd-u > http://datatracker.ietf.org/doc/draft-fu-softwire-4rd-mib > http://datatracker.ietf.org/doc/draft-fu-softwire-map-mib > http://datatracker.ietf.org/doc/draft-jiang-softwire-map-radius > http://datatracker.ietf.org/doc/draft-mdt-softwire-map-deployment > http://datatracker.ietf.org/doc/draft-mdt-softwire-map-dhcp-option > > http://datatracker.ietf.org/doc/draft-mdt-softwire-map-encapsulation > http://datatracker.ietf.org/doc/draft-mdt-softwire-map-translation > > http://datatracker.ietf.org/doc/draft-mdt-softwire-mapping-address-and-port > http://datatracker.ietf.org/doc/draft-murakami-softwire-4rd > > http://datatracker.ietf.org/doc/draft-sarikaya-softwire-4rdmulticast > > and notably the comments in the working group meeting Monday morning. Why > do I comment on the "chair hat"? Well, I'm not "giving instruction", as > chair; I'm floating an idea. If the idea is acceptable, the idea may become > instruction; if it needs to be modified, I want to have that conversation. > > The objections raised in the working group come down to: > - the authors of said other documents would like to have a conversation > with the 464XLAT folks > - What's this about a prefix::/96? > - What's this about a proxy service? > - What's this about normative language? > - How does it fit the the mdt-softwire-map specifications, which > appear to have a growing consensus behind them in softwire? > > Before you continue reading this note, please stop and read these two > sections: > http://tools.ietf.org/html/rfc2026#section-4.2.2 > http://tools.ietf.org/html/rfc2026#section-5 > > From my perspective, and from reading those definitions, an Informational > Document is a white paper, while a BCP is something that a significant and > relevant part of the Internet COmmunity agrees to, and > > ...since the Internet itself is composed of networks operated by a great > variety of organizations, with diverse goals and rules, good user > service requires that the operators and administrators of the > Internet follow some common guidelines for policies and operations. > > In other words, operational service models, while not strictly speaking > "protocols", can be described in a BCP *standard* as "how to implement a > certain service". This is in no sense "the best" or "only way to deploy > RFCs 6145/6146", but it might be "the best way to deploy the CLAT service". > v6ops is authorized, by charter, to write informational and BCP documents. > > And since a BCP describes the set of things that one MUST or SHOULD do in > deploying such a service, RFC 2119 language regarding that specific service > may be acceptable in a BCP describing that service. > > > With that preparatory reasoning, it seems to me that we need to separate > the contentious parts of the specification so that uncontentious parts can > go forward, and other parts can be discussed - whether in this working > group or another one. > > > Given the points of contention, it seems that the separation needs to be > among three documents. > > The first is a specification - a BCP - for the CLAT service. It refers to > RFCs 6052/6144/6145/6146/6147, and describes how translation is used in > this context using normative language. It does not refer to a prefix::/96; > it refers to RFC 6052. My understanding is that several people have said > that this specification is interesting and useful. > > The second is a separate specification for the proxy service, which is > contentious. Being separated, it can be discussed and beaten to death as > needed. The first specification says that the CLAT service MAY implement > this proxy service. I'm not sure whether that is BCP or Informational; we > can discuss that in the context of the rest of the discussion of the proxy > service. > > The third is a report on the trial deployment of the CLAT service by the > various companies in question. This is an informational document. > > Am I making sense? Would this be an acceptable way forward? > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --20cf306f74de1825ae04bc4f2dce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Fred,

the proposed way forward makes sense to me. There appears t= o be a desire to have an "implementers spec" for a NAT64 client-d= evice, along with some default settings, and assuming that this is based on= existing NAT64 standards and not based on some "hard coded" valu= es, it's fine to progress as a separate draft.

Regards,
Woj.

On 27 March 2012 04:= 34, Fred Baker <fred= @cisco.com> wrote:
I won't say "chair hat off", but "chair hat fashionably = tipped to one side." I'm trying to figure out the best way forward= for the 464XLAT specification in view of comments by the authors of

=A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-despr= es-softwire-4rd-u
=A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-fu-softw= ire-4rd-mib
=A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-fu-softw= ire-map-mib
=A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-ji= ang-softwire-map-radius
=A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-= mdt-softwire-map-deployment
=A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft= -mdt-softwire-map-dhcp-option
=A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/dra= ft-mdt-softwire-map-encapsulation
=A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft= -mdt-softwire-map-translation
=A0 =A0 =A0 =A0http://datatracker.ietf.org/= doc/draft-mdt-softwire-mapping-address-and-port
=A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-muraka= mi-softwire-4rd
=A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/dra= ft-sarikaya-softwire-4rdmulticast

and notably the comments in the working group meeting Monday morning. Why d= o I comment on the "chair hat"? Well, I'm not "giving in= struction", as chair; I'm floating an idea. If the idea is accepta= ble, the idea may become instruction; if it needs to be modified, I want to= have that conversation.

The objections raised in the working group come down to:
=A0 =A0- the authors of said other documents would like to have a conversa= tion with the 464XLAT folks
=A0 =A0- What's this about a prefix::/96?
=A0 =A0- What's this about a proxy service?
=A0 =A0- What's this about normative language?
=A0 =A0- How does it fit the the mdt-softwire-map specifications, which =A0 =A0 =A0appear to have a growing consensus behind them in softwire?

Before you continue reading this note, please stop and read these two secti= ons:
=A0 =A0http://tools.ietf.org/html/rfc2026#section-4.2.2
=A0 =A0http://tools.ietf.org/html/rfc2026#section-5

>From my perspective, and from reading those definitions, an Informational D= ocument is a white paper, while a BCP is something that a significant and r= elevant part of the Internet COmmunity agrees to, and

...since the Internet itself is composed of networks operated by a great =A0 variety of organizations, with diverse goals and rules, good user
=A0 service requires that the operators and administrators of the
=A0 Internet follow some common guidelines for policies and operations.
In other words, operational service models, while not strictly speaking &qu= ot;protocols", can be described in a BCP *standard* as "how to im= plement a certain service". This is in no sense "the best" o= r "only way to deploy RFCs 6145/6146", but it might be "the = best way to deploy the CLAT service". v6ops is authorized, by charter,= to write informational and BCP documents.

And since a BCP describes the set of things that one MUST or SHOULD do in d= eploying such a service, RFC 2119 language regarding that specific service = may be acceptable in a BCP describing that service.


With that preparatory reasoning, it seems to me that we need to separate th= e contentious parts of the specification so that uncontentious parts can go= forward, and other parts can be discussed - whether in this working group = or another one.


Given the points of contention, it seems that the separation needs to be am= ong three documents.

The first is a specification - a BCP - for the CLAT service. It refers to R= FCs 6052/6144/6145/6146/6147, and describes how translation is used in this= context using normative language. It does not refer to a prefix::/96; it r= efers to RFC 6052. My understanding is that several people have said that t= his specification is interesting and useful.

The second is a separate specification for the proxy service, which is cont= entious. Being separated, it can be discussed and beaten to death as needed= . The first specification says that the CLAT service MAY implement this pro= xy service. I'm not sure whether that is BCP or Informational; we can d= iscuss that in the context of the rest of the discussion of the proxy servi= ce.

The third is a report on the trial deployment of the CLAT service by the va= rious companies in question. This is an informational document.

Am I making sense? Would this be an acceptable way forward?
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--20cf306f74de1825ae04bc4f2dce-- From lorenzo@google.com Wed Mar 28 09:29:22 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E110821E80F3 for ; Wed, 28 Mar 2012 09:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.225 X-Spam-Level: X-Spam-Status: No, score=-102.225 tagged_above=-999 required=5 tests=[AWL=-0.449, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_LOW=-1, 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 ypAo2hFSALg4 for ; Wed, 28 Mar 2012 09:29:21 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 652BC21E8091 for ; Wed, 28 Mar 2012 09:29:21 -0700 (PDT) Received: by yhkk25 with SMTP id k25so935014yhk.31 for ; Wed, 28 Mar 2012 09:29:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=FW0kPxqhsrE5PAwxkUFnA2OgS8T0HJc5QEp3laKoQE0=; b=pQ1ECjd//tlJbWqIqsV4KE6aOsVv5von7vH4Ydp6s94CcXiNrD/MmP5NMrzfYqph9W xoMx2QITt/NtYUGfDB1BJJufG6zN/F5Xd291Yb0FZc0Po6xB0RBDqS0Wz4uFBXdu15D+ HiFWITJItoyZA08x+MdhOSQLMewAFXAaif2g1arQUfb3iU2XV0kODRxFLxmOSsPBYT9n EB4TTgGkDWnWjcEOLYZ2AZSaCTXLH1GuQy9yPyA+HiZ0PrdlaetRPfQqm/5APO5irr9/ kdd74vZk3/kYpKCh6qmQG6x/acXJKRql/XKHGv5KLtIX94P5aLl85uLtCpxkJPml9UeU 3oBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=FW0kPxqhsrE5PAwxkUFnA2OgS8T0HJc5QEp3laKoQE0=; b=e0qOppL0vmFSZO2CTz6+VjgqcV1DvLG5eiiysyu5odBUrIjcvu2Ub5YhN3d1w/xBO6 Yt5C9k/CxLPhWy2kwk6rE/fR27avkmcp+eUFOhoqae3uyFpDYB6M6XjXPJv2AApV4wJr JaB50abGwQRDnuASofngiFIa/AbffWpWPTb9DxMwcZ80a1UxsDivpJ0FHTCa9nyOtF6s qoL7YrKIeiSbK3deQsgvsQUYZjjI7ndiamC8kv0PUdvrs07/xLW6r/JnI3FvPDTLvGCq Hu947SEqMgiR9FJJdVSiPf5InUT4xjBwv8DvumnpmUz+c7YTLG+DFILWEnawnQ7AsVys nMKQ== Received: by 10.60.7.196 with SMTP id l4mr38514733oea.8.1332952156553; Wed, 28 Mar 2012 09:29:16 -0700 (PDT) Received: by 10.60.7.196 with SMTP id l4mr38514291oea.8.1332952151658; Wed, 28 Mar 2012 09:29:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.63.231 with HTTP; Wed, 28 Mar 2012 09:28:51 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Wed, 28 Mar 2012 18:28:51 +0200 Message-ID: To: Fred Baker Content-Type: multipart/alternative; boundary=e89a8f643910808f9204bc501bf9 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmes3BN7IV+1OOM8eMmAV/D9VzwrVdO141Go4PwzpgYdbyhIbekbqN6SUyczEglzPyK269AJQwKlnuRdLi3f4tGd5p4JqhN0r3WGo11z+UuQrMuQj9CAGfNRvrXjwhSp8AB2pSV Cc: IPv6 Operations , Softwire Chairs , v6ops-ads@tools.ietf.org, draft-ietf-v6ops-464xlat@tools.ietf.org Subject: Re: [v6ops] A way forward for 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 16:29:22 -0000 --e89a8f643910808f9204bc501bf9 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Mar 27, 2012 at 04:34, Fred Baker wrote: > The first is a specification - a BCP - for the CLAT service. It refers to > RFCs 6052/6144/6145/6146/6147, and describes how translation is used in > this context using normative language. It does not refer to a prefix::/96; > it refers to RFC 6052. My understanding is that several people have said > that this specification is interesting and useful. > Sounds reasonable to me. I take that it can't become a proposed standard because proposed standards are, by definition, new specifications and thus can'e be addressed in v6ops? --e89a8f643910808f9204bc501bf9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Mar 27, 2012 at 04:34, Fred Baker <fred@cisco.com> wrote:
The first is a specification - a BCP - for the CLAT service. It refers to R= FCs 6052/6144/6145/6146/6147, and describes how translation is used in this= context using normative language. It does not refer to a prefix::/96; it r= efers to RFC 6052. My understanding is that several people have said that t= his specification is interesting and useful.

Sounds reasonable to me.

I take that it can't become a proposed standard because propose= d standards are, by definition, new specifications and thus can'e be ad= dressed in v6ops?
--e89a8f643910808f9204bc501bf9-- From fred@cisco.com Wed Mar 28 09:56:47 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98A321E828D for ; Wed, 28 Mar 2012 09:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.946 X-Spam-Level: X-Spam-Status: No, score=-109.946 tagged_above=-999 required=5 tests=[AWL=-0.547, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_31=0.6, 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 77U2IalXJPAl for ; Wed, 28 Mar 2012 09:56:47 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 182D321E8270 for ; Wed, 28 Mar 2012 09:56:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=914; q=dns/txt; s=iport; t=1332953807; x=1334163407; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to:content-transfer-encoding; bh=3oMqamjjQKLpPE30hIXI22ZaT8bvTXhdS0s1VCGrRwE=; b=c/Th+AxKdV941bvX254dJamqh7BWM9LbQmfb8V+BmYEAQUPNupo2pvFH wj+Ow3GT0OPRz2x0RdpZlwQEg4lJHcTgUeITxEzenpMW6vkDtHWdK7biW 9GihuJvY4N26etjPb45+j/x+Zw2CO6eF7YyptaQsrv33IUjJZ0bCPzhhX M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAH1Cc0+Q/khL/2dsb2JhbABFuGyBB4IJAQEBAwESASc/BQsLGC5XBhMih2MFnAWfI5AvYwSVYYVviFaBaIJp X-IronPort-AV: E=Sophos;i="4.73,662,1325462400"; d="scan'208";a="133635453" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 28 Mar 2012 16:56:44 +0000 Received: from dhcp-5155.meeting.ietf.org (ams3-vpn-dhcp4466.cisco.com [10.61.81.113]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q2SGuhd9030966; Wed, 28 Mar 2012 16:56:43 GMT Received: from [127.0.0.1] by dhcp-5155.meeting.ietf.org (PGP Universal service); Wed, 28 Mar 2012 18:56:44 +0200 X-PGP-Universal: processed; by dhcp-5155.meeting.ietf.org on Wed, 28 Mar 2012 18:56:44 +0200 Mime-Version: 1.0 (Apple Message framework v1084) From: Fred Baker In-Reply-To: Date: Wed, 28 Mar 2012 18:56:32 +0200 Message-Id: References: To: Lorenzo Colitti X-Mailer: Apple Mail (2.1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: IPv6 Operations , Softwire Chairs , v6ops-ads@tools.ietf.org, draft-ietf-v6ops-464xlat@tools.ietf.org Subject: Re: [v6ops] A way forward for 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 16:56:48 -0000 On Mar 28, 2012, at 6:28 PM, Lorenzo Colitti wrote: > On Tue, Mar 27, 2012 at 04:34, Fred Baker wrote: > The first is a specification - a BCP - for the CLAT service. It refers = to RFCs 6052/6144/6145/6146/6147, and describes how translation is used = in this context using normative language. It does not refer to a = prefix::/96; it refers to RFC 6052. My understanding is that several = people have said that this specification is interesting and useful. >=20 > Sounds reasonable to me. >=20 > I take that it can't become a proposed standard because proposed = standards are, by definition, new specifications and thus can'e be = addressed in v6ops? In part. For another part, while it would make sense to move RFC = 6145/6146/6147 through the PS/DS/FS/OS (Obsolete Standard) sequence, I'm = not sure how you would carry out a plugfest for 464XLAT as a = specification.= From internet-drafts@ietf.org Wed Mar 28 10:19:35 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0F221E82DD; Wed, 28 Mar 2012 10:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 VF0s-67WKp4A; Wed, 28 Mar 2012 10:19:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26CA521E80A4; Wed, 28 Mar 2012 10:19:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120328171935.10664.16539.idtracker@ietfa.amsl.com> Date: Wed, 28 Mar 2012 10:19:35 -0700 Cc: v6ops@ietf.org Subject: [v6ops] I-D Action: draft-ietf-v6ops-ipv6-discard-prefix-03.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 17:19:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the IPv6 Operations Working Group of the = IETF. Title : A Discard Prefix for IPv6 Author(s) : Nick Hilliard Filename : draft-ietf-v6ops-ipv6-discard-prefix-03.txt Pages : 6 Date : 2012-03-28 Remote triggered black hole filtering describes a method of mitigating the effects of denial-of-service attacks by selectively discarding traffic based on source or destination address. Remote triggered black hole routing describes a method of selectively re- routing traffic into a sinkhole router (for further analysis) based on destination address. This document updates RFC5156 by explaining why a unique IPv6 prefix should be formally assigned by IANA for the purpose of facilitating IPv6 remote triggered black hole filtering and routing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-discard-prefix-03= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-ipv6-discard-prefix-03.= txt From xing@cernet.edu.cn Wed Mar 28 13:35:24 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E826921F8753 for ; Wed, 28 Mar 2012 13:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.436 X-Spam-Level: X-Spam-Status: No, score=-92.436 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 Vf6B7o0G8Urw for ; Wed, 28 Mar 2012 13:35:23 -0700 (PDT) Received: from cernet.edu.cn (sea.net.edu.cn [202.112.39.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2762A21F8684 for ; Wed, 28 Mar 2012 13:35:21 -0700 (PDT) Received: by ajax-webmail-centos (Coremail) ; Thu, 29 Mar 2012 04:32:00 +0800 (CST) Date: Thu, 29 Mar 2012 04:32:00 +0800 (CST) From: =?GBK?B?wO7Qxw==?= To: "Wojciech Dec" Message-ID: <1dfb37f.b02.1365b020553.Coremail.xing@cernet.edu.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_6830_31413480.1332966720845" X-Originating-IP: [130.129.69.238] X-Priority: 3 X-Mailer: Coremail Webmail Server Version XT2.1.3 build 110627(13838.3863.3865) Copyright (c) 2002-2012 www.mailtech.cn mtdemo X-CM-TRANSID: AQAAf3AbQQNBdXNP5UcUAA--.659W X-CM-SenderInfo: p0lqwqxfhu0vvwohv3gofq/1tbiAQAHDE58k2P7KgACsb X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VWkKw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU= Cc: IPv6 Operations , draft-ietf-v6ops-464xlat@tools.ietf.org, v6ops-ads@tools.ietf.org, Softwire Chairs Subject: Re: [v6ops] A way forward for 464XLAT X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 20:35:25 -0000 ------=_Part_6830_31413480.1332966720845 Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 09ogMjAxMi8zLzI4IDIzOjIyLCBXb2pjaWVjaCBEZWMg0LS1wDpIaSBGcmVkLAoKdGhlIHByb3Bv c2VkIHdheSBmb3J3YXJkIG1ha2VzIHNlbnNlIHRvIG1lLiBUaGVyZSBhcHBlYXJzIHRvIGJlIGEg ZGVzaXJlIHRvIGhhdmUgYW4gImltcGxlbWVudGVycyBzcGVjIiBmb3IgYSBOQVQ2NCBjbGllbnQt ZGV2aWNlLCBhbG9uZyB3aXRoIHNvbWUgZGVmYXVsdCBzZXR0aW5ncywgYW5kIGFzc3VtaW5nIHRo YXQgdGhpcyBpcyBiYXNlZCBvbiBleGlzdGluZyBOQVQ2NCBzdGFuZGFyZHMgYW5kIG5vdCBiYXNl ZCBvbiBzb21lICJoYXJkIGNvZGVkIiB2YWx1ZXMsIGl0J3MgZmluZSB0byBwcm9ncmVzcyBhcyBh IHNlcGFyYXRlIGRyYWZ0LgoKKzEuICB4aW5nCgoKUmVnYXJkcywKV29qLgoKCk9uIDI3IE1hcmNo IDIwMTIgMDQ6MzQsIEZyZWQgQmFrZXI8ZnJlZEBjaXNjby5jb20+IHdyb3RlOgpJIHdvbid0IHNh eSAiY2hhaXIgaGF0IG9mZiIsIGJ1dCAiY2hhaXIgaGF0IGZhc2hpb25hYmx5IHRpcHBlZCB0byBv bmUgc2lkZS4iIEknbSB0cnlpbmcgdG8gZmlndXJlIG91dCB0aGUgYmVzdCB3YXkgZm9yd2FyZCBm b3IgdGhlIDQ2NFhMQVQgc3BlY2lmaWNhdGlvbiBpbiB2aWV3IG9mIGNvbW1lbnRzIGJ5IHRoZSBh dXRob3JzIG9mCgogICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1k ZXNwcmVzLXNvZnR3aXJlLTRyZC11CiAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWZ1LXNvZnR3aXJlLTRyZC1taWIKICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtZnUtc29mdHdpcmUtbWFwLW1pYgogICAgICAgaHR0cDovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1qaWFuZy1zb2Z0d2lyZS1tYXAtcmFkaXVzCiAgICAg ICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1kdC1zb2Z0d2lyZS1tYXAt ZGVwbG95bWVudAogICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1t ZHQtc29mdHdpcmUtbWFwLWRoY3Atb3B0aW9uCiAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LW1kdC1zb2Z0d2lyZS1tYXAtZW5jYXBzdWxhdGlvbgogICAgICAgaHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1tZHQtc29mdHdpcmUtbWFwLXRyYW5z bGF0aW9uCiAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1kdC1z b2Z0d2lyZS1tYXBwaW5nLWFkZHJlc3MtYW5kLXBvcnQKICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtbXVyYWthbWktc29mdHdpcmUtNHJkCiAgICAgICBodHRwOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNhcmlrYXlhLXNvZnR3aXJlLTRyZG11bHRp Y2FzdAoKYW5kIG5vdGFibHkgdGhlIGNvbW1lbnRzIGluIHRoZSB3b3JraW5nIGdyb3VwIG1lZXRp bmcgTW9uZGF5IG1vcm5pbmcuIFdoeSBkbyBJIGNvbW1lbnQgb24gdGhlICJjaGFpciBoYXQiPyBX ZWxsLCBJJ20gbm90ICJnaXZpbmcgaW5zdHJ1Y3Rpb24iLCBhcyBjaGFpcjsgSSdtIGZsb2F0aW5n IGFuIGlkZWEuIElmIHRoZSBpZGVhIGlzIGFjY2VwdGFibGUsIHRoZSBpZGVhIG1heSBiZWNvbWUg aW5zdHJ1Y3Rpb247IGlmIGl0IG5lZWRzIHRvIGJlIG1vZGlmaWVkLCBJIHdhbnQgdG8gaGF2ZSB0 aGF0IGNvbnZlcnNhdGlvbi4KClRoZSBvYmplY3Rpb25zIHJhaXNlZCBpbiB0aGUgd29ya2luZyBn cm91cCBjb21lIGRvd24gdG86CiAgIC0gdGhlIGF1dGhvcnMgb2Ygc2FpZCBvdGhlciBkb2N1bWVu dHMgd291bGQgbGlrZSB0byBoYXZlIGEgY29udmVyc2F0aW9uIHdpdGggdGhlIDQ2NFhMQVQgZm9s a3MKICAgLSBXaGF0J3MgdGhpcyBhYm91dCBhIHByZWZpeDo6Lzk2PwogICAtIFdoYXQncyB0aGlz IGFib3V0IGEgcHJveHkgc2VydmljZT8KICAgLSBXaGF0J3MgdGhpcyBhYm91dCBub3JtYXRpdmUg bGFuZ3VhZ2U/CiAgIC0gSG93IGRvZXMgaXQgZml0IHRoZSB0aGUgbWR0LXNvZnR3aXJlLW1hcCBz cGVjaWZpY2F0aW9ucywgd2hpY2gKICAgICBhcHBlYXIgdG8gaGF2ZSBhIGdyb3dpbmcgY29uc2Vu c3VzIGJlaGluZCB0aGVtIGluIHNvZnR3aXJlPwoKQmVmb3JlIHlvdSBjb250aW51ZSByZWFkaW5n IHRoaXMgbm90ZSwgcGxlYXNlIHN0b3AgYW5kIHJlYWQgdGhlc2UgdHdvIHNlY3Rpb25zOgogICBo dHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMyMDI2I3NlY3Rpb24tNC4yLjIKICAgaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMjAyNiNzZWN0aW9uLTUKCj5Gcm9tIG15IHBlcnNwZWN0 aXZlLCBhbmQgZnJvbSByZWFkaW5nIHRob3NlIGRlZmluaXRpb25zLCBhbiBJbmZvcm1hdGlvbmFs IERvY3VtZW50IGlzIGEgd2hpdGUgcGFwZXIsIHdoaWxlIGEgQkNQIGlzIHNvbWV0aGluZyB0aGF0 IGEgc2lnbmlmaWNhbnQgYW5kIHJlbGV2YW50IHBhcnQgb2YgdGhlIEludGVybmV0IENPbW11bml0 eSBhZ3JlZXMgdG8sIGFuZAoKLi4uc2luY2UgdGhlIEludGVybmV0IGl0c2VsZiBpcyBjb21wb3Nl ZCBvZiBuZXR3b3JrcyBvcGVyYXRlZCBieSBhIGdyZWF0CiAgdmFyaWV0eSBvZiBvcmdhbml6YXRp b25zLCB3aXRoIGRpdmVyc2UgZ29hbHMgYW5kIHJ1bGVzLCBnb29kIHVzZXIKICBzZXJ2aWNlIHJl cXVpcmVzIHRoYXQgdGhlIG9wZXJhdG9ycyBhbmQgYWRtaW5pc3RyYXRvcnMgb2YgdGhlCiAgSW50 ZXJuZXQgZm9sbG93IHNvbWUgY29tbW9uIGd1aWRlbGluZXMgZm9yIHBvbGljaWVzIGFuZCBvcGVy YXRpb25zLgoKSW4gb3RoZXIgd29yZHMsIG9wZXJhdGlvbmFsIHNlcnZpY2UgbW9kZWxzLCB3aGls ZSBub3Qgc3RyaWN0bHkgc3BlYWtpbmcgInByb3RvY29scyIsIGNhbiBiZSBkZXNjcmliZWQgaW4g YSBCQ1AgKnN0YW5kYXJkKiBhcyAiaG93IHRvIGltcGxlbWVudCBhIGNlcnRhaW4gc2VydmljZSIu IFRoaXMgaXMgaW4gbm8gc2Vuc2UgInRoZSBiZXN0IiBvciAib25seSB3YXkgdG8gZGVwbG95IFJG Q3MgNjE0NS82MTQ2IiwgYnV0IGl0IG1pZ2h0IGJlICJ0aGUgYmVzdCB3YXkgdG8gZGVwbG95IHRo ZSBDTEFUIHNlcnZpY2UiLiB2Nm9wcyBpcyBhdXRob3JpemVkLCBieSBjaGFydGVyLCB0byB3cml0 ZSBpbmZvcm1hdGlvbmFsIGFuZCBCQ1AgZG9jdW1lbnRzLgoKQW5kIHNpbmNlIGEgQkNQIGRlc2Ny aWJlcyB0aGUgc2V0IG9mIHRoaW5ncyB0aGF0IG9uZSBNVVNUIG9yIFNIT1VMRCBkbyBpbiBkZXBs b3lpbmcgc3VjaCBhIHNlcnZpY2UsIFJGQyAyMTE5IGxhbmd1YWdlIHJlZ2FyZGluZyB0aGF0IHNw ZWNpZmljIHNlcnZpY2UgbWF5IGJlIGFjY2VwdGFibGUgaW4gYSBCQ1AgZGVzY3JpYmluZyB0aGF0 IHNlcnZpY2UuCgoKV2l0aCB0aGF0IHByZXBhcmF0b3J5IHJlYXNvbmluZywgaXQgc2VlbXMgdG8g bWUgdGhhdCB3ZSBuZWVkIHRvIHNlcGFyYXRlIHRoZSBjb250ZW50aW91cyBwYXJ0cyBvZiB0aGUg c3BlY2lmaWNhdGlvbiBzbyB0aGF0IHVuY29udGVudGlvdXMgcGFydHMgY2FuIGdvIGZvcndhcmQs IGFuZCBvdGhlciBwYXJ0cyBjYW4gYmUgZGlzY3Vzc2VkIC0gd2hldGhlciBpbiB0aGlzIHdvcmtp bmcgZ3JvdXAgb3IgYW5vdGhlciBvbmUuCgoKR2l2ZW4gdGhlIHBvaW50cyBvZiBjb250ZW50aW9u LCBpdCBzZWVtcyB0aGF0IHRoZSBzZXBhcmF0aW9uIG5lZWRzIHRvIGJlIGFtb25nIHRocmVlIGRv Y3VtZW50cy4KClRoZSBmaXJzdCBpcyBhIHNwZWNpZmljYXRpb24gLSBhIEJDUCAtIGZvciB0aGUg Q0xBVCBzZXJ2aWNlLiBJdCByZWZlcnMgdG8gUkZDcyA2MDUyLzYxNDQvNjE0NS82MTQ2LzYxNDcs IGFuZCBkZXNjcmliZXMgaG93IHRyYW5zbGF0aW9uIGlzIHVzZWQgaW4gdGhpcyBjb250ZXh0IHVz aW5nIG5vcm1hdGl2ZSBsYW5ndWFnZS4gSXQgZG9lcyBub3QgcmVmZXIgdG8gYSBwcmVmaXg6Oi85 NjsgaXQgcmVmZXJzIHRvIFJGQyA2MDUyLiBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgc2V2ZXJh bCBwZW9wbGUgaGF2ZSBzYWlkIHRoYXQgdGhpcyBzcGVjaWZpY2F0aW9uIGlzIGludGVyZXN0aW5n IGFuZCB1c2VmdWwuCgpUaGUgc2Vjb25kIGlzIGEgc2VwYXJhdGUgc3BlY2lmaWNhdGlvbiBmb3Ig dGhlIHByb3h5IHNlcnZpY2UsIHdoaWNoIGlzIGNvbnRlbnRpb3VzLiBCZWluZyBzZXBhcmF0ZWQs IGl0IGNhbiBiZSBkaXNjdXNzZWQgYW5kIGJlYXRlbiB0byBkZWF0aCBhcyBuZWVkZWQuIFRoZSBm aXJzdCBzcGVjaWZpY2F0aW9uIHNheXMgdGhhdCB0aGUgQ0xBVCBzZXJ2aWNlIE1BWSBpbXBsZW1l bnQgdGhpcyBwcm94eSBzZXJ2aWNlLiBJJ20gbm90IHN1cmUgd2hldGhlciB0aGF0IGlzIEJDUCBv ciBJbmZvcm1hdGlvbmFsOyB3ZSBjYW4gZGlzY3VzcyB0aGF0IGluIHRoZSBjb250ZXh0IG9mIHRo ZSByZXN0IG9mIHRoZSBkaXNjdXNzaW9uIG9mIHRoZSBwcm94eSBzZXJ2aWNlLgoKVGhlIHRoaXJk IGlzIGEgcmVwb3J0IG9uIHRoZSB0cmlhbCBkZXBsb3ltZW50IG9mIHRoZSBDTEFUIHNlcnZpY2Ug YnkgdGhlIHZhcmlvdXMgY29tcGFuaWVzIGluIHF1ZXN0aW9uLiBUaGlzIGlzIGFuIGluZm9ybWF0 aW9uYWwgZG9jdW1lbnQuCgpBbSBJIG1ha2luZyBzZW5zZT8gV291bGQgdGhpcyBiZSBhbiBhY2Nl cHRhYmxlIHdheSBmb3J3YXJkPwpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwp2Nm9wcyBtYWlsaW5nIGxpc3QKdjZvcHNAaWV0Zi5vcmcKaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby92Nm9wcwoKCgoKCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCnY2b3BzIG1haWxpbmcgbGlzdAp2Nm9wc0BpZXRm Lm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzCgoKCgo= ------=_Part_6830_31413480.1332966720845 Content-Type: text/html; charset=GBK Content-Transfer-Encoding: base64 09ogMjAxMi8zLzI4IDIzOjIyLCBXb2pjaWVjaCBEZWMg0LS1wDoKPGJsb2NrcXVvdGUgY2l0ZT0i bWlkOkNBRkZqVzRpcCtEc0xUMFZPc0VYcVJzOXRYRUsyemhvTXFxbjZxOV8xVi10eGJDOUZ3d0Bt YWlsLmdtYWlsLmNvbSIgdHlwZT0iY2l0ZSI+SGkgRnJlZCw8YnI+CiAgPGJyPgp0aGUgcHJvcG9z ZWQgd2F5IGZvcndhcmQgbWFrZXMgc2Vuc2UgdG8gbWUuIFRoZXJlIGFwcGVhcnMgdG8gYmUgYSBk ZXNpcmUKIHRvIGhhdmUgYW4gImltcGxlbWVudGVycyBzcGVjIiBmb3IgYSBOQVQ2NCBjbGllbnQt ZGV2aWNlLCBhbG9uZyB3aXRoIApzb21lIGRlZmF1bHQgc2V0dGluZ3MsIGFuZCBhc3N1bWluZyB0 aGF0IHRoaXMgaXMgYmFzZWQgb24gZXhpc3RpbmcgTkFUNjQKIHN0YW5kYXJkcyBhbmQgbm90IGJh c2VkIG9uIHNvbWUgImhhcmQgY29kZWQiIHZhbHVlcywgaXQncyBmaW5lIHRvIApwcm9ncmVzcyBh cyBhIHNlcGFyYXRlIGRyYWZ0Ljxicj4KPC9ibG9ja3F1b3RlPgo8YnI+CisxLiZuYnNwOyB4aW5n PGJyPgo8YnI+CjxibG9ja3F1b3RlIGNpdGU9Im1pZDpDQUZGalc0aXArRHNMVDBWT3NFWHFSczl0 WEVLMnpob01xcW42cTlfMVYtdHhiQzlGd3dAbWFpbC5nbWFpbC5jb20iIHR5cGU9ImNpdGUiPgog IDxicj4KUmVnYXJkcyw8YnI+Cldvai48YnI+CiAgPGJyPgogIDxkaXYgY2xhc3M9ImdtYWlsX3F1 b3RlIj5PbiAyNyBNYXJjaCAyMDEyIDA0OjM0LCBGcmVkIEJha2VyIDxzcGFuIGRpcj0ibHRyIj4m bHQ7PGEgdGFyZ2V0PSJfYmxhbmsiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0ibWFpbHRv OmZyZWRAY2lzY28uY29tIj5mcmVkQGNpc2NvLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+ PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0iYm9yZGVyLWxlZnQ6IDFweCBz b2xpZCByZ2IoMjA0LCAyMDQsIDIwNCk7IG1hcmdpbjogMHB0IDBwdCAwcHQgMC44ZXg7IHBhZGRp bmctbGVmdDogMWV4OyI+Ckkgd29uJ3Qgc2F5ICJjaGFpciBoYXQgb2ZmIiwgYnV0ICJjaGFpciBo YXQgZmFzaGlvbmFibHkgdGlwcGVkIHRvIG9uZSAKc2lkZS4iIEknbSB0cnlpbmcgdG8gZmlndXJl IG91dCB0aGUgYmVzdCB3YXkgZm9yd2FyZCBmb3IgdGhlIDQ2NFhMQVQgCnNwZWNpZmljYXRpb24g aW4gdmlldyBvZiBjb21tZW50cyBieSB0aGUgYXV0aG9ycyBvZjxicj4KCjxicj4KICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0iaHR0cDov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1kZXNwcmVzLXNvZnR3aXJlLTRyZC11IiB0 YXJnZXQ9Il9ibGFuayI+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1kZXNw cmVzLXNvZnR3aXJlLTRyZC11PC9hPjxicj4KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxh IG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1mdS1zb2Z0d2lyZS00cmQtbWliIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1mdS1zb2Z0d2lyZS00cmQtbWliPC9hPjxicj4K ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJl Zj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1mdS1zb2Z0d2lyZS1tYXAt bWliIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1mdS1zb2Z0d2lyZS1tYXAtbWliPC9hPjxicj4KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1qaWFuZy1zb2Z0d2lyZS1tYXAtcmFkaXVzIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1qaWFuZy1zb2Z0d2lyZS1tYXAt cmFkaXVzPC9hPjxicj4KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIG1vei1kby1ub3Qt c2VuZD0idHJ1ZSIgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1t ZHQtc29mdHdpcmUtbWFwLWRlcGxveW1lbnQiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1kdC1zb2Z0d2lyZS1tYXAtZGVwbG95bWVudDwvYT48 YnI+CiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUi IGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWR0LXNvZnR3aXJl LW1hcC1kaGNwLW9wdGlvbiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtbWR0LXNvZnR3aXJlLW1hcC1kaGNwLW9wdGlvbjwvYT48YnI+CiAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Imh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbWR0LXNvZnR3aXJlLW1hcC1lbmNh cHN1bGF0aW9uIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1tZHQtc29mdHdpcmUtbWFwLWVuY2Fwc3VsYXRpb248L2E+PGJyPgogJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJodHRwOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1kdC1zb2Z0d2lyZS1tYXAtdHJhbnNsYXRp b24iIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LW1kdC1zb2Z0d2lyZS1tYXAtdHJhbnNsYXRpb248L2E+PGJyPgogJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJodHRwOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1kdC1zb2Z0d2lyZS1tYXBwaW5nLWFkZHJlc3MtYW5kLXBv cnQiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LW1kdC1zb2Z0d2lyZS1tYXBwaW5nLWFkZHJlc3MtYW5kLXBvcnQ8L2E+PGJyPgogJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7PGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBocmVmPSJodHRwOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW11cmFrYW1pLXNvZnR3aXJlLTRyZCIgdGFy Z2V0PSJfYmxhbmsiPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbXVyYWth bWktc29mdHdpcmUtNHJkPC9hPjxicj4KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIG1v ei1kby1ub3Qtc2VuZD0idHJ1ZSIgaHJlZj0iaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1zYXJpa2F5YS1zb2Z0d2lyZS00cmRtdWx0aWNhc3QiIHRhcmdldD0iX2JsYW5rIj5o dHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXNhcmlrYXlhLXNvZnR3aXJlLTRy ZG11bHRpY2FzdDwvYT48YnI+Cjxicj4KYW5kIG5vdGFibHkgdGhlIGNvbW1lbnRzIGluIHRoZSB3 b3JraW5nIGdyb3VwIG1lZXRpbmcgTW9uZGF5IG1vcm5pbmcuIApXaHkgZG8gSSBjb21tZW50IG9u IHRoZSAiY2hhaXIgaGF0Ij8gV2VsbCwgSSdtIG5vdCAiZ2l2aW5nIGluc3RydWN0aW9uIiwKIGFz IGNoYWlyOyBJJ20gZmxvYXRpbmcgYW4gaWRlYS4gSWYgdGhlIGlkZWEgaXMgYWNjZXB0YWJsZSwg dGhlIGlkZWEgbWF5CiBiZWNvbWUgaW5zdHJ1Y3Rpb247IGlmIGl0IG5lZWRzIHRvIGJlIG1vZGlm aWVkLCBJIHdhbnQgdG8gaGF2ZSB0aGF0IApjb252ZXJzYXRpb24uPGJyPgoKPGJyPgpUaGUgb2Jq ZWN0aW9ucyByYWlzZWQgaW4gdGhlIHdvcmtpbmcgZ3JvdXAgY29tZSBkb3duIHRvOjxicj4KICZu YnNwOyAmbmJzcDstIHRoZSBhdXRob3JzIG9mIHNhaWQgb3RoZXIgZG9jdW1lbnRzIHdvdWxkIGxp a2UgdG8gaGF2ZSBhIGNvbnZlcnNhdGlvbiB3aXRoIHRoZSA0NjRYTEFUIGZvbGtzPGJyPgogJm5i c3A7ICZuYnNwOy0gV2hhdCdzIHRoaXMgYWJvdXQgYSBwcmVmaXg6Oi85Nj88YnI+CiAmbmJzcDsg Jm5ic3A7LSBXaGF0J3MgdGhpcyBhYm91dCBhIHByb3h5IHNlcnZpY2U/PGJyPgogJm5ic3A7ICZu YnNwOy0gV2hhdCdzIHRoaXMgYWJvdXQgbm9ybWF0aXZlIGxhbmd1YWdlPzxicj4KICZuYnNwOyAm bmJzcDstIEhvdyBkb2VzIGl0IGZpdCB0aGUgdGhlIG1kdC1zb2Z0d2lyZS1tYXAgc3BlY2lmaWNh dGlvbnMsIHdoaWNoPGJyPgogJm5ic3A7ICZuYnNwOyAmbmJzcDthcHBlYXIgdG8gaGF2ZSBhIGdy b3dpbmcgY29uc2Vuc3VzIGJlaGluZCB0aGVtIGluIHNvZnR3aXJlPzxicj4KPGJyPgpCZWZvcmUg eW91IGNvbnRpbnVlIHJlYWRpbmcgdGhpcyBub3RlLCBwbGVhc2Ugc3RvcCBhbmQgcmVhZCB0aGVz ZSB0d28gc2VjdGlvbnM6PGJyPgogJm5ic3A7ICZuYnNwOzxhIG1vei1kby1ub3Qtc2VuZD0idHJ1 ZSIgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMjAyNiNzZWN0aW9uLTQuMi4y IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMjAyNiNzZWN0 aW9uLTQuMi4yPC9hPjxicj4KICZuYnNwOyAmbmJzcDs8YSBtb3otZG8tbm90LXNlbmQ9InRydWUi IGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzIwMjYjc2VjdGlvbi01IiB0YXJn ZXQ9Il9ibGFuayI+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMjAyNiNzZWN0aW9uLTU8 L2E+PGJyPgo8YnI+CiZndDtGcm9tIG15IHBlcnNwZWN0aXZlLCBhbmQgZnJvbSByZWFkaW5nIHRo b3NlIGRlZmluaXRpb25zLCBhbiAKSW5mb3JtYXRpb25hbCBEb2N1bWVudCBpcyBhIHdoaXRlIHBh cGVyLCB3aGlsZSBhIEJDUCBpcyBzb21ldGhpbmcgdGhhdCBhCiBzaWduaWZpY2FudCBhbmQgcmVs ZXZhbnQgcGFydCBvZiB0aGUgSW50ZXJuZXQgQ09tbXVuaXR5IGFncmVlcyB0bywgYW5kPGJyPgo8 YnI+Ci4uLnNpbmNlIHRoZSBJbnRlcm5ldCBpdHNlbGYgaXMgY29tcG9zZWQgb2YgbmV0d29ya3Mg b3BlcmF0ZWQgYnkgYSBncmVhdDxicj4KICZuYnNwOyB2YXJpZXR5IG9mIG9yZ2FuaXphdGlvbnMs IHdpdGggZGl2ZXJzZSBnb2FscyBhbmQgcnVsZXMsIGdvb2QgdXNlcjxicj4KICZuYnNwOyBzZXJ2 aWNlIHJlcXVpcmVzIHRoYXQgdGhlIG9wZXJhdG9ycyBhbmQgYWRtaW5pc3RyYXRvcnMgb2YgdGhl PGJyPgogJm5ic3A7IEludGVybmV0IGZvbGxvdyBzb21lIGNvbW1vbiBndWlkZWxpbmVzIGZvciBw b2xpY2llcyBhbmQgb3BlcmF0aW9ucy48YnI+Cjxicj4KSW4gb3RoZXIgd29yZHMsIG9wZXJhdGlv bmFsIHNlcnZpY2UgbW9kZWxzLCB3aGlsZSBub3Qgc3RyaWN0bHkgc3BlYWtpbmcgCiJwcm90b2Nv bHMiLCBjYW4gYmUgZGVzY3JpYmVkIGluIGEgQkNQICpzdGFuZGFyZCogYXMgImhvdyB0byBpbXBs ZW1lbnQgYQogY2VydGFpbiBzZXJ2aWNlIi4gVGhpcyBpcyBpbiBubyBzZW5zZSAidGhlIGJlc3Qi IG9yICJvbmx5IHdheSB0byBkZXBsb3kKIFJGQ3MgNjE0NS82MTQ2IiwgYnV0IGl0IG1pZ2h0IGJl ICJ0aGUgYmVzdCB3YXkgdG8gZGVwbG95IHRoZSBDTEFUIApzZXJ2aWNlIi4gdjZvcHMgaXMgYXV0 aG9yaXplZCwgYnkgY2hhcnRlciwgdG8gd3JpdGUgaW5mb3JtYXRpb25hbCBhbmQgCkJDUCBkb2N1 bWVudHMuPGJyPgoKPGJyPgpBbmQgc2luY2UgYSBCQ1AgZGVzY3JpYmVzIHRoZSBzZXQgb2YgdGhp bmdzIHRoYXQgb25lIE1VU1Qgb3IgU0hPVUxEIGRvIAppbiBkZXBsb3lpbmcgc3VjaCBhIHNlcnZp Y2UsIFJGQyAyMTE5IGxhbmd1YWdlIHJlZ2FyZGluZyB0aGF0IHNwZWNpZmljIApzZXJ2aWNlIG1h eSBiZSBhY2NlcHRhYmxlIGluIGEgQkNQIGRlc2NyaWJpbmcgdGhhdCBzZXJ2aWNlLjxicj4KPGJy Pgo8YnI+CldpdGggdGhhdCBwcmVwYXJhdG9yeSByZWFzb25pbmcsIGl0IHNlZW1zIHRvIG1lIHRo YXQgd2UgbmVlZCB0byBzZXBhcmF0ZQogdGhlIGNvbnRlbnRpb3VzIHBhcnRzIG9mIHRoZSBzcGVj aWZpY2F0aW9uIHNvIHRoYXQgdW5jb250ZW50aW91cyBwYXJ0cyAKY2FuIGdvIGZvcndhcmQsIGFu ZCBvdGhlciBwYXJ0cyBjYW4gYmUgZGlzY3Vzc2VkIC0gd2hldGhlciBpbiB0aGlzIAp3b3JraW5n IGdyb3VwIG9yIGFub3RoZXIgb25lLjxicj4KCjxicj4KPGJyPgpHaXZlbiB0aGUgcG9pbnRzIG9m IGNvbnRlbnRpb24sIGl0IHNlZW1zIHRoYXQgdGhlIHNlcGFyYXRpb24gbmVlZHMgdG8gYmUgYW1v bmcgdGhyZWUgZG9jdW1lbnRzLjxicj4KPGJyPgpUaGUgZmlyc3QgaXMgYSBzcGVjaWZpY2F0aW9u IC0gYSBCQ1AgLSBmb3IgdGhlIENMQVQgc2VydmljZS4gSXQgcmVmZXJzIAp0byBSRkNzIDYwNTIv NjE0NC82MTQ1LzYxNDYvNjE0NywgYW5kIGRlc2NyaWJlcyBob3cgdHJhbnNsYXRpb24gaXMgdXNl ZCAKaW4gdGhpcyBjb250ZXh0IHVzaW5nIG5vcm1hdGl2ZSBsYW5ndWFnZS4gSXQgZG9lcyBub3Qg cmVmZXIgdG8gYSAKcHJlZml4OjovOTY7IGl0IHJlZmVycyB0byBSRkMgNjA1Mi4gTXkgdW5kZXJz dGFuZGluZyBpcyB0aGF0IHNldmVyYWwgCnBlb3BsZSBoYXZlIHNhaWQgdGhhdCB0aGlzIHNwZWNp ZmljYXRpb24gaXMgaW50ZXJlc3RpbmcgYW5kIHVzZWZ1bC48YnI+Cgo8YnI+ClRoZSBzZWNvbmQg aXMgYSBzZXBhcmF0ZSBzcGVjaWZpY2F0aW9uIGZvciB0aGUgcHJveHkgc2VydmljZSwgd2hpY2gg aXMgCmNvbnRlbnRpb3VzLiBCZWluZyBzZXBhcmF0ZWQsIGl0IGNhbiBiZSBkaXNjdXNzZWQgYW5k IGJlYXRlbiB0byBkZWF0aCBhcwogbmVlZGVkLiBUaGUgZmlyc3Qgc3BlY2lmaWNhdGlvbiBzYXlz IHRoYXQgdGhlIENMQVQgc2VydmljZSBNQVkgCmltcGxlbWVudCB0aGlzIHByb3h5IHNlcnZpY2Uu IEknbSBub3Qgc3VyZSB3aGV0aGVyIHRoYXQgaXMgQkNQIG9yIApJbmZvcm1hdGlvbmFsOyB3ZSBj YW4gZGlzY3VzcyB0aGF0IGluIHRoZSBjb250ZXh0IG9mIHRoZSByZXN0IG9mIHRoZSAKZGlzY3Vz c2lvbiBvZiB0aGUgcHJveHkgc2VydmljZS48YnI+Cgo8YnI+ClRoZSB0aGlyZCBpcyBhIHJlcG9y dCBvbiB0aGUgdHJpYWwgZGVwbG95bWVudCBvZiB0aGUgQ0xBVCBzZXJ2aWNlIGJ5IHRoZQogdmFy aW91cyBjb21wYW5pZXMgaW4gcXVlc3Rpb24uIFRoaXMgaXMgYW4gaW5mb3JtYXRpb25hbCBkb2N1 bWVudC48YnI+Cjxicj4KQW0gSSBtYWtpbmcgc2Vuc2U/IFdvdWxkIHRoaXMgYmUgYW4gYWNjZXB0 YWJsZSB3YXkgZm9yd2FyZD88YnI+Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPgp2Nm9wcyBtYWlsaW5nIGxpc3Q8YnI+CjxhIHRhcmdldD0iX2JsYW5r IiBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Im1haWx0bzp2Nm9wc0BpZXRmLm9yZyI+djZv cHNAaWV0Zi5vcmc8L2E+PGJyPgo8YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdjZvcHMiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Y2b3BzPC9hPjxicj4KPC9ibG9j a3F1b3RlPjwvZGl2PgogIDxicj4KCgogIDxicj4KICA8ZmllbGRzZXQgY2xhc3M9Im1pbWVBdHRh Y2htZW50SGVhZGVyIj48L2ZpZWxkc2V0PgogIDxicj4KICA8cHJlIHdyYXA9IiI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+djZvcHMgbWFpbGluZyBs aXN0PGJyPnY2b3BzQGlldGYub3JnPGJyPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdjZvcHM8YnI+PC9wcmU+CgoKPC9ibG9ja3F1b3RlPgo8YnI+PGJyPjxicj48c3Bhbj48 L3NwYW4+ ------=_Part_6830_31413480.1332966720845-- From cb.list6@gmail.com Wed Mar 28 15:01:15 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65AAF21E80ED for ; Wed, 28 Mar 2012 15:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.444 X-Spam-Level: X-Spam-Status: No, score=-3.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 pRFztmOHMJuF for ; Wed, 28 Mar 2012 15:01:15 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id E322C21E80E9 for ; Wed, 28 Mar 2012 15:01:14 -0700 (PDT) Received: by pbbrq13 with SMTP id rq13so2425198pbb.31 for ; Wed, 28 Mar 2012 15:01:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=H+Y1fkBFrG1w+YfquQAx/lJGdbm0htJ+rjpOmRobIcE=; b=pdIKVxN0avOLlv7YzS8VxTzNZMYdQ+r0/O327DHNckzaBzsz1tlxwl+YzqSnyB+15n OnkDvCru7tzhKweE8DIL89YDRgNfXGqVqqTIQHAg5wcxhG1Wh830SibUh9WTxeV4le0U /j2pa3q1hUARerqbjCTDPUfaw6UH++oycNxchkPhBN1qGppLftBUuIYT5cQEQQQa+GmI WsaLm69r02o5BoNn4vlwbgVnk2scgn5yIqzvICt2HlJI0NV77Hy2rjfueb42JbHAhyuz Q4SgCsw2jB541xrQfIX3LxQFr0kteI9I8Akea9PPcbi1vpaYGNanlrsxccs9d+tGD5FY mt9A== MIME-Version: 1.0 Received: by 10.68.225.229 with SMTP id rn5mr9936526pbc.115.1332972074759; Wed, 28 Mar 2012 15:01:14 -0700 (PDT) Received: by 10.143.160.13 with HTTP; Wed, 28 Mar 2012 15:01:14 -0700 (PDT) Date: Wed, 28 Mar 2012 15:01:14 -0700 Message-ID: From: Cameron Byrne To: IPv6 Ops WG Content-Type: text/plain; charset=ISO-8859-1 Subject: [v6ops] 464XLAT from informational to BCP -- Document Change Manifest X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Mar 2012 22:01:15 -0000 Folks, For the sake of clarity, what i understand from Fred's email, and has been supported by 3 people so far, is that there is desire to move from informational to BCP and some changes are required along the way. I believe these specific changes are required from my reading of Fred's mail, let me know if something is missing: 1. Change document category from informational to BCP 2. Re-insert RFC 2119 keywords 3. Replace all text in section in 6.1 with this one sentence "The XLAT Prefix format used on the CLAT for RFC6145 translation is defined in Section 2.2 of [RFC6052]. " Also, remove all references to /96 in section 6.5. Update diagram in 6.2 to remove /96. 4. The DNS proxy section will add a reference to RFC5625, such as adding the sentence to the beginning of section 6.4 stating "The CLAT SHOULD implement a DNS proxy as defined in RFC 5625." Am I missing something? Are these the agreeable terms of moving forward with 464XLAT as a BCP instead of informational? Thanks for the feedback and helping to clarify the path forward Cameron From dthaler@microsoft.com Thu Mar 29 01:11:06 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBEC521F88BD; Thu, 29 Mar 2012 01:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.279 X-Spam-Level: X-Spam-Status: No, score=-103.279 tagged_above=-999 required=5 tests=[AWL=-0.881, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1, 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 tUU9rW2I0pMT; Thu, 29 Mar 2012 01:11:04 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id AD5CB21F88AD; Thu, 29 Mar 2012 01:11:01 -0700 (PDT) Received: from mail88-ch1-R.bigfish.com (10.43.68.237) by CH1EHSOBE017.bigfish.com (10.43.70.67) with Microsoft SMTP Server id 14.1.225.23; Thu, 29 Mar 2012 08:10:59 +0000 Received: from mail88-ch1 (localhost [127.0.0.1]) by mail88-ch1-R.bigfish.com (Postfix) with ESMTP id AF313260113; Thu, 29 Mar 2012 08:10:59 +0000 (UTC) X-SpamScore: -5 X-BigFish: VS-5(zzc85fh1419Mzz1202hzz8275bh8275dhz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail88-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=dthaler@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail88-ch1 (localhost.localdomain [127.0.0.1]) by mail88-ch1 (MessageSwitch) id 1333008657388408_24714; Thu, 29 Mar 2012 08:10:57 +0000 (UTC) Received: from CH1EHSMHS007.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.252]) by mail88-ch1.bigfish.com (Postfix) with ESMTP id 57D193A0077; Thu, 29 Mar 2012 08:10:57 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 29 Mar 2012 08:10:56 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.2.283.4; Thu, 29 Mar 2012 08:10:46 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) with Microsoft SMTP Server (TLS) id 14.2.283.4; Thu, 29 Mar 2012 01:10:46 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.253]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0283.004; Thu, 29 Mar 2012 01:10:46 -0700 From: Dave Thaler To: "v6ops v6ops WG (v6ops@ietf.org)" Thread-Topic: Report on PCP WG discussion on 6204bis Thread-Index: Ac0M/2Xm6NNFsPRxQDy0hhkfu8nxPgAg8M5A Date: Thu, 29 Mar 2012 08:10:46 +0000 Message-ID: <9B57C850BB53634CACEC56EF4853FF653B4E72BD@TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.42] Content-Type: multipart/alternative; boundary="_000_9B57C850BB53634CACEC56EF4853FF653B4E72BDTK5EX14MBXW604w_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "pcp@ietf.org" , Ralph Droms Subject: [v6ops] FW: Report on PCP WG discussion on 6204bis X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 08:11:06 -0000 --_000_9B57C850BB53634CACEC56EF4853FF653B4E72BDTK5EX14MBXW604w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The PCP WG discussed W-6 and W-7 and what advice it might give to the v6ops= WG on what it might say about the PCP protocol. It was made clear the text w= as a v6ops item, and that the PCP WG is providing review/advice. Fred Baker ask= ed for a report to be posted to the v6ops list, which is this email. Also cc'ing Ralph who was substituting as acting co-chair of the PCP meetin= g in Alain's absence. Raw notes straight from notetaker (on Etherpad) regarding W-6: Q1. Is requirement for PCP client okay? v4-only or dual-stack? Q2. Should PCP server be required in CPE? Just for configuring local state? Francis: No reason to put a SHOULD to the PCP client, and not another protocol that can do the same thing. Dave: current defaults from v6ops: Q1=3Dyes, dual stack; Q2=3Dno Stuart: Apple base station has local (CPE-based) apps Dave: another example is web-based CPE configuration Margaret: we can't make requirements for ALL CPE equipment. "SHOULD" doesn't help me; a PCP client is useless without anything to configure Tom Taylor: server function on the CPE needs PCP, not the CPE per se Simon: any CPE router has the ability to run a local server, so the text as written is sufficient Pete Resnick: we got into this mess because CPEs were too stupid to realize that they might have private addresses on both sides. Not clear on why it's SHOULD not MUST. Assuming proxy on the CPE. Also servers will probably be running on the CPE, so need PCP anyway. Dave: no strong consensus in either direction My recollection regarding the last is that we polled the room, and there wa= s a "weak leaning" towards the current W-6 approach, but no strong consensus. And raw notes from notetaker on the W-7 discussion: PCP DS-Lite mode being discussed in v6ops working group for 6204bis. WG suggestion is that v6ops should remove PCP DS-Lite mode from their requi= rements. As chair, my reading of the PCP WG discussion on W-7 was that the PCP WG did not have consensus on what W-7 should say, should it be kept, and there= fore it is best to remove it pending PCP WG work on ds-lite interaction with pcp= , which is being done in a separate document that still needs significant eff= ort. If another update is done in the future once that work is complete, the WG might very well be able to get consensus at that time. -Dave Thaler --_000_9B57C850BB53634CACEC56EF4853FF653B4E72BDTK5EX14MBXW604w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The PCP WG discussed W-6 and W-7 and what advice = it might give to the v6ops WG

on what it might say about the PCP protocol. = ;  It was made clear the text was a

v6ops item, and that the PCP WG is providing revi= ew/advice.  Fred Baker asked

for a report to be posted to the v6ops list, whic= h is this email.

 

Also cc’ing Ralph who was substituting as a= cting co-chair of the PCP meeting in

Alain’s absence.

 

Raw notes straight from notetaker (on Etherpad) r= egarding W-6:

Q1. Is requirement for= PCP client okay? v4-only or dual-stack?

Q2. Should PCP server = be required in CPE? Just for configuring local state?

Francis: No reason to = put a SHOULD to the PCP client, and not another

protocol that can do t= he same thing.

Dave: current defaults= from v6ops: Q1=3Dyes, dual stack; Q2=3Dno

Stuart: Apple base sta= tion has local (CPE-based) apps

Dave: another example = is web-based CPE configuration

Margaret: we can't mak= e requirements for ALL CPE equipment. "SHOULD"

doesn't help me; a PCP= client is useless without anything to configure

Tom Taylor: server fun= ction on the CPE needs PCP, not the CPE per se

Simon: any CPE router = has the ability to run a local server, so the text

as written is sufficie= nt

Pete Resnick: we got i= nto this mess because CPEs were too stupid to

realize that they migh= t have private addresses on both sides. Not

clear on why it's SHOU= LD not MUST. Assuming proxy on the CPE. Also

servers will probably = be running on the CPE, so need PCP anyway.

Dave: no strong consen= sus in either direction

 

My recollection regarding the last is that we pol= led the room, and there was

a “weak leaning” towards the current = W-6 approach, but no strong consensus.

 

And raw notes from notetaker on the W-7 discussio= n:

PCP DS-Lite mode being di= scussed in v6ops working group for 6204bis.

WG suggestion is that v6o= ps should remove PCP DS-Lite mode from their requirements.

 

As chair, my reading of the PCP WG discussion on = W-7 was that the PCP WG

did not have consensus on what W-7 should say, sh= ould it be kept, and therefore

it is best to remove it pending PCP WG work on ds= -lite interaction with pcp,

which is being done in a separate document that s= till needs significant effort.

If another update is done in the future once that= work is complete, the WG

might very well be able to get consensus at that = time.

 

-Dave Thaler

--_000_9B57C850BB53634CACEC56EF4853FF653B4E72BDTK5EX14MBXW604w_-- From ietfc@btconnect.com Thu Mar 29 04:49:44 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD9421F88FE for ; Thu, 29 Mar 2012 04:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, J_CHICKENPOX_13=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 oq28oweT2MXx for ; Thu, 29 Mar 2012 04:49:44 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr08.btconnect.com [213.123.26.186]) by ietfa.amsl.com (Postfix) with ESMTP id 1706921F88FB for ; Thu, 29 Mar 2012 04:49:43 -0700 (PDT) Received: from host86-162-135-195.range86-162.btcentralplus.com (HELO pc6) ([86.162.135.195]) by c2beaomr08.btconnect.com with SMTP id GUL85105; Thu, 29 Mar 2012 12:49:40 +0100 (BST) Message-ID: <03ec01cd0d99$79e94320$4001a8c0@gateway.2wire.net> From: "t.petch" To: References: <20120322113729.19251.14284.idtracker@ietfa.amsl.com> Date: Thu, 29 Mar 2012 12:48:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4F744C53.00FD, actions=tag X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2012.3.29.105416:17:8.317, ip=86.162.135.195, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __TO_NO_NAME, __MULTIPLE_RCPTS_CC_X2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_PATH, __INT_PROD_LOC, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_1200_1299, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, HTML_00_01, HTML_00_10, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, MULTIPLE_RCPTS, RDNS_SUSP, BODY_SIZE_2000_LESS, BODY_SIZE_7000_LESS X-Junkmail-Status: score=10/50, host=c2beaomr08.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0201.4F744C54.016C,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Cc: dromasca@avaya.com, v6ops@ietf.org, fred.baker@cisco.com Subject: Re: [v6ops] IPR Disclosure: China Mobile Communications Corporation's Statement about IPR related to draft-ietf-v6ops-464xlat-01 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 11:49:45 -0000 Since we are discussing the way forward for the I-D to which this IPR claim applies, can anyone tell me what the claim is and what the terms are? I can view it in Chinese but that leaves me none the wiser. Tom Petch ----- Original Message ----- From: "IETF Secretariat" To: ; ; Cc: ; ; ; Sent: Thursday, March 22, 2012 1:37 PM > Dear Masataka Mawatari, Masanobu Kawashima, Cameron Byrne: > > An IPR disclosure that pertains to your Internet-Draft entitled "464XLAT: > Combination of Stateful and Stateless Translation" (draft-ietf-v6ops-464xlat) > was submitted to the IETF Secretariat on 2012-03-22 and has been posted on the > "IETF Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/1730/). The title of the IPR disclosure is > "China Mobile Communications Corporation's Statement about IPR related to draft- > ietf-v6ops-464xlat-01.""); > > The IETF Secretariat > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > > From achatz@forthnetgroup.gr Thu Mar 29 05:41:09 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB0321F8AAA for ; Thu, 29 Mar 2012 05:41:09 -0700 (PDT) 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 kn8MY1UrbvwR for ; Thu, 29 Mar 2012 05:41:08 -0700 (PDT) Received: from mx-out.forthnet.gr (mx-out.forthnet.gr [193.92.150.107]) by ietfa.amsl.com (Postfix) with ESMTP id 12C3D21F85B6 for ; Thu, 29 Mar 2012 05:41:06 -0700 (PDT) Received: from mx-av-06.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-01.forthnet.gr (8.14.4/8.14.4) with ESMTP id q2TCf5YS024257 for ; Thu, 29 Mar 2012 15:41:05 +0300 Received: from MX-IN-01.forthnet.gr (mx-in-01.forthnet.gr [193.92.150.23]) by mx-av-06.forthnet.gr (8.14.4/8.14.4) with ESMTP id q2TCf5Z8004668 for ; Thu, 29 Mar 2012 15:41:05 +0300 Received: from [10.216.6.237] ([93.158.43.148]) (authenticated bits=0) by MX-IN-01.forthnet.gr (8.14.4/8.14.4) with ESMTP id q2TCeo4W031662; Thu, 29 Mar 2012 15:40:52 +0300 Authentication-Results: MX-IN-01.forthnet.gr smtp.mail=achatz@forthnetgroup.gr; auth=pass (PLAIN) Message-ID: <4F745859.50207@forthnetgroup.gr> Date: Thu, 29 Mar 2012 14:40:57 +0200 From: Tassos Chatzithomaoglou User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: v6ops@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [v6ops] comments about draft-townsley-troan-ipv6-ce-transitioning-02 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:41:09 -0000 Hi, I had a quick look at this draft and i wanted to make some comments. First, i believe it would be good to have some examples of the Information Bases (their structure) used under the Terminology paragraph. > SRIB A Source Address Routing Information Base > containing an entry per delegated prefix. > Each entry points to one or more > Destination Address Routing Tables (DRIB). Replace "Destination Address Routing Tables" with "Destination Address Routing Information Base (DRIB) tables "? > MH-1: An IPv6 CE router MUST create a separate DRIB for each WAN > interface (real or virtual) and installs a route for the > associated delegated prefix, default route and more specific > routes. What kind of route is installed in the DRIB (pointing to the WAN?) for the associated delegated prefix? Or does this refer to a route pointing to a LAN interface? > MH-2: An IPv6 CE router MUST create an SRIB containing entries for > associated delegated prefixes. Each entry points to one or > more DRIBs. An entry points to multiple DRIBs only in the > case where an identical delegated prefix is associated with > multiple WAN interfaces. I guess the last paragraph refers to when having two or more connections to the same ISP. Can't the same DRIB be used in that case, especially if the NH is the same? There is also the following reference under 3, which forbids it, but there could be a pointer from each WAN interface to the DRIB(s). > The CE > router has a single SRIB, and one DRIB associated with each WAN > Interface. > This is important not only > in order to choose the best path, but also because the networks that > the CE are connected to typically employ source address verification > mechanisms. Replace "verification" with "validation" in order to be in accordance with savi? > MH-3: When forwarding a packet from a LAN interface, the CE router > MUST do a longest matching lookup based on the packet's Source > Address in the SRIB. A Destination Address lookup is then > performed in the corresponding DRIB or DRIBs. When there are > multiple equal matches, the route with the lowest cost is > chosen. Who defines the cost and what exactly is it? Is this different from the following under 4.2? > If more than one > interface is selected (which will be the case when more than one > active WAN interface programs a default route in the RIB), then > packets are sent via the interface with the highest configured > preference. If the preference is the same, packets may be load- > balanced. > 6RDS-2: By default, the 6rd virtual interface MUST be assigned a > higher routing cost than a native IPv6 interface. Is this the same as above too? If i'm not mistaken, in your draft routes have costs/metrics (lower is better) and interfaces have preferences (higher is better), but it would be good to clarify that. > As entries in > the NPIB table naturally time out, or if the Native interface is > deactivated, the CGN within the DS-Lite AFTR takes over the NAPT > state of the CE router. Replace "state" with "functionality"? One might think that the current state is "transferred" as it is. > The following table indicates a basic ordering > (least to most preferred) for some of the known IPv4 extension and > IPv6 transition mechanisms under development today. Since "Native IPv4" (which is neither IPv4 extension, nor IPv6 transition) is also included in the table, maybe the above should be rephrased. Also, i didn't notice any reference to the packets (or traffic in general) originating from or terminating to the CER itself. Shouldn't that be included too? -- Tassos From victor.kuarsingh@gmail.com Thu Mar 29 07:46:03 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4CA21F890F for ; Thu, 29 Mar 2012 07:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 LK7t2FPvcvvb for ; Thu, 29 Mar 2012 07:46:02 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id A261921F892A for ; Thu, 29 Mar 2012 07:45:53 -0700 (PDT) Received: by werb10 with SMTP id b10so1263502wer.31 for ; Thu, 29 Mar 2012 07:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-type; bh=3k8Ms8F+6ivEw47R9CGNwOg4eZLNirZucKnKbQ4uA78=; b=KmCfwgYGCBJ10POPlezyJ5boxNSeKGcU6UEQ6ADGtQAEVswPCqwtKyzPGi6aSix+UL uqHgTdSDsxyTtBMMYCxLyniy5VsPi926BEZixebHBwK/yO5d/y2wOMmgzc3oyMin9Dgm Fc0CtZpkN1bkycgQGOb3PCbD6oph41nSol+xPvfMf8X934f5BDkrk1I0KRIHuKSkmUDi SWKnuyoEuA/82mrw0TTG087DGegy/ceLr4Gm/0k7V63ktU7tFJOSOnR+HGr/XmekcdVO vIVKDH+7fRA1+zJogOtLzez1o451WPBf7XERumPAJoUuzEuJFxmeXdmU2LMnM4FbVN8m VzhA== Received: by 10.180.85.35 with SMTP id e3mr6325925wiz.6.1333032352649; Thu, 29 Mar 2012 07:45:52 -0700 (PDT) Received: from [130.129.22.223] (dhcp-16df.meeting.ietf.org. [130.129.22.223]) by mx.google.com with ESMTPS id ex2sm29548260wib.8.2012.03.29.07.45.51 (version=SSLv3 cipher=OTHER); Thu, 29 Mar 2012 07:45:51 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.0.0.100825 Date: Thu, 29 Mar 2012 16:45:53 +0200 From: Victor Kuarsingh To: Message-ID: Thread-Topic: Text Updates for Wireline Incremental IPv6 Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3415884355_11784838" Subject: [v6ops] Text Updates for Wireline Incremental IPv6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:46:03 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3415884355_11784838 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit WG, Can the two mic commenters please send me suggested text updates we can add as per our discussion today. Please add net-new text per the Phase-3 section 5.5 as this time. Please also review text as written in the NAT64 section to see if you think there is updates needed there (section 4.6 in current revision). http://tools.ietf.org/html/draft-ietf-v6ops-wireline-incremental-ipv6-01 (current revision) Regards, Victor K --B_3415884355_11784838 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
WG,

Can  the two mic commenters please send me suggested text updates we c= an add as per our discussion today.  Please add net-new text per the Ph= ase-3 section 5.5 as this time.

Please also review = text as written in the NAT64 section to see if you think there is updates ne= eded there (section 4.6 in current revision).



<= /div>
Victor K
--B_3415884355_11784838-- From bzeeb-lists@lists.zabbadoz.net Thu Mar 29 07:46:05 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC46D21F893C for ; Thu, 29 Mar 2012 07:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.185 X-Spam-Level: X-Spam-Status: No, score=-2.185 tagged_above=-999 required=5 tests=[AWL=0.415, 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 nnaxeEKs47+f for ; Thu, 29 Mar 2012 07:46:05 -0700 (PDT) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by ietfa.amsl.com (Postfix) with ESMTP id 7018E21F890E for ; Thu, 29 Mar 2012 07:46:02 -0700 (PDT) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 2FBB525D3860; Thu, 29 Mar 2012 14:46:01 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 2AD0DBE3B41; Thu, 29 Mar 2012 14:46:00 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 4WV+XBr1JgU3; Thu, 29 Mar 2012 14:45:58 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id B5CC0BE3B40; Thu, 29 Mar 2012 14:45:58 +0000 (UTC) Date: Thu, 29 Mar 2012 14:45:57 +0000 (UTC) From: "Bjoern A. Zeeb" To: Fernando Gont In-Reply-To: <20120308195759.14484.86851.idtracker@ietfa.amsl.com> Message-ID: References: <20120308195759.14484.86851.idtracker@ietfa.amsl.com> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ra-guard-implementation-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 14:46:05 -0000 On Thu, 8 Mar 2012, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IPv6 Operations Working Group of the IETF. > > Title : Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard) > Author(s) : Fernando Gont > Filename : draft-ietf-v6ops-ra-guard-implementation-02.txt > Pages : 18 > Date : 2012-03-08 What I was trying to say at the mic is that there is no reason to drop the packet even if I fail on 3.1 of this draft if I can still make sure that it cannot be an RA. For example the paket could be failing 4861 6.1.2. rule number 1 if the source of the packet is non link-local. However the dratf does not have that restriction. I don't want a switch vendor to drop my valid packets if the feature is on, simply because they applied the draft w/o further thinking and not seeing the entire big picture and other constraints that must apply. /bz PS: this is not the only further restriction that must apply. It could be worded genrally upfront in which cases these rules will apply. -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From fgont@si6networks.com Thu Mar 29 10:35:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C589F21F8860 for ; Thu, 29 Mar 2012 10:35:29 -0700 (PDT) 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 4+2mk4vVwLPH for ; Thu, 29 Mar 2012 10:35:29 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 04D1821F8820 for ; Thu, 29 Mar 2012 10:35:25 -0700 (PDT) Received: from [2001:df8:0:16:1e65:9dff:febe:7f88] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SDJFg-0008SR-76; Thu, 29 Mar 2012 19:35:12 +0200 Message-ID: <4F749D57.7060309@si6networks.com> Date: Thu, 29 Mar 2012 19:35:19 +0200 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <20120308195759.14484.86851.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ra-guard-implementation-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 17:35:29 -0000 Hi, Bjoern, On 03/29/2012 04:45 PM, Bjoern A. Zeeb wrote: > What I was trying to say at the mic is that there is no reason to drop the > packet even if I fail on 3.1 of this draft if I can still make sure that it > cannot be an RA. For example the paket could be failing 4861 6.1.2. > rule number 1 if the source of the packet is non link-local. Rule 3.1 is to prevent an attacker from performing a DoS against the RA-Guard device. That is, if an attacker includes, say, 200 extension headers, we don't want the RA-Guard device to jump through all of them. Note that an implementation could enforce a limit of e.g. 10, allowing a single packet to contain more than one copy of each of all the possible extension headers. If your traffic has the minimum level of sanity, it will pass rule 3.1. Then rule 3.3 will check the Source Address and Hop Limit to avoid false positives. > PS: this is not the only further restriction that must apply. It > could be worded genrally upfront in which cases these rules will > apply. Please let me know if my comment above answers your concerns. That aside, I'm wondering if we should include another rule to have the RA-Guard box policy the Neighbor Advertisements that could otherwise perform a Neighbor Cache poisoning attack for the router's IPv6 address. After all, if we don't policy such packets an attacker might still be able to redirect to itself traffic meant for the first-hop router. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From bzeeb-lists@lists.zabbadoz.net Thu Mar 29 15:18:48 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3642A21F8691 for ; Thu, 29 Mar 2012 15:18:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.374, 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 urXtOPB0Hk-X for ; Thu, 29 Mar 2012 15:18:47 -0700 (PDT) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by ietfa.amsl.com (Postfix) with ESMTP id 5757821F864D for ; Thu, 29 Mar 2012 15:18:47 -0700 (PDT) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 22F7925D3857; Thu, 29 Mar 2012 22:18:46 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 2FF36BE3B9C; Thu, 29 Mar 2012 22:18:45 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id Z-oJpjAKsT7Y; Thu, 29 Mar 2012 22:18:43 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 79495BE3B9B; Thu, 29 Mar 2012 22:18:43 +0000 (UTC) Date: Thu, 29 Mar 2012 22:18:42 +0000 (UTC) From: "Bjoern A. Zeeb" To: Fernando Gont In-Reply-To: <4F749D57.7060309@si6networks.com> Message-ID: References: <20120308195759.14484.86851.idtracker@ietfa.amsl.com> <4F749D57.7060309@si6networks.com> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ra-guard-implementation-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 22:18:48 -0000 On Thu, 29 Mar 2012, Fernando Gont wrote: > Hi, Bjoern, > > On 03/29/2012 04:45 PM, Bjoern A. Zeeb wrote: >> What I was trying to say at the mic is that there is no reason to drop the >> packet even if I fail on 3.1 of this draft if I can still make sure that it >> cannot be an RA. For example the paket could be failing 4861 6.1.2. >> rule number 1 if the source of the packet is non link-local. > > Rule 3.1 is to prevent an attacker from performing a DoS against the > RA-Guard device. > > That is, if an attacker includes, say, 200 extension headers, we don't > want the RA-Guard device to jump through all of them. > > Note that an implementation could enforce a limit of e.g. 10, allowing a > single packet to contain more than one copy of each of all the possible > extension headers. You are still going be the assumption of what sensible thing you might find there today but not tomorrow. IfJohn Doe comes up with a great idea that will require him to do a 10k extension header on a 9k MTU, he'll have to wait 5++++ years to get the entire switch world fixed and given some comments from data center folks - replacing all your switches is something they didn't even decide to do for the v6 rollout but rather disable a feature. Stop thinking to only address yesterday's problems - think 20 years ahead. Avoid posisble problems where you can upfront. And I am also startignt o wonder how big a 3971 packet could possibly be and if that would ever work... Not sure I'd want to drop those at all for RAs? > If your traffic has the minimum level of sanity, it will pass rule 3.1. > Then rule 3.3 will check the Source Address and Hop Limit to avoid false > positives. If I am performning the checkes from 1 to 3 I'll never make 3 if I'll have more than 1 * mtu IPv6 header + extension headers before the ULP as 3.1 clearly states that I shall drop the packet. So maybe you'll also have to be more precise how the evaluation of these rules should happen. > >> PS: this is not the only further restriction that must apply. It >> could be worded genrally upfront in which cases these rules will >> apply. > > Please let me know if my comment above answers your concerns. > > That aside, I'm wondering if we should include another rule to have the > RA-Guard box policy the Neighbor Advertisements that could otherwise > perform a Neighbor Cache poisoning attack for the router's IPv6 address. Please don't mix things up. > After all, if we don't policy such packets an attacker might still be > able to redirect to itself traffic meant for the first-hop router. -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From dean.cheng@huawei.com Thu Mar 29 09:04:10 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE7C21E81FF for ; Thu, 29 Mar 2012 09:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 96qWHZWy6Etl for ; Thu, 29 Mar 2012 09:04:09 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id A772921E816B for ; Thu, 29 Mar 2012 09:04:08 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEU41033; Thu, 29 Mar 2012 12:04:08 -0400 (EDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 09:03:09 -0700 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Mar 2012 09:02:30 -0700 Received: from SZXEML523-MBS.china.huawei.com ([169.254.6.188]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Fri, 30 Mar 2012 00:03:12 +0800 From: Dean cheng To: "v6ops@ietf.org" Thread-Topic: An opion on "auto-transition-selecdtion on CER" Thread-Index: Ac0NxW/MGP6isnkgSD6qs66ECErfLQ== Date: Thu, 29 Mar 2012 16:03:11 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.65.59] Content-Type: multipart/alternative; boundary="_000_DC7880973D477648AC15A3BA66253F6829329B41szxeml523mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mailman-Approved-At: Thu, 29 Mar 2012 20:05:05 -0700 Subject: [v6ops] An opion on "auto-transition-selecdtion on CER" X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 16:04:11 -0000 --_000_DC7880973D477648AC15A3BA66253F6829329B41szxeml523mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I was interested in listening to Mark's presentation today on the auto-transition-selection on a CER. In fact, I always preferred to code my router behavior with maximum capability of automation whenever possible. But in this case, I'm not sure whether it is practical to do so on a CER on its WAN link. First of all, the CER that I'd purchase would need to support multiple traffic forwarding behavior including more than one of native IPv4, native IPv6, 6rd, DS-Lite, etc., and further, when I decide to subscribe the right Internet connection at home with AT&T (currently with IPv4, but may be able to pick 6rd, IPv4-IPv6 dual-stack, IPv6 only, etc. at a later time), I will always need to communicate with AT&T customer services to purchase one so my choice is always known to me that can just be configured on my CER, which really needs just do what it is told. At BBF, the IPv6 transition document (WT-242, currently a straw ballot) has a requirement on this and it says: R-7: The RG MUST be configurable to independently enable or disable native IPv4, native IPv6, DS-Lite, and 6rd via manual configuration or via TR-69. I think the configuration method is simple and will do the job just fine. Cheers Dean --_000_DC7880973D477648AC15A3BA66253F6829329B41szxeml523mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I was interested in listening to Mark’s presentation today

on the auto-transition-selection on a CER. In fact, I always

preferred to code my router behavior with maximum=

capability of automation whenever possible.

 

But in this case, I’m not sure whether it is practical to

do so on a CER on its WAN link.

 

First of all, the CER that I’d purchase would need to support

multiple traffic forwarding behavior including more than one

of native IPv4, native IPv6, 6rd, DS-Lite, etc., and further, when<= o:p>

I decide to subscribe the right Internet connection at

home with AT&T (currently with IPv4, but may be able=

to pick 6rd, IPv4-IPv6 dual-stack, IPv6 only, etc. at a later time)= ,

I will always need to communicate with AT&T customer

services to purchase one so my choice is always known to me

that can just be configured on my CER, which really needs just

do what it is told.

 

At BBF, the IPv6 transition document (WT-242, currently<= /span>

a straw ballot) has a requirement on this and it says:

 

R-7:

The RG MUST be configurable to independently

enable or disable native IPv4, native IPv6, DS-Lite,

and 6rd via manual configuration or via TR-69.

 

I think the configuration method is simple and will do

the job just fine.

 

Cheers

Dean

 

--_000_DC7880973D477648AC15A3BA66253F6829329B41szxeml523mbschi_-- From fgont@si6networks.com Fri Mar 30 04:10:29 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31ED321F878E for ; Fri, 30 Mar 2012 04:10:29 -0700 (PDT) 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 z5HuT8xGLCZg for ; Fri, 30 Mar 2012 04:10:28 -0700 (PDT) Received: from srv01.bbserve.nl (unknown [IPv6:2a02:27f8:1025:18::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9463821F8786 for ; Fri, 30 Mar 2012 04:10:23 -0700 (PDT) Received: from [2001:df8:0:16:1e65:9dff:febe:7f88] by srv01.bbserve.nl with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SDZid-0001p2-06; Fri, 30 Mar 2012 13:10:11 +0200 Message-ID: <4F75949C.4020303@si6networks.com> Date: Fri, 30 Mar 2012 13:10:20 +0200 From: Fernando Gont Organization: SI6 Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.28) Gecko/20120313 Thunderbird/3.1.20 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <20120308195759.14484.86851.idtracker@ietfa.amsl.com> <4F749D57.7060309@si6networks.com> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: v6ops@ietf.org Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-ra-guard-implementation-02.txt X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 11:10:29 -0000 On 03/30/2012 12:18 AM, Bjoern A. Zeeb wrote: >> Rule 3.1 is to prevent an attacker from performing a DoS against the >> RA-Guard device. >> >> That is, if an attacker includes, say, 200 extension headers, we don't >> want the RA-Guard device to jump through all of them. >> >> Note that an implementation could enforce a limit of e.g. 10, allowing a >> single packet to contain more than one copy of each of all the possible >> extension headers. > > You are still going be the assumption of what sensible thing you might > find there today but not tomorrow. IfJohn Doe comes up with a great > idea that will require him to do a 10k extension header on a 9k MTU, If John Doe comes with such idea, he won't be able to deploy it on the public Internet, since deployed stateless IPv6 firewalls will block such packets. One would also wonder whether John might re-think his idea, since it's usually the payload that is meant to be much larger than the headers, and not the other way around. > And I am also startignt o wonder how big a 3971 packet could possibly > be and if that would ever work... Not sure I'd want to drop those at > all for RAs? No need to wonder: See Appendix C of RFC 3971. And I don't think you want to rely on fragmentation for SEND: if you do, an attacker could employ any fragmentation-based attack to disable SEND. >> If your traffic has the minimum level of sanity, it will pass rule 3.1. >> Then rule 3.3 will check the Source Address and Hop Limit to avoid false >> positives. > > If I am performning the checkes from 1 to 3 I'll never make 3 if I'll > have more than 1 * mtu IPv6 header + extension headers before the ULP > as 3.1 clearly states that I shall drop the packet. Exactly. There's not way to do stateless packet filtering without policing such rather insane packets. > So maybe you'll also have to be more precise how the evaluation of > these rules should happen. Note sure what you mean. Thanks, -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 From fred@cisco.com Fri Mar 30 05:45:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA7021F84C9 for ; Fri, 30 Mar 2012 05:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.235 X-Spam-Level: X-Spam-Status: No, score=-110.235 tagged_above=-999 required=5 tests=[AWL=0.364, 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 bExanBdbsTJk for ; Fri, 30 Mar 2012 05:45:00 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id C8D4821F8690 for ; Fri, 30 Mar 2012 05:45:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=137; q=dns/txt; s=iport; t=1333111500; x=1334321100; h=date:from:message-id:to:subject:cc; bh=SU0zZ5l2f6jrzm8nZB5oLcToNAom7tduFdphFrapvSg=; b=Fe9oi6/p11VmjZrTiVLrynqVi96c+6L3CP6IMUrn+Bd3FH6ZCyXcuI64 lJk/C1n86XeoMECX/bfQX81iXT8U8hpnlXsaBVPbfk2msvHXXsBvlfg4L YKLFlEuBwQXmdOQdEW3kswJZWms8ePyZVuClwxpGFLfxBqPJw6p/MzjgR 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApUHAAaqdU+rRDoG/2dsb2JhbABDp14BkRaBB4IiAWY8LYEKh2YMn3KXNI1sgyQEiFqOGo01gWiDBw X-IronPort-AV: E=Sophos;i="4.75,344,1330905600"; d="scan'208";a="35787347" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 30 Mar 2012 12:45:00 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q2UCj0bp020372; Fri, 30 Mar 2012 12:45:00 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id q2UCj0S18945; Fri, 30 Mar 2012 05:45:00 -0700 (PDT) Date: Fri, 30 Mar 2012 05:45:00 -0700 (PDT) From: Message-Id: <201203301245.q2UCj0S18945@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-donley-v6ops-ce-router-design@tools.ietf.org Subject: [v6ops] new draft: draft-donley-v6ops-ce-router-design X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 12:45:02 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-donley-v6ops-ce-router-design. Please take a look at it and comment. From wesley.george@twcable.com Fri Mar 30 16:15:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F6021F8691; Fri, 30 Mar 2012 16:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.259 X-Spam-Level: X-Spam-Status: No, score=-0.259 tagged_above=-999 required=5 tests=[AWL=-0.396, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=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 T47BktuRgJ47; Fri, 30 Mar 2012 16:15:01 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id 766B221F8688; Fri, 30 Mar 2012 16:15:01 -0700 (PDT) X-SENDER-IP: 10.136.163.11 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,346,1330923600"; d="scan'208";a="345186175" Received: from unknown (HELO PRVPEXHUB02.corp.twcable.com) ([10.136.163.11]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 30 Mar 2012 19:15:00 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.27]) by PRVPEXHUB02.corp.twcable.com ([10.136.163.11]) with mapi; Fri, 30 Mar 2012 19:15:00 -0400 From: "George, Wes" To: "grow@ietf.org" , "v6ops@ietf.org" Date: Fri, 30 Mar 2012 19:14:58 -0400 Thread-Topic: draft-behringer-lla-only and draft-ietf-grow-private-ip-sp-cores Thread-Index: Ac0M1PTc8z4ZGA26S5W5umLx5IqzdwB6fdhw Message-ID: References: <20120328112128.19122.59432.idtracker@ietfa.amsl.com> In-Reply-To: <20120328112128.19122.59432.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-behringer-lla-only@tools.ietf.org" , Anthony Kirkham Subject: [v6ops] draft-behringer-lla-only and draft-ietf-grow-private-ip-sp-cores X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 23:15:03 -0000 Cross-posting to both lists again because I was unable to attend the v6ops = session where draft-behringer was discussed, draft-ietf-grow-private-ip-sp-= cores is likely nearing WGLC, and I believe that the issue I raised needs t= o be addressed before either proceeds. I defer to the chairs of both groups= to determine how to manage this across the two groups. After reviewing both draft-grow-private-ip-sp-cores (Kirkham) and draft-beh= ringer-lla-only again, I am even more convinced that they either need to be= merged, or that draft-behringer needs to be abandoned altogether as a bad = idea. Draft-grow-private-ip-sp-cores is quite a lot more complete in its di= scussion of the considerations around private IP usage, but focuses on IPv4= , meaning that it *is* incomplete for lack of discussion of IPv6, which is = a reality in most SP cores today. Nearly all of the same considerations app= ly for IPv4 and IPv6 in this case, so there are probably a limited number o= f changes that would be necessary to cover IPv6 in the Kirkham document. I think that we need to come to some consensus on the recommended behavior = on both cases. If the recommendation is different for one versus the other,= we need to have a unified and clear articulation as to why this is the cas= e. It may be that the consensus is to not recommend a behavior at all, and = simply expand the format of Kirkham's document to cover any IPv6-specific i= tems, since it discusses pros and cons evenly (as an informational doc) rat= her than recommending anything as a BCP. My vote is to do this, as I am unc= onvinced that use of LLA represents BCP today, nor should it. I outline som= e reasons below, but that's probably not as critical if others agree that t= his is the proper method to proceed with these documents. If draft-behringer is left as a separate document, here are some specific c= omments: The advantages proposed in draft-behringer are IMO not enough to justify re= commending use of LLA. - Smaller routing tables can be achieved through other methods such as sett= ing the interfaces into passive mode in the IGP (so that they are not redis= tributed into the IGP) and/or not redistributing connected routes. Further,= as SPs make great use of interface bundling (LAG), the number of interface= s with IP addresses is dramatically reduced, making the need to pull the po= int to point interfaces out of the routing table significantly lower. - Reduced attack surface - draft-ietf-grow-private-ip-sp-cores sections 10 = and 11 discuss this in great detail, and come to the conclusion that it is = of limited benefit, and that alternatives exist to protect the infrastructu= re. - lower configuration complexity - while this is true, it is replaced by ad= ditional complexity in troubleshooting. In the case of traces and pings loc= ally on the box, it adds the additional step of requiring the operator to u= se extended ping and trace commands to specify the exit interface in order = to make the ping work (vs simply issuing "ping [ip address]"), and makes it= nearly impossible to derive the address of the remote interface without de= termining the remote side router through some other means and logging into = the router to look. (vs practice today of using an IP in the same subnet, u= sually 1 digit up or down that can be guessed to save time). - less address space: The other draft mentions this as well, in the context= of IPv4 where it might make a difference, but this simply is not much of a= concern with IPv6. An entire network could be numbered many times over out= of one /64. -simpler DNS : Most ISPs operating at the scale where this makes any differ= ence at all have tools to build the DNS forward and reverse entries for the= ir infrastructure automatically based on the router name and interface name= extracted from their inventory tools. It's a few bits of scripting, so it'= s not like having less interfaces in DNS results in any net reduction in wo= rk or increase in the possibility of mistakes. - Draft-ietf-grow-private-ip-sp-cores rightly notes that the proposed solut= ion to broken pings/traces/PMTUD from draft-behringer (RFC 5837) has little= or no implementation. This makes it a hard sell as any sort of recommended= solution unless the benefits are much more significant than what is curren= tly discussed in draft-behringer. This has to be a large enough benefit to = justify pushing hard on router vendors to implement the feature and SPs to = certify and deploy the code, and frankly there are many more important feat= ures to consider. Thanks, Wes George > -----Original Message----- > From: grow-bounces@ietf.org [mailto:grow-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Wednesday, March 28, 2012 7:21 AM > To: i-d-announce@ietf.org > Cc: grow@ietf.org > Subject: [GROW] I-D Action: draft-ietf-grow-private-ip-sp-cores-00.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Global Routing Operations > Working Group of the IETF. > > Title : Issues with Private IP Addressing in the Internet > Author(s) : Anthony Kirkham > Filename : draft-ietf-grow-private-ip-sp-cores-00.txt > Pages : 15 > Date : 2012-03-28 > > The purpose of this document is to provide a discussion of the > potential problems of using private, RFC1918, or non-globally- > routable addressing within the core of an SP network. The discussion > focuses on link addresses and to a small extent loopback addresses. > While many of the issues are well recognised within the ISP > community, there appears to be no document that collectively > describes the issues. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-grow-private-ip-sp-cores-0= 0.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-grow-private-ip-sp-cores-00= .txt > > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From ietfc@btconnect.com Sat Mar 31 04:27:49 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E6221F86B7; Sat, 31 Mar 2012 04:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, J_CHICKENPOX_13=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 WD+qrr16GYAC; Sat, 31 Mar 2012 04:27:49 -0700 (PDT) Received: from mail.btconnect.com (c2beaomr07.btconnect.com [213.123.26.185]) by ietfa.amsl.com (Postfix) with ESMTP id 076E521F86A8; Sat, 31 Mar 2012 04:27:45 -0700 (PDT) Received: from host86-162-135-195.range86-162.btcentralplus.com (HELO pc6) ([86.162.135.195]) by c2beaomr07.btconnect.com with SMTP id GWY58498; Sat, 31 Mar 2012 12:27:41 +0100 (BST) Message-ID: <006501cd0f28$bb177e80$4001a8c0@gateway.2wire.net> From: "t.petch" To: "George, Wes" , , References: <20120328112128.19122.59432.idtracker@ietfa.amsl.com> Date: Sat, 31 Mar 2012 12:26:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4F76EA2D.0032, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2012.3.31.103620:17:7.944, ip=86.162.135.195, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __MIME_VERSION, __CT, CT_TP_8859_1, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __CP_URI_IN_BODY, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, HTML_00_01, HTML_00_10, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP X-Junkmail-Status: score=10/50, host=c2beaomr07.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020A.4F76EA2E.0024,ss=1,re=0.000,fgs=0, ip=0.0.0.0, so=2011-07-25 19:15:43, dmn=2011-05-27 18:58:46, mode=multiengine X-Junkmail-IWF: false Subject: Re: [v6ops] [GROW] draft-behringer-lla-only anddraft-ietf-grow-private-ip-sp-cores X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 11:27:50 -0000 ----- Original Message ----- From: "George, Wes" To: ; Cc: Sent: Saturday, March 31, 2012 1:14 AM > Cross-posting to both lists again because I was unable to attend the v6ops session where draft-behringer was discussed, draft-ietf-grow-private-ip-sp-cores is likely nearing WGLC, and I believe that the issue I raised needs to be addressed before either proceeds. I defer to the chairs of both groups to determine how to manage this across the two groups. > > After reviewing both draft-grow-private-ip-sp-cores (Kirkham) and draft-behringer-lla-only again, I am even more convinced that they either need to be merged, or that draft-behringer needs to be abandoned altogether as a bad idea. Draft-grow-private-ip-sp-cores is quite a lot more complete in its discussion of the considerations around private IP usage, but focuses on IPv4, meaning that it *is* incomplete for lack of discussion of IPv6, which is a reality in most SP cores today. Nearly all of the same considerations apply for IPv4 and IPv6 in this case, so there are probably a limited number of changes that would be necessary to cover IPv6 in the Kirkham document. Disagree. As you say, the grow draft is more or less complete, more or less ready for WGLC. And it has taken the IETF two years to get to this state. IPv6 is different. We probably know little as yet as to how it works or how it should. Adding IPv6 would put this work back a year or two, and given that GROW is not the most lively of growps, it may never happen. Get the grow draft out as an RFC while it is still of value to its audience. Then contemplate a -bis with IPv6 if there is sufficient enthusiasm in a WG to do so. Tom Petch > I think that we need to come to some consensus on the recommended behavior on both cases. If the recommendation is different for one versus the other, we need to have a unified and clear articulation as to why this is the case. It may be that the consensus is to not recommend a behavior at all, and simply expand the format of Kirkham's document to cover any IPv6-specific items, since it discusses pros and cons evenly (as an informational doc) rather than recommending anything as a BCP. My vote is to do this, as I am unconvinced that use of LLA represents BCP today, nor should it. I outline some reasons below, but that's probably not as critical if others agree that this is the proper method to proceed with these documents. > > > > If draft-behringer is left as a separate document, here are some specific comments: > The advantages proposed in draft-behringer are IMO not enough to justify recommending use of LLA. > - Smaller routing tables can be achieved through other methods such as setting the interfaces into passive mode in the IGP (so that they are not redistributed into the IGP) and/or not redistributing connected routes. Further, as SPs make great use of interface bundling (LAG), the number of interfaces with IP addresses is dramatically reduced, making the need to pull the point to point interfaces out of the routing table significantly lower. > - Reduced attack surface - draft-ietf-grow-private-ip-sp-cores sections 10 and 11 discuss this in great detail, and come to the conclusion that it is of limited benefit, and that alternatives exist to protect the infrastructure. > - lower configuration complexity - while this is true, it is replaced by additional complexity in troubleshooting. In the case of traces and pings locally on the box, it adds the additional step of requiring the operator to use extended ping and trace commands to specify the exit interface in order to make the ping work (vs simply issuing "ping [ip address]"), and makes it nearly impossible to derive the address of the remote interface without determining the remote side router through some other means and logging into the router to look. (vs practice today of using an IP in the same subnet, usually 1 digit up or down that can be guessed to save time). > - less address space: The other draft mentions this as well, in the context of IPv4 where it might make a difference, but this simply is not much of a concern with IPv6. An entire network could be numbered many times over out of one /64. > -simpler DNS : Most ISPs operating at the scale where this makes any difference at all have tools to build the DNS forward and reverse entries for their infrastructure automatically based on the router name and interface name extracted from their inventory tools. It's a few bits of scripting, so it's not like having less interfaces in DNS results in any net reduction in work or increase in the possibility of mistakes. > > - Draft-ietf-grow-private-ip-sp-cores rightly notes that the proposed solution to broken pings/traces/PMTUD from draft-behringer (RFC 5837) has little or no implementation. This makes it a hard sell as any sort of recommended solution unless the benefits are much more significant than what is currently discussed in draft-behringer. This has to be a large enough benefit to justify pushing hard on router vendors to implement the feature and SPs to certify and deploy the code, and frankly there are many more important features to consider. > > Thanks, > > Wes George > > > > -----Original Message----- > > From: grow-bounces@ietf.org [mailto:grow-bounces@ietf.org] On Behalf Of > > internet-drafts@ietf.org > > Sent: Wednesday, March 28, 2012 7:21 AM > > To: i-d-announce@ietf.org > > Cc: grow@ietf.org > > Subject: [GROW] I-D Action: draft-ietf-grow-private-ip-sp-cores-00.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. This draft is a work item of the Global Routing Operations > > Working Group of the IETF. > > > > Title : Issues with Private IP Addressing in the Internet > > Author(s) : Anthony Kirkham > > Filename : draft-ietf-grow-private-ip-sp-cores-00.txt > > Pages : 15 > > Date : 2012-03-28 > > > > The purpose of this document is to provide a discussion of the > > potential problems of using private, RFC1918, or non-globally- > > routable addressing within the core of an SP network. The discussion > > focuses on link addresses and to a small extent loopback addresses. > > While many of the issues are well recognised within the ISP > > community, there appears to be no document that collectively > > describes the issues. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-grow-private-ip-sp-cores-00.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > This Internet-Draft can be retrieved at: > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-grow-private-ip-sp-cores-00.txt > > > > _______________________________________________ > > GROW mailing list > > GROW@ietf.org > > https://www.ietf.org/mailman/listinfo/grow > > This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > > From fred@cisco.com Sat Mar 31 05:45:02 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6039521F85F6 for ; Sat, 31 Mar 2012 05:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.266 X-Spam-Level: X-Spam-Status: No, score=-110.266 tagged_above=-999 required=5 tests=[AWL=0.333, 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 vzOiiAKfkxl5 for ; Sat, 31 Mar 2012 05:45:01 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id ADA9421F8607 for ; Sat, 31 Mar 2012 05:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fred@cisco.com; l=124; q=dns/txt; s=iport; t=1333197901; x=1334407501; h=date:from:message-id:to:subject:cc; bh=qXQJnf9eg8Avl/eBwIPc9izsuX0nhCmLyU6YDpkDXwU=; b=LosjBLU7evASIkC9KC0zwOCZ/GRVFbWxrFmVhiuhvaD709lH6IaFHyuL NY4lr7NCNvQKpcDy5alEl4g1Ev4KZpD7QlDrnOwIV5la6GEWAuahp9LKl TJLiYmuYs1q2R9JxZuQHgBSQt7KvOWbT6S3su1gJvXr9L8rAe/OMLFHXQ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMIAMb7dk+rRDoI/2dsb2JhbABFp2YBkReBB4IiAWY8LYEKh2YMmwyefY14gkFjBIhYjhqNNoFogwc X-IronPort-AV: E=Sophos;i="4.75,348,1330905600"; d="scan'208";a="35922916" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-3.cisco.com with ESMTP; 31 Mar 2012 12:45:01 +0000 Received: from ftpeng-update.cisco.com (ftpeng-update.cisco.com [171.69.17.32]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q2VCj1pJ021116; Sat, 31 Mar 2012 12:45:01 GMT Received: (fred@localhost) by ftpeng-update.cisco.com (8.11.2/CISCO.WS.1.2) id q2VCj1E17045; Sat, 31 Mar 2012 05:45:01 -0700 (PDT) Date: Sat, 31 Mar 2012 05:45:01 -0700 (PDT) From: Message-Id: <201203311245.q2VCj1E17045@ftpeng-update.cisco.com> To: v6ops@ietf.org Cc: draft-yang-v6ops-fast6@tools.ietf.org Subject: [v6ops] new draft: draft-yang-v6ops-fast6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 12:45:02 -0000 A new draft has been posted, at http://tools.ietf.org/html/draft-yang-v6ops-fast6. Please take a look at it and comment. From wdec.ietf@gmail.com Sat Mar 31 08:12:14 2012 Return-Path: X-Original-To: v6ops@ietfa.amsl.com Delivered-To: v6ops@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D5521F8564 for ; Sat, 31 Mar 2012 08:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.944 X-Spam-Level: X-Spam-Status: No, score=-2.944 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, 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 dEH6gj8YuW06 for ; Sat, 31 Mar 2012 08:12:14 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id F0C2721F84EF for ; Sat, 31 Mar 2012 08:12:13 -0700 (PDT) Received: by qcsq13 with SMTP id q13so1060553qcs.31 for ; Sat, 31 Mar 2012 08:12:13 -0700 (PDT) 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=U8H0ieDFfcS8g7KY+/Tj/eyI4L+/olsjAdEJn8P+HK8=; b=cE6yIqxe8LYJCfhh64rDUhTp60UNX+R/qKYr1qYKat72vbH1PIMwFsJRS6vS3aMLW2 BZiBRmHh2q7W9fmGaklL7XqTyGBdmsrlDefCI+DX/BXGAh1IT1t6VP04PKnESjKmInVp gRgud5XdGKTgEOnw/HwVlbqBKecZFiwN0t1v0vUvTpBWf/724YY7C56FAUts759GPUpC PTI4uZOFOrlET+wyDcc/lh49h4FDxg63Xf5MX7VTUyfdKQA/HjFf2d9oI49qtAoC6FcM qQL5iLs/7au5XnbK4ggTwKeXidiarYDMvEu9xFKFP/ixsosxkMrPV4rQP6MNedVJUP+o 3/ug== MIME-Version: 1.0 Received: by 10.224.8.208 with SMTP id i16mr3402017qai.51.1333206733499; Sat, 31 Mar 2012 08:12:13 -0700 (PDT) Received: by 10.229.218.4 with HTTP; Sat, 31 Mar 2012 08:12:13 -0700 (PDT) In-Reply-To: <201203311245.q2VCj1E17045@ftpeng-update.cisco.com> References: <201203311245.q2VCj1E17045@ftpeng-update.cisco.com> Date: Sat, 31 Mar 2012 17:12:13 +0200 Message-ID: From: Wojciech Dec To: draft-yang-v6ops-fast6@tools.ietf.org Content-Type: multipart/alternative; boundary=bcaec51b15f5c32c2f04bc8b61c4 Cc: v6ops@ietf.org Subject: Re: [v6ops] new draft: draft-yang-v6ops-fast6 X-BeenThere: v6ops@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: v6ops discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 15:12:14 -0000 --bcaec51b15f5c32c2f04bc8b61c4 Content-Type: text/plain; charset=ISO-8859-1 Hi, not sure if this is intentional, but the draft seems to describes an IPv4inIPv4 tunneling + CGN architecture. For closer applicability to v6 ops it would be a good idea to show tunneling over IPv6, as well as to highlight perhaps what the difference of fast6 to http://tools.ietf.org/html/draft-ietf-softwire-gateway-init-ds-lite is (given that it appears to describe a similar architecture)? Regards, Wojciech. On 31 March 2012 14:45, wrote: > > A new draft has been posted, at > http://tools.ietf.org/html/draft-yang-v6ops-fast6. Please take a look at > it and comment. > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops > --bcaec51b15f5c32c2f04bc8b61c4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

not sure if this is intentional, but the draft seems to describe= s an IPv4inIPv4 tunneling + CGN architecture. For closer applicability to v= 6 ops it would be a good idea to show tunneling over IPv6, as well as to hi= ghlight perhaps what the difference of fast6 to http://tools.ietf.org/= html/draft-ietf-softwire-gateway-init-ds-lite is (given that it appears= to describe a similar architecture)?

Regards,
Wojciech.

On 31 March 201= 2 14:45, <fred@cisc= o.com> wrote:

A new draft has been posted, at http://tools.ietf.org/html/draft-yang-= v6ops-fast6. Please take a look at it and comment.
_______________________________________________
v6ops mailing list
v6ops@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/v6ops

--bcaec51b15f5c32c2f04bc8b61c4--