Re: [IPv6] draft-ietf-6man-rfc6724-update might break current ULA+IPv4 hostnames
Mark Smith <markzzzsmith@gmail.com> Sat, 11 November 2023 21:05 UTC
Return-Path: <markzzzsmith@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 0C2D1C1519AC for <ipv6@ietfa.amsl.com>; Sat, 11 Nov 2023 13:05:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.602
X-Spam-Level:
X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FN8igHo705m3 for <ipv6@ietfa.amsl.com>; Sat, 11 Nov 2023 13:05:42 -0800 (PST)
Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BE02C151547 for <ipv6@ietf.org>; Sat, 11 Nov 2023 13:05:42 -0800 (PST)
Received: by mail-lf1-x135.google.com with SMTP id 2adb3069b0e04-50949b7d7ffso4626498e87.0 for <ipv6@ietf.org>; Sat, 11 Nov 2023 13:05:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1699736740; x=1700341540; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=IMeS2YPwHv9hQ5OaPOn31enNZqRQIFNZCh91KOGlNko=; b=Lp2TMpJX1FKd8n6W4SwHmKvQ/ehHGYwlxyH1TYYNZgVY/YJMOwOH8kywuJWZrbIdSB yc6KLDls3eLxcRoX6eTVc3R+zMoargPtyj4jzSP/dXLZgEHL5lTgMzlCZR4OAMp+WM5I tbRIsZYwARzcCou4r2rqsENUYPIPJOmfqDkt77jIUtS18mLtiNLTxmBhfttOkuhktp0I ax/EI3wPZGOlnlKBybtou1HPC5pcr81AQCJZJK5NIUY8qrVtOgZNAIJeriQwLrGRmpIO Xo4ue8gplxY6Up5GZ1s5NA+pz2OmF3bllm2Vne2IQBPgh1SjXiwb2MFaCBynR1zeC7HD K+PA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699736740; x=1700341540; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=IMeS2YPwHv9hQ5OaPOn31enNZqRQIFNZCh91KOGlNko=; b=lOb2g33EKHp5/VwkmbA0YcQv9onZvCui2NO2lNEcP6Yu7MvKLC2OKVq0gus8pPCZKz CGsteaSDNBpRE+UKek65CuDWj8ypqk/eMAfJt8ah84gzjMOviSYN2Z1r6oGv/EDvvheB CfnV7zc7UoeLeWbeUS9lWSDJZb30fQs5jH7gfGT6P18TNm6RYJfswSAK7LzorUbAannj EpXVPez9p3+kpPWbkaempoLbC3k9YFnKyqu/+HDs28QNAUBCIcoIDwCW/SBZsyKK0Ypv 5pcGzqJ0stVP5FTBG3/oNREU2FDqzuWt9tPRKn1uJGz0kiir5Mglo3dXJfKM19M4QUF2 2gUg==
X-Gm-Message-State: AOJu0YwNsj0Hc4nL0JpJPtkDY2iZbx30pNcqgk57PjCdmGCm9DzL8r48 H4cSNnsIBYr6DKivpteJRxHSNsrqYuh0wfVbpeA=
X-Google-Smtp-Source: AGHT+IH38XVKJLLL1HG3VndR81E4eji8iRZWTIlCAB7oWibt9YxE6CzVK/Q03RxL0Y4vEz5k/GspmqSGbGNxhvtU2Bc=
X-Received: by 2002:a05:6512:3da6:b0:50a:7868:d3c0 with SMTP id k38-20020a0565123da600b0050a7868d3c0mr1159139lfv.23.1699736740145; Sat, 11 Nov 2023 13:05:40 -0800 (PST)
MIME-Version: 1.0
References: <CAKD1Yr2uD+XE+HA6vs3BfEchpWr5H2NEeoXLrXm7-U9_ckw1sA@mail.gmail.com> <CAN-Dau2Nw21wUm-mjxq3bnYczPJbApVhcZZ6oie+HiB4yvr_PQ@mail.gmail.com> <CAKD1Yr1z2x8iKXYQtPVifj-XkP7MeRq=NWe0gdWBGC1aS_j0Mg@mail.gmail.com> <CAO42Z2xZ5pvOpzdN+_=zUTvVhp-Rf80kA7HWsZNpzrg58mX2nQ@mail.gmail.com> <CAPt1N1kR2xnHR3GZn90V1hYxchOTXZ6dVrH=2sO=vdH_nVCtZA@mail.gmail.com> <cc9887f6-fe8c-de8f-6acb-a43662aed3f4@gmail.com> <CACMsEX-Ohqssrdzi87=W852fqkkbBi-tGWNyz91R1pYmeSFw6g@mail.gmail.com>
In-Reply-To: <CACMsEX-Ohqssrdzi87=W852fqkkbBi-tGWNyz91R1pYmeSFw6g@mail.gmail.com>
From: Mark Smith <markzzzsmith@gmail.com>
Date: Sun, 12 Nov 2023 08:05:30 +1100
Message-ID: <CAO42Z2xa9q=jy2TR4YzS05MenMVFKD88krr06jD5A-J=DOjK6Q@mail.gmail.com>
To: Nick Buraglio <buraglio@forwardingplane.net>
Cc: IETF IPv6 Mailing List <ipv6@ietf.org>, Ted Lemon <mellon@fugue.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000009bae120609e6cccb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/KS8CUlaBpwv_uwW14lqePyBC7Rk>
Subject: Re: [IPv6] draft-ietf-6man-rfc6724-update might break current ULA+IPv4 hostnames
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.39
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, 11 Nov 2023 21:05:47 -0000
Hi Nick, On Sun, 12 Nov 2023, 07:24 Nick Buraglio, <buraglio@forwardingplane.net> wrote: > A quick recap of this draft: > > * It changes the preference for ULAs to be above IPv4 > As I read the updated table, RIR assigned GUA DAs match on 0::/0, resulting in a preference of 40. ULA DAs match on fc00::/7, resulting in a preference of 30. This means GUA DAs will be preferred over ULAs when both are in use in a network, which I think will be the common case, which includes residential networks. Consequently there wouldn't be much if any point in having a ULA address space in a GUA addressed network. The local ULA address space would only be used to reach hosts that only have a ULA address. ULAs are basically the functional equivalent to the old site-locals, except with a big random number in them to overcome the ambiguity problems that site-locals had because they were a single, non-unique prefix that would have been duplicated many times. In RFC 3484, site-locals won over GUAs because they had a site-local scope, which is smaller than GUA's global scope. The same outcome needs to be achieved with ULAs verses GUAs. Specifically, fc00::/7 needs to have a preference of 45 if 0::/0 continues to have a preference of 40. Regards, Mark. * It leaves all labels intact, allowing for proper IPv6 to IPv6 behavior > * It performs a deliberate tactical change, aimed at demoting IPv4 below > all IPv6 enabling consistent behavior, and continuing to leverage the > aforementioned existing labels > * The newest version adds the section 5.5 MUST adjust back in, per IETF > 118 input > * The draft is deliberately as simple as we could make it because the > topic is fairly complex. It does not address any signaling or other changes > to the address selection mechanics that would need to be executed in > some new version of getaddrinfo(), and that is by design - see bullet 3. > > 118 comments are already in the working copy, we will address David's > great input this week and submit a new version. At that time we will humbly > request that it be considered for WGLC. > > nb > > On Sat, Nov 11, 2023 at 1:55 PM Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> On 12-Nov-23 07:25, Ted Lemon wrote: >> > You can’t deprecate ULAs. We’re using them. They work really well. What >> we are discussing here is if there are things we can do that make them work >> even better. >> >> Exactly. The problem is not ULAs, which work as intended. The problems >> are: >> >> a) Split-horizon DNS, while widely used, is somehow regarded as suspect. >> >> b) The RFC3484/6724/getaddrinfo() model is fundamentally inadequate. >> >> a) is also behind the answer to Lorenzo's question. It's wrong to put >> a ULA in public DNS, because it's a private address. It's fine to put >> a ULA in private DNS, because it's a private address. >> >> RFC 4193 says this: >> >> > At the present time, AAAA and PTR records for locally assigned local >> > IPv6 addresses are not recommended to be installed in the global DNS. >> >> That should probably have used RFC2119 language, but it's clear enough. >> >> Brian >> >> > >> > Op za 11 nov 2023 om 16:36 schreef Mark Smith <markzzzsmith@gmail.com >> <mailto:markzzzsmith@gmail.com>> >> > >> > I'm starting to believe it is better to deprecate ULAs. >> > >> > People can't seem to get past default address selection being a >> static starting point, and that it can't be made to cope with all >> situations because it is a static mechanism which can never cope with the >> normal dynamic situations of occasional unreachability and human error. >> > >> > If GUAs are preferred over ULAs, then ULAs aren't of any use in >> networks with GUAs. >> > >> > So much for, from RFC 4193, >> > >> > 4.2 <https://datatracker.ietf.org/doc/html/rfc4193#section-4.2>. >> Renumbering and Site Merging >> > >> > The use of Local IPv6 addresses in a site results in making >> > communication that uses these addresses independent of >> renumbering a >> > site's provider-based global addresses. >> > >> > >> > >> > >> > >> > On Sat, 11 Nov 2023, 20:57 Lorenzo Colitti, <lorenzo= >> 40google.com@dmarc.ietf.org <mailto:40google.com@dmarc.ietf.org>> wrote: >> > >> > Why is is a misconfiguration to put a ULA AAAA record in the >> DNS? Because it is never preferred over anything, adding it won't break >> anything, and it will work on IPv6-only networks when global IPv6 >> connectivity is down. I could totally see someone doing the following: >> > >> > server.smallcompany.com <http://server.smallcompany.com> AAAA >> fd73:4899:2a7f:a93a::53 >> > server.smallcompany.com <http://server.smallcompany.com> AAAA >> 2001:db8:4923::1 >> > server.smallcompany.com <http://server.smallcompany.com> A >> 192.0.2.1 >> > >> > This would work well today. The server would be reached: >> > >> > - over global IPv6, if the client has it >> > - over ULA, if the client is v6-only and is within small >> company's network but there is no global connectivity (e.g. ISP link down >> and addresses deprecated) >> > - over IPv4, otherwise >> > >> > People might well have done this today because it works for >> them. If we change the rules as proposed in this draft, it will stop >> working for any home network that has a ULA and IPv4, but no IPv6 (and >> there are lots of these). >> > >> > This is a fundamental property of ULA: it doesn't provide >> reachability. If we give all of ULA the same label, and prefer it over >> other addresses, we'll always end up with problems. >> > >> > What happened to the idea of treating "same /48" ULA >> differently from "rest of ULA space"? >> > >> > On Fri, 10 Nov 2023, 15:57 David Farmer, <farmer= >> 40umn.edu@dmarc.ietf.org <mailto:40umn.edu@dmarc.ietf.org>> wrote: >> > >> > In this scenario, a ULA source with a non-local ULA >> destination can only occur from a misconfiguration that includes both a ULA >> and Global IPv4 addresses in the Global DNS, contradicting Section 4.4 of >> RFC4193. >> > >> > Nevertheless, even if this misconfiguration happens, Happy >> Eyeballs, if implemented, will try the non-local ULA destination with the >> ULA source and the IPv4 destination and source pairings. The likely result >> is IPv4 being used in practice since the ULA source will typically fail to >> communicate with the non-local ULA destination, and IPv4 will succeed if >> IPv4 Internet connectivity is available. >> > >> > If Happy Eyeballs is not implemented, the non-local ULA >> destination with the ULA source is preferred, and the ULA source will >> typically fail to communicate with the non-local ULA destination; however, >> if the operational guidelines in Section 4.3 of [RFC4193] are followed. In >> that case, recognizing this failure can be accelerated, and transport layer >> timeouts (e.g., TCP) can be avoided. These guidelines will cause a >> Destination Unreachable ICMPv6 Error to be received by the source device, >> signaling the next address in the list to be tried, as discussed in Section >> 2 of RFC 6724; >> > >> > Well-behaved applications SHOULD NOT simply use the >> first address returned from an API such as getaddrinfo() and then give up >> if it fails. For many applications, it is appropriate to iterate through >> the list of addresses returned from getaddrinfo() until a working address >> is found. For other applications, it might be appropriate to try multiple >> addresses in parallel (e.g., with some small delay in between) and use the >> first one to succeed. >> > >> > >> > Should this also be discussed in the draft? >> > >> > Thanks >> > >> > On Fri, Nov 10, 2023 at 3:35 AM Lorenzo Colitti <lorenzo= >> 40google.com@dmarc.ietf.org <mailto:40google.com@dmarc.ietf.org>> wrote: >> > >> > I don't know how common this is, but it's probably >> worth thinking about. >> > >> > Many home routers assign ULAs, even if they don't have >> native IPv6. On such networks, a hostname that has ULA and IPv4 (or ULA and >> global and IPv4) will currently work using IPv4. >> > >> > If hosts update to follow the new rules in >> draft-ietf-6man-rfc6724-update, that will break because new hosts will >> prefer ULA over IPv4. This won't work, because the ULA is actually a >> different ULA and the home router will drop the packets. >> > >> -------------------------------------------------------------------- >> > IETF IPv6 working group mailing list >> > ipv6@ietf.org <mailto:ipv6@ietf.org> >> > Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 < >> https://www.ietf.org/mailman/listinfo/ipv6> >> > >> -------------------------------------------------------------------- >> > >> > >> > >> > -- >> > =============================================== >> > David Farmer Email:farmer@umn.edu <mailto: >> Email%3Afarmer@umn.edu> >> > Networking & Telecommunication Services >> > Office of Information Technology >> > University of Minnesota >> > 2218 University Ave SE Phone: 612-626-0815 >> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 >> > =============================================== >> > >> > >> -------------------------------------------------------------------- >> > IETF IPv6 working group mailing list >> > ipv6@ietf.org <mailto:ipv6@ietf.org> >> > Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 < >> https://www.ietf.org/mailman/listinfo/ipv6> >> > >> -------------------------------------------------------------------- >> > >> > -------------------------------------------------------------------- >> > IETF IPv6 working group mailing list >> > ipv6@ietf.org <mailto:ipv6@ietf.org> >> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> <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 >> > -------------------------------------------------------------------- >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >
- [IPv6] draft-ietf-6man-rfc6724-update might break… Lorenzo Colitti
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… Erik Kline
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… Ole Trøan
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… Vasilenko Eduard
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… David Farmer
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… Ted Lemon
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… Erik Auerswald
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… Ole Troan
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… Jeremy Duncan
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… Brian E Carpenter
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… Ted Lemon
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… Brian E Carpenter
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… Ole Trøan
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… David Farmer
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… Vasilenko Eduard
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… Lorenzo Colitti
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… Mark Smith
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… Ted Lemon
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… Brian E Carpenter
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… Mark Smith
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… Nick Buraglio
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… Nick Buraglio
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… Brian E Carpenter
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… David Farmer
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… Mark Smith
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… Michael Richardson
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… Nick Buraglio
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… Ole Trøan
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… David Farmer
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… Brian E Carpenter
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… Brian E Carpenter
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… Brian E Carpenter
- [IPv6] RFC 6724 shouldn't prefer partial reachabi… Lorenzo Colitti
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Brian E Carpenter
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Vasilenko Eduard
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Mark Smith
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Ted Lemon
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Soni L.
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Mark Smith
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Kyle Rose
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Havard Eidnes
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Kyle Rose
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Nick Buraglio
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… Ted Lemon
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Brian E Carpenter
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Ted Lemon
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Mark Smith
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… David Farmer
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Brian E Carpenter
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Kyle Rose
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Ted Lemon
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Michael Richardson
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… David Farmer
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… David Farmer
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Brian E Carpenter
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Lorenzo Colitti
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Mark Smith
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… David Farmer
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Nick Buraglio
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… Mark Smith
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Brian E Carpenter
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… David Farmer
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Lorenzo Colitti
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Lorenzo Colitti
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Michael Richardson
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Vasilenko Eduard
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Brian E Carpenter
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Ed Horley
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Philipp S. Tiesel
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Michael Richardson
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Ole Troan
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Brian Carpenter
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Michael Richardson
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Philipp S. Tiesel
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Nick Buraglio
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Ole Troan
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Ted Lemon
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Ole Trøan
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Ted Lemon
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Ole Troan
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Ted Lemon
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Ole Troan
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Ted Lemon
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Ole Troan
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Ted Lemon
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Ole Trøan
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Kyle Rose
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Nick Buraglio
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Ted Lemon
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Ole Trøan
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Mark Smith
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Kyle Rose
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Ole Troan
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Ted Lemon
- [IPv6] Multi6 (no longer RFC 6724 shouldn't prefe… Brian E Carpenter
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Philipp S. Tiesel
- [IPv6] Multi6 (no longer RFC 6724 shouldn't prefe… Brian E Carpenter
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Mark Smith
- [IPv6] Multi6 (no longer RFC 6724 shouldn't prefe… Brian E Carpenter
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Nick Buraglio
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Mark Smith
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Ed Horley
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Nick Buraglio
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Kyle Rose
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Brian E Carpenter
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Kyle Rose
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Brian E Carpenter
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Mark Smith
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Ted Lemon
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Kyle Rose
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… Michael Richardson
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Ted Lemon
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Brian E Carpenter
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Brian E Carpenter
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Ted Lemon
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Michael Richardson
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Nick Buraglio
- Re: [IPv6] draft-ietf-6man-rfc6724-update might b… David Farmer
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Kyle Rose
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Michael Richardson
- Re: [IPv6] Multi6 (no longer RFC 6724 shouldn't p… Nick Buraglio
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Brian E Carpenter
- Re: [IPv6] RFC 6724 shouldn't prefer partial reac… Kyle Rose
- Re: [IPv6] Multi6 (no longer RFC 6724 shouldn't p… Philipp S. Tiesel
- [IPv6] Multi6 (no longer RFC 6724 shouldn't prefe… Brian E Carpenter