Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - /63 and /65 RAs on linux
Fred Baker <fredbaker.ietf@gmail.com> Fri, 03 March 2017 22:51 UTC
Return-Path: <fredbaker.ietf@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 9A3691293DB for <ipv6@ietfa.amsl.com>; Fri, 3 Mar 2017 14:51:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 pHwo9MddkyUA for <ipv6@ietfa.amsl.com>; Fri, 3 Mar 2017 14:51:20 -0800 (PST)
Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFBC3124281 for <ipv6@ietf.org>; Fri, 3 Mar 2017 14:51:20 -0800 (PST)
Received: by mail-pg0-x230.google.com with SMTP id s67so48306763pgb.3 for <ipv6@ietf.org>; Fri, 03 Mar 2017 14:51:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PQaMeHQ7M/YkOLCHmIpVwojNooH1dbBjm/6LP8rPJUs=; b=EoNwyhz5lD5ExffSvcv36tZDX0y2nI4YqNgRvRXzC50YYDpn3DIo6ov0QvUHoiD4Zv D1tPMiZ/YHkKSg/u19E/5ILCO70qP41mdWl+bhKBGRXdGxm9lkzdsfseG/Koq7GzJpQJ m+gS6Dcp5sOrShm43JOYy60+Vp9qurmnK4haO5qBig9TfCcKluRdVP3AaHdQOJ55Ygur 5xts9uPWuKasqc1juRno2tf6YNRNjn3p3Z1ky8hbTu9vZqt99+qcUMYY+4B3gTMeyf8h xEqfzXCEOktNTFxF+q0+3dUC2DT5qk8t2lhpA2PyM/7Xug9EEYJY0ftHpfDcVOlH+nGj SDvw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PQaMeHQ7M/YkOLCHmIpVwojNooH1dbBjm/6LP8rPJUs=; b=hT5/odNaEacpSsDsGenPuGNWxrEqUai3U8q49m1i+cfCelaH7QYGhuFulRN446wjXu hKD4Gx8N4a5TO7HIQXlEbqE2rFprsSYkgdPufGiv9HmFCV8MGFYguVcPliETtkjkXT1+ oci9uC+SGPl0+/1ERtlZcm9mfTTl2Bhu+S8aNBYKTT3BHrsiKiiHhTAbD3ZHvGSSaTsg M/LPA4X181d2IVDDTUiKjn97olkhChrs5v3wSXePDEX3z8hZc9fwovWNVbjTP3oPMy3T gIJzJVsc6951Zqx2ghM/uwPjpz32gM31RiuMWAJSHr6aQ2cg0zNovbthg2RXpyLDlGxK 8UOQ==
X-Gm-Message-State: AMke39kWYmIpFz/r3KD75ZGi1wh4wF7wvEE27aMsMZtCfBoveV5nXF4k+af7FNTptqr8jQ==
X-Received: by 10.98.134.142 with SMTP id x136mr6300952pfd.64.1488581480118; Fri, 03 Mar 2017 14:51:20 -0800 (PST)
Received: from [192.168.1.15] (wsip-184-191-158-59.sd.sd.cox.net. [184.191.158.59]) by smtp.gmail.com with ESMTPSA id y187sm25252545pfy.123.2017.03.03.14.51.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 03 Mar 2017 14:51:19 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Objection to draft-ietf-6man-rfc4291bis-07.txt - /63 and /65 RAs on linux
From: Fred Baker <fredbaker.ietf@gmail.com>
In-Reply-To: <a630f8b8-e6ed-885a-a909-6c75dfd79892@gmail.com>
Date: Fri, 03 Mar 2017 14:51:17 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <49C3F649-FEC9-430E-B716-D5608E00D385@gmail.com>
References: <20170223134026.GI5069@gir.theapt.org> <98401ef7-cf41-b4a0-4d11-a7d840181bd0@gmail.com> <1047f5fc-ae40-be52-6bab-27f31fe5e045@gmail.com> <9a94feac-8d59-b153-d41c-04fc371e4db4@gmail.com> <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>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/YoO2kCvuCGrPfK24_hIAx2-OsrQ>
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: Fri, 03 Mar 2017 22:51:22 -0000
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 > --------------------------------------------------------------------
- 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