Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - textual representation of prefixes - DOI
Alexandre Petrescu <alexandre.petrescu@gmail.com> Sat, 04 March 2017 12:33 UTC
Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED351294F0 for <ipv6@ietfa.amsl.com>; Sat, 4 Mar 2017 04:33:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.353
X-Spam-Level:
X-Spam-Status: No, score=-5.353 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_SOFTFAIL=0.665] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHIwByY7la-Y for <ipv6@ietfa.amsl.com>; Sat, 4 Mar 2017 04:33:06 -0800 (PST)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCF0F1294A1 for <ipv6@ietf.org>; Sat, 4 Mar 2017 04:33:05 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.15.2/8.15.2/CEAnet-Internet-out-2.4) with ESMTP id v24CX2oZ003496; Sat, 4 Mar 2017 13:33:02 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A1F1E203EA6; Sat, 4 Mar 2017 13:33:02 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 92285201037; Sat, 4 Mar 2017 13:33:02 +0100 (CET)
Received: from [132.166.84.69] ([132.166.84.69]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v24CX1bQ004508; Sat, 4 Mar 2017 13:33:01 +0100
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - textual representation of prefixes - DOI
To: Fred Baker <fredbaker.ietf@gmail.com>
References: <20170223134026.GI5069@gir.theapt.org> <CAO42Z2z7v4gDk91b6Of-1sczV88m3B9kzn0MeJU_VBJ416k6Ww@mail.gmail.com> <ae35b45a-0398-840f-fc0d-1f64dd2fcc58@gmail.com> <37851ee3-03be-8bee-6190-f4d28df86305@gmail.com> <alpine.DEB.2.02.1703012051590.30226@uplift.swm.pp.se> <b5784622-c24e-a531-4e68-249b03701941@gmail.com> <CAAedzxrSTFe0GgYuvtXPNE=R_ZCXotxL7HbKdj5A4-869rncmw@mail.gmail.com> <ba025be6-709d-87b4-f388-d6f143408277@gmail.com> <alpine.DEB.2.02.1703021029010.30226@uplift.swm.pp.se> <4e17a9f4-6daf-787f-0321-3327fe601d70@gmail.com> <bead3cd8-f7f9-37b3-66f9-e76ae94056d1@baanhofman.nl> <63d98caf-ab70-088f-ff6b-ad27a11619e0@gmail.com> <CAJE_bqcOLSK061p_biSD3GK1y464Ld=8Zp3-hAuJqQ2R2t3JRw@mail.gmail.com> <68803ac3-97f4-838c-ffd2-a294d7fb6d0d@gmail.com> <CAJE_bqc7cFrhCaiGMGeSUf1zMsXpcoDUVvYQ13L-Soe4Rwf6RA@mail.gmail.com> <a630f8b8-e6ed-885a-a909-6c75dfd79892@gmail.com> <49C3F649-FEC9-430E-B716-D5608E00D385@gmail.com> <23d0ed53-918f-dec0-1914-57f2e31bccc9@gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <1693b650-f79b-e569-be94-2bcb8d9af522@gmail.com>
Date: Sat, 04 Mar 2017 13:33:05 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <23d0ed53-918f-dec0-1914-57f2e31bccc9@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/MR0aHmKja5epv52CpLPFjh2lJog>
Cc: IPv6 IPv6 List <ipv6@ietf.org>, 神明達哉 <jinmei@wide.ad.jp>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 04 Mar 2017 12:33:08 -0000
This proposal has now a DOI: 10.13140/RG.2.2.30828.36484 Alex Le 04/03/2017 à 13:09, Alexandre Petrescu a écrit : > Fred, > > I think the problem I have - agreed, on my side - is that "fe80::/10" is > sometimes read as a link-local address, other times as a prefix > configured on a computer, other times as just the first 10bits of an LL > address. > > The difficulty is in that people say "prefix" meaning the first bits > from left to right, and other times "prefix" meaning what is configured > on a computer. They are different. > > This "fe80::/10" seems to be the first ten bits of a link-local address; > "fe80::/10" is not an address and not a prefix to be configured on a > computer, even though whenever we write "P::/X" we understand it as a > prefix configured on a computer. > > The prefix configured on a computer is "fe80::/64" and the LL address is > "fe80::1". > > I had the same problem with textual representation of site-local "fec0", > with the default route "2001::/3", with the two ULAs "fc00::/7" > "fd00::/7" and recently with the 16 prefixes denoted by > 2001:db8:ffff:cafe::/60 despite the mandatory presence of a single > character (the 'e' in cafe could have been 0, 1, 2... f). > > I propose to introduce new ASCII characters in the textual > representation of IPv6 addresses: > > fe80:://10 means the first 10 bits of an address, it does not mean it is > the configured prefix of an address in the rt table, nor is it a prefix > used for on-link determination. > > fg00:://7 means the first 7 bits of a ULA, also represented as > "fc00::/7" or as "fd00::/7". > > 2001:db8:ffff:caf*::/60 means one or more configured prefixes from 0 to > f at the place of *. > > I will try to use these characters in conversation to see what it gives. > > Alex > > > Le 03/03/2017 à 23:51, Fred Baker a écrit : >> Read the fine RFC, Alexandre. We used to have something called a >> site-local address, which was fe80::/10 with 54 bits that were not >> all zero and a 64 bit IID, and the link-local address was fe80::/10 >> with 54 bits of zero. We deprecated the site-local address, but >> link-local is still fe80::/10 followed by 54 bits that are all zero. >> >>> On Mar 3, 2017, at 2:40 PM, Alexandre Petrescu >>> <alexandre.petrescu@gmail.com> wrote: >>> >>> >>> >>> Le 03/03/2017 à 23:02, 神明達哉 a écrit : >>>> At Fri, 3 Mar 2017 22:09:47 +0100, Alexandre Petrescu >>>> <alexandre.petrescu@gmail.com> wrote: >>>> >>>>>> Both, and I believe at least most implementers have had no >>>>>> difficulty in interpreting the spec that way. >>>>> >>>>> If it is both, then it requires that the prefix used for >>>>> address autoconfiguration of LL addresses to be 64bit length. >>>>> >>>>> But the LL prefix is fe80::/10. >>>>> >>>>> "fe80::/10" means it is a prefix. It does not mean it is "a >>>>> mask for implementation in BSD and other OSs C macros to >>>>> recognise the LL address". >>>>> >>>>> So, what goes between /10 and /64? Why? >>>> >>>> For (auto)configuring a link-local address? If so, it's all-0 >>>> bits, as defined in Section 2.5.6 of RFC4291: >>>> >>>> | 10 | | bits | 54 bits | 64 >>>> bits | >>>> +----------+-------------------------+----------------------------+ >>>> >>>> >>>> > |1111111010| 0 | interface ID | >>>> +----------+-------------------------+----------------------------+ >>> >>> >>>> >>>> > Is that figure picturing a fe80::/10 or a fe80::/64? >>> >>> Is the prefix extended from fe80::/10 to fe80::/64 with 0s? Or is >>> the IID len extended from 64 to to become an IID len==108? >>> >>> If we stopped saying fe80::/10 then it would be clearer. >>> >>> But one seems to be forced to continue talking about fe80::/10. >>> >>> Otherwise we would never write text reading "fe80::/10". >>> >>>>>> - uses the 64-bit IID (as specified in RFC2464) - uses the >>>>>> fe80::/64 prefix (as defined in RFC4291 Section 2.5.6) >>>>> >>>>> And ignores the same document's fe80::/10. And some >>>>> implementer does not appreciate that. >>>> >>>> I'm not sure what you mean by this here, but out of curiosity, >>>> who is that implementer and what does it actually do by not >>>> appreciating that? >>> >>> Let us say that I talked to many IPv6 stack implementers and I >>> continue to. So to answer this question there is not one person >>> in particular that I could name, but rather the name of a few >>> persons, and a sort of average I make from my discussions. >>> >>> Moreover, whenever I invoke such 3rd person, it is the very >>> optimistic view. I avoid saying all the bad things that I heard, >>> and I keep the good things. >>> >>>> Auto-configuring a link-local address that does not match >>>> fe80::/64? >>> >>> I mean this: is one implementer mandated to bzero() the bits from >>> /10 to /64? Or not? Nobody is telling her so. >>> >>> If one writes code that generate an LL address by using a /64 >>> mask, and then tries to make sure by recognising it by using a /10 >>> macro, there is obviously place for false negatives or false >>> positives. >>> >>> If the 4291 spec wrote everywhere that the prefix is "fe80::/64" >>> (and never write "fe80::/10"), then the implementer would be >>> helped a lot. She would generate and reognise by always using a >>> 64bit mask. >>> >>> But that would be wrong to put in an IPv6 Addressing Archi, >>> because 64 is too much of a limit, anyways. >>> >>> Additionally, when we talk about the first 3 bits 000, we dont >>> write "::/3" because "::/3" is a prefix and there is a risk of >>> confusion. >>> >>> You may remember the discussion about how to denote a default >>> route. >>> >>>>>> - combine these to configure a link-local address >>>>>> fe80::<64-bit IID> as specified in Section 5.3 of RFC4862 >>>>> >>>>> And who tells the implementer what to put between /10 and /64? >>>> >>>>> Should that be 0s? 1s? An arbitrary random mix of 0s and 1s? >>>> >>>> 0s, as described in RFC4291 Section 2.5.6. >>> >>> Are these 0s part of the plen or part of the IID? >>> >>>>>> To me there's nothing confusing or unclear here, and I >>>>>> suspect the Linux implementation essentially does the same >>>>>> thing. >>>>> >>>>> I think you dont want to see the potential confusion because >>>>> you do not ask yourself what to put between /10 and /64. I >>>>> think you silently assume that should be 0s. >>>> >>>> If "what to put between /10 and /64" is for (auto)configuring >>>> link-local addresses, yes, I assume it's 0s. But not "silently" >>>> - it's based on Section 2.5.6 of RFC4291. >>> >>> That section 2.5.6 does not say whether the 0s are part of the >>> plen or part of the IID. >>> >>> It is your reading, with an inclined view to make everything work, >>> that makes it read so. >>> >>> But read it with an inquiring view: is the 0 part of the IID or of >>> the plen? The section does not answer. >>> >>>> BTW, I do not necessarily disagree that there may be "some >>>> confusion" if one sees this: >>>> >>>> Link-Local unicast 1111111010 FE80::/10 2.5.6 >>>> (Section 2.4 of RFC4291) >>>> >>>> and this: >>>> >>>> | 10 | | bits | 54 bits | 64 >>>> bits | >>>> +----------+-------------------------+----------------------------+ >>>> >>>> >>>> > |1111111010| 0 | interface ID | >>>> +----------+-------------------------+----------------------------+ >>>> >>>> >>>> > (Section 2.5.6 of RFC4291) >>>> >>>> like, wondering "what if the intermediate 54 bits are non-0? >>>> should it be called a link-local address?". >>> >>> I agree with the doubt. >>> >>>> But, at least in terms of auto-generating link-local addresses, >>>> the specs are clear enough to me that these bits should be set >>>> to 0. That's why I always try to clarify the context is to >>>> auto-generate a link-local address in this conversation. >>> >>> Yes, it's clear it should be 0. But it's not clear whether the 0s >>> are part of the plen or part of the IID. >>> >>>> If you want to further clear any possible confusion between the >>>> intermediate 54 bits, I wouldn't discourage you to write a >>>> "mystery of the intermediate 54 bits for fe80::/10" draft:-) >>> >>> I agree :-) When I hear this I think I need to stop talking >>> because I cant write so many drafts as I write emails :-) >>> >>> But some of these things are indeed doubts there for a long time. >>>> >>>>>>> It does not forbid that that 64bit prefix be formed by >>>>>>> self-appending a 0 to a /63 from the RA, or other >>>>>>> mechanism. >>>>>> >>>>>> It's not the job of RFC2464. RFC4862 imposes the restriction >>>>>> through its Section 5.5.3 bullet d): >>>>> >>>>> Well then, it should. >>>>> >>>>> BEcause currently RFC2464 says "An IPv6 address prefix used for >>>>> stateless autoconfiguration [ACONF] of an Ethernet interface >>>>> must have a length of 64 bits". >>>>> >>>>> If we go by your recommendation above, then it means RFC2464 >>>>> must not say that. >>>> >>>> I guess we're just not on the same page...trying to rephrase my >>>> point, it doesn't matter that RFC2464 "does not forbid that that >>>> 64bit prefix be formed by self-appending a 0 to a /63 from the >>>> RA", since RFC4862 forbids it anyway (by the "sum must be 128" >>>> requirement). >>> >>> I dont understand you. >>> >>> I want to say this: RFC2464 does require the prefix len to be 64. >>> >>> >>>>>> I guess that "rt entry for that /63 prefix" is to treat the >>>>>> /63 prefix as on-link (assuming the corresponding PIO has L >>>>>> bit on). >>>>> >>>>> YEs. >>>>> >>>>>> If so, that's the correct behavior per RFC4861 (not 4862). >>>>> >>>>> So RFC4862 should not require the Host to ignore a received >>>>> non 128 plen+IID, because RFC4861 accepts it. >>>> >>>> Here I actually see conflating. RFC4862 only says the host MUST >>>> ignore such prefix *for SLAAC*. >>> >>> That emphasis is yours, it's not in the document. The document >>> says it must ignore it. >>> >>>> It doesn't say, for example, it should ignore the entire RA or >>>> even for that particular PIO for other purposes than SLAAC. >>> >>> It says it must ignore the PIO. IT does not say for what to >>> ignore it. >>> >>>> But I admit this point may be subtle and can easily be >>>> misunderstood. RFC4862 tried to clarify that subtlety a bit in >>>> the following paragraph of that section (that was actually >>>> written by me): >>>> >>>> It is the responsibility of the system administrator to ensure >>>> that the lengths of prefixes contained in Router Advertisements >>>> are consistent with the length of interface identifiers for that >>>> link type. It should be noted, however, that this does not mean >>>> the advertised prefix length is meaningless. In fact, the >>>> advertised length has non-trivial meaning for on-link >>>> determination in [RFC4861] where the sum of the prefix length >>>> and the interface identifier length may not be equal to 128. >>>> Thus, it should be safe to validate the advertised prefix length >>>> here, in order to detect and avoid a configuration error >>>> specifying an invalid prefix length in the context of address >>>> autoconfiguration. >>> >>> It reads reasonable. But the other paragraph requiring to ignore >>> the PIO which is non 64 is still there. These two paragraphs are >>> contradictory. >>> >>> One requires consistency, the other requires 64. >>> >>> We are going to write the same for IPv6 Addressing Architecture? >>> A paragraph requiring 64 and another requiring variable length? >>> >>>> but this conversation seems to suggest it's still not clear >>>> enough. >>> >>> BEcause when writing RFCs it is not by adding paragraphs that >>> things get clearer. Clarification paragraphs may be good, but >>> often removing some paragraphs can also improve clarity. >>> >>> There are readers out there, most often the programmers. They >>> dont care about the earlier discussion involving pride and other >>> feelings. They want consistency - things that can be easily >>> implemented. >>> >>>>> As such, either rfc4862 or rfc4861 should be modified to make >>>>> it work together. >>>> >>>> 4861 and 4862 already work together. But, we could make it even >>>> clearer that prefix length validation for on-link determination >>>> (actually there's no restriction for this) and prefix length >>>> validation for SLAAC are independent, if and when we want to >>>> update these RFCs. >>>> >>>>> Maybe rfc4862 should not require the Host to refuse a received >>>>> plen+IID not making for 128. >>>> >>>> No, it should still require that, as there's currently no defect >>>> in the spec even if it may still not be crystal clear for some. >>>> However, you have the right to propose loosening the >>>> requirement, so if you think that change is necessary, please >>>> feel free to write a draft. >>> >>> Ah this invitation. The title reads great! "Mistery of...". >>> Thanks, but no, not at this time :-) >>> >>>>>> It's also correct to ignore that prefix for SLAAC per RFC4862 >>>>>> (not 4861). >>>>> >>>>> If some RFC requires the Host to ignore the PIO and some other >>>>> RFC requires the Host to interpret it, and both RFCs are >>>>> mandatory to implement, under the same conditions, isn't there >>>>> a conflict? >>>> >>>> No, there's no conflict, once one understands the two types >>>> validations are independent: >>>> >>>> - RFC4861 does not impose any restriction on the prefix length >>>> in PIO for on-link determination purpose (and therefore the host >>>> is expected to accept any length of prefix for on-link >>>> determination) - RFC4862 requires the host to ignore the PIO of >>>> some particular length for the purpose of SLAAC (and therefore >>>> the host is expected to not use a prefix of "invalid length" to >>>> configure an address) >>>> >>>> Both can coexist. BSDs literally implement it. From your >>>> previous message, I guess so does Linux. I also suspect so do >>>> other major OS implementations such as Windows or Solaris, as >>>> this separation has been in fact one of common test cases in >>>> IPv6 protocol conformance test suites. >>> >>> Ok. >>> >>> Alex >>> >>>> >>>> -- JINMEI, Tatuya >>>> >>> >>> -------------------------------------------------------------------- >>> >>> >>> > IETF IPv6 working group mailing list >>> ipv6@ietf.org Administrative Requests: >>> https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >> >>> >>> >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > --------------------------------------------------------------------
- Objection to draft-ietf-6man-rfc4291bis-07.txt Peter Hessler
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Lorenzo Colitti
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Job Snijders
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Lorenzo Colitti
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Peter Hessler
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Pierre Pfister
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Brian E Carpenter
- RE: Objection to draft-ietf-6man-rfc4291bis-07.txt Manfredi, Albert E
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Mark Smith
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Iván Arce
- RE: Objection to draft-ietf-6man-rfc4291bis-07.txt Manfredi, Albert E
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Job Snijders
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Mark Smith
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Nick Hilliard
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt james woodyatt
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Nick Hilliard
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt james woodyatt
- RE: Objection to draft-ietf-6man-rfc4291bis-07.txt Manfredi, Albert E
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Nick Hilliard
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt james woodyatt
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Brian E Carpenter
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Lorenzo Colitti
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Christopher Morrow
- RE: Objection to draft-ietf-6man-rfc4291bis-07.txt mohamed.boucadair
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Peter Hessler
- RE: Objection to draft-ietf-6man-rfc4291bis-07.txt mohamed.boucadair
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Sander Steffann
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Nick Hilliard
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Nick Hilliard
- RE: Objection to draft-ietf-6man-rfc4291bis-07.txt mohamed.boucadair
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Christopher Morrow
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt james woodyatt
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Christopher Morrow
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Pierre Pfister
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt David Farmer
- RE: Objection to draft-ietf-6man-rfc4291bis-07.txt Manfredi, Albert E
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Christopher Morrow
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Brian E Carpenter
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt David Farmer
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Christopher Morrow
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt David Farmer
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Fernando Gont
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Brian E Carpenter
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt David Farmer
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Brian E Carpenter
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Xing Li
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Xing Li
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Mark Smith
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Brian E Carpenter
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Mark Smith
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Lorenzo Colitti
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Philip Homburg
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt David Farmer
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Lorenzo Colitti
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Brian E Carpenter
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt james woodyatt
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt David Farmer
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Fernando Gont
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Greg Hankins
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Lorenzo Colitti
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Lorenzo Colitti
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Lorenzo Colitti
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt sthaug
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt sthaug
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Lorenzo Colitti
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Lorenzo Colitti
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Nick Hilliard
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Greg Hankins
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt sthaug
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt otroan
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt otroan
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Dan Lüdtke
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt sthaug
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt David Farmer
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt David Farmer
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Lorenzo Colitti
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Lorenzo Colitti
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Iván Arce
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Iván Arce
- Re: Objection to draft-ietf-6man-rfc4291bis-07.tx… Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Brian E Carpenter
- Re: Objection to draft-ietf-6man-rfc4291bis-07.tx… Mikael Abrahamsson
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Mark Smith
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Brian E Carpenter
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Nick Hilliard
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Iván Arce
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Fernando Gont
- Re: Objection to draft-ietf-6man-rfc4291bis-07.tx… Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.tx… Erik Kline
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.tx… Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Fernando Gont
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Fernando Gont
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Lorenzo Colitti
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Lorenzo Colitti
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Lorenzo Colitti
- Re: Objection to draft-ietf-6man-rfc4291bis-07.tx… Mikael Abrahamsson
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Fernando Gont
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Fernando Gont
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Tore Anderson
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Lorenzo Colitti
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Iván Arce
- Re: Objection to draft-ietf-6man-rfc4291bis-07.tx… Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Tore Anderson
- Consensus? (was Re: Objection to draft-ietf-6man-… Wilco Baan Hofman
- Re: Objection to draft-ietf-6man-rfc4291bis-07.tx… Mikael Abrahamsson
- Re: Objection to draft-ietf-6man-rfc4291bis-07.tx… Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.tx… Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.tx… Mikael Abrahamsson
- Re: Objection to draft-ietf-6man-rfc4291bis-07.tx… Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Lorenzo Colitti
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Tore Anderson
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Lorenzo Colitti
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Sander Steffann
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Mikael Abrahamsson
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Mikael Abrahamsson
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt JORDI PALET MARTINEZ
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt JORDI PALET MARTINEZ
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt JORDI PALET MARTINEZ
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Nick Hilliard
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Mark Andrews
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt 神明達哉
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Lorenzo Colitti
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Mikael Abrahamsson
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.tx… Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Job Snijders
- RE: Objection to draft-ietf-6man-rfc4291bis-07.txt mohamed.boucadair
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt otroan
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Ca By
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.tx… 神明達哉
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt 神明達哉
- Re: Objection to draft-ietf-6man-rfc4291bis-07.tx… Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.tx… 神明達哉
- Re: Objection to draft-ietf-6man-rfc4291bis-07.tx… Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.tx… Fred Baker
- Re: Objection to draft-ietf-6man-rfc4291bis-07.tx… Philip Homburg
- Re: Objection to draft-ietf-6man-rfc4291bis-07.tx… Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.tx… Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.tx… Brian E Carpenter
- Re: Objection to draft-ietf-6man-rfc4291bis-07.tx… Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.tx… Christian Huitema
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt 神明達哉
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt 神明達哉
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt 神明達哉
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Simon Hobson
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Simon Hobson
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt otroan
- Re: Objection to draft-ietf-6man-rfc4291bis-07.tx… Alexandre Petrescu
- Re: Objection to draft-ietf-6man-rfc4291bis-07.tx… otroan
- Re: Objection to draft-ietf-6man-rfc4291bis-07.txt Alexandre Petrescu