Re: [IPv6] Adoption call for draft-bctb-6man-rfc6296-bis
Nick Buraglio <buraglio@forwardingplane.net> Thu, 28 March 2024 14:45 UTC
Return-Path: <buraglio@forwardingplane.net>
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 E0639C15108A for <ipv6@ietfa.amsl.com>; Thu, 28 Mar 2024 07:45:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forwardingplane.net
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 3PMZS_yg4GND for <ipv6@ietfa.amsl.com>; Thu, 28 Mar 2024 07:45:19 -0700 (PDT)
Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 35085C15153F for <ipv6@ietf.org>; Thu, 28 Mar 2024 07:45:19 -0700 (PDT)
Received: by mail-qt1-x82c.google.com with SMTP id d75a77b69052e-43182c2457bso5775791cf.1 for <ipv6@ietf.org>; Thu, 28 Mar 2024 07:45:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=forwardingplane.net; s=google; t=1711637118; x=1712241918; 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=+yOwf38YkQScWf8o/bCD94IcMzDFMIkS7n1xsy3XA4c=; b=rQTfuvlcU7zKlFhrZ/+2hR8DcdNF/kuXGB/NB47hJdkL9+119HnfAJQtMY021+50Kj Zw4jYdquX7B5/QX8YFs7kYsp4sCV4p7+RhrtX7vFbYczTNZHA8MpW5PXZBKn+Adfv4l1 x/cB1sdmfiqWwaILIPyDBd10UcgOcY/UvnaLM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711637118; x=1712241918; 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=+yOwf38YkQScWf8o/bCD94IcMzDFMIkS7n1xsy3XA4c=; b=MZEpcGCHsI4MVqzSqYAeXDHV2MDDEpWhtEh8yrSxVam+dEO4mP7+KYp9iTdddesA7t ymPfgy9J82wu/PnYbub0eG2NFKFPd3LRrCqDaLPW2p+T+TMdSU2sdz4NMWWKaUsBFj4V j+NxR3uGojI21hvLqUDLGwyzvPib3UXonM0QPAJdSct5Kw1becpVmmUnr/T45N7X4pno uuanzBJPo/y2HEOP0Epqnef7qm3h7YegQn5dRn1uKxvFzg1blwdHjahuY3sHNtdcc43M WvZjU+RzlsNqX6ENrKjfKeu+4rbb4Aa+o7HcZ3TFVgvoua257t2XjgwP2+IT3NJUGwnr 6sqw==
X-Forwarded-Encrypted: i=1; AJvYcCV8/vmh07VEabHF35Z/13W1fpRQp1lHolIfL5jpVUtyTTlyh4kwlhRAf9Ic0y1k43a6BkDSOEEuw1JE7dzS
X-Gm-Message-State: AOJu0YwAv1uBwclJ3sC0gohhVAlhF/DLXs87KbmH+4ZGLL9BUfLSWvO3 6WEAwzLT5bHWx24nBdV+x4ebfdtWp3OANkHii114gisYlv3/fs3NtToQrNfFkh9ZT1dLrj67aDN ZP3Niq/YT92MVdFGlIdyMFpdE8gw1v386YK9dhJwbQdAojYCHmw==
X-Google-Smtp-Source: AGHT+IHxb5s/tK32dtxZ1sFhY2Oek+Bkjl4XfPegQFWpSVGn7VSkwZJwPbn1b4D/kG8L9U8F8S9ouVJKRH9F47cAXrU=
X-Received: by 2002:ac8:5993:0:b0:431:3df2:207b with SMTP id e19-20020ac85993000000b004313df2207bmr3074153qte.50.1711637117802; Thu, 28 Mar 2024 07:45:17 -0700 (PDT)
MIME-Version: 1.0
References: <CADmxuPF1AReQCSY13HjqXE+8Jofy_uoo1wmnzs8+whG7Tdc+UQ@mail.gmail.com> <836E3A12-FAAF-4C19-91A1-322203645AAA@employees.org> <CADmxuPEBXYeTPrJqfPEGaxmUM75iKQx6kfCcpHHjxyekZy0xuQ@mail.gmail.com> <2DB6E450-9EE4-438A-9D3B-78DDFF0CA78F@employees.org> <CAKD1Yr0+ArFfn7uZddMAGpxYroSxw-u=cpti4mwp_7-yRBSRSA@mail.gmail.com> <CACMsEX_Can2Uc4dEvC+9B_zG3OuP0YwQnGr=4uQyrFcjjgLHjA@mail.gmail.com> <CAO42Z2yghAZdk_ZO8nzufkJXsgsJMhUNi_Fm+SpUUQ1b7GLCuQ@mail.gmail.com>
In-Reply-To: <CAO42Z2yghAZdk_ZO8nzufkJXsgsJMhUNi_Fm+SpUUQ1b7GLCuQ@mail.gmail.com>
From: Nick Buraglio <buraglio@forwardingplane.net>
Date: Thu, 28 Mar 2024 09:45:06 -0500
Message-ID: <CACMsEX8S26NMaseCfepBzoHHyN68k5aApSwG4nSKwJWk4mMKOA@mail.gmail.com>
To: Mark Smith <markzzzsmith@gmail.com>
Cc: Lorenzo Colitti <lorenzo=40google.com@dmarc.ietf.org>, 6man WG <ipv6@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000644da00614b9920c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/5uey1cfhkt5z2FteU-u8VZeYiq0>
Subject: Re: [IPv6] Adoption call for draft-bctb-6man-rfc6296-bis
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: Thu, 28 Mar 2024 14:45:24 -0000
On Wed, Mar 27, 2024 at 8:34 PM Mark Smith <markzzzsmith@gmail.com> wrote: > > > > On Thu, 28 Mar 2024, 02:50 Nick Buraglio, <buraglio@forwardingplane.net> wrote: >> >> >> >> On Tue, Mar 26, 2024 at 8:31 PM Lorenzo Colitti <lorenzo= 40google.com@dmarc.ietf.org> wrote: >>> >>> On Tue, Mar 26, 2024 at 6:33 PM Ole Troan <otroan@employees.org> wrote: >>>> >>>> The benefit of NAT class mechanisms, is that cost and benefit are aligned. Only one side needs to deploy it. >>> >>> >>> Actually, the benefit of NAT class mechanisms is that one party deploys them and another party incurs the costs. NAT is great for the network operator, because it moves a number of problems out of the network operator's domain. But it doesn't do that by solving the problem, it does so by making the application's job more difficult. >> >> >> I don't think that is typically true. > > > For client/server applications, where the client is on the inside of the NAT with a private address, and the server is on the outside with a public address, that wouldn't be typically true. > > However, for applications where the communications model is peer-to-peer, or a mix of client/server and peer-to-peer, the application developer has to implement RFC 8445 ICE using STUN and TURN for NAT traversal, incurring additional development, debugging and testing costs. Is that still accurate for a device behind NPTv6? RFC3235 section 3.1.5 points out that statically configured NAT bindings are largely exempt from the problems of port mapping, and NPTv6 is only a non-stateful translation that does not require the transport header to be re-written, simply translating the first 64 bits, so unless the communication embeds an address, which is problematic for all of the obvious reasons we see with things like legacy FTP, the peer-to-peer applications should work - assuming no security policy is in place to prevent it. In fact, vendor documentation specifically calls out one of the advantages of NPTv6 as keeping peer-to-peer networking accessible: *The NPTv6 support allows you to redirect or forward packets from one network to another in an IPV6 environment. The NPTv6 support on is an algorithmic translation function which provides a 1:1 relationship between the addresses within the inside and outside network. When NTPv6 is used, you can interconnect different networks and support multihoming, load balancing, peer-to-peer networking. The NPTv6 does not create any state in the data plane and hence can operate using minimal memory and also supports high availability by default.* Of course, it's vendor documentation so take it with a grain of salt, but I would not expect that to remain in published documentation unless it actually had some validity. > > Alternatively the application developer adopts a client/server communications model for the application, even though a peer-to-peer model would be more scalable and more robust against a centralised server failure and server performance problems. > > This is why I say that NAT (of any type) imposes a default client (inside NAT) /server (outside NAT) communications model at the IPv4 or IPv6 network layers, rather than the default peer-to-peer model that can then accommodate both client/server and peer-to-peer applications communications models. > > NPTv6 may be stateless, however since hosts behind the NPTv6 will have to discover their public addresses via ICE if they want to be peers, NPTv6 still imposes those ICE costs on application developers and the applications' end-users. Do they need to discover that? If the mapping is 1:1 it is functionally the same address unless there is an embedded address in the protocol communications, right? Or am I missing something obvious? > > Network engineers who deploy NATs aren't directly exposed to or pay any of these additional application development costs (other than when they're the application users), which is why it appears that NAT is a simple and low impact technology to deploy. Given that nearly every application must be written to support dual-stack, and therefore must implement these techniques for port address translation, is that cost not already incurred by default? I understand that it may take some work to add IPv6 support to applications that require ICE/STUN/TURN, however, assuming (and that's a big assumption on my part), that the 1:1 stateless nature of NPTv6 and a lack of an embedded address, what is the surface area of applications that need to incur that cost specifically for IPv6 where it does not currently exist? Is it 90% of applications? Is is 10%? I don't actually know but would like to. Likelihood of occurrence is a key in making design decisions, at least in my world. I fully admit that I am not an application developer, and there are undoubtedly aspects here that I do not understand, so pardon my potentially basic questions - I simply don't have the background but would like to fully understand. Knowing the likelihood and actual need at an application level where it does not already exist as part of a normal development workflow to support existing environments, and specifically where it is required where NPTv6 is a valid design model would be very, very useful, especially with the use cases for NPTv6 being fairly specific. > > Regards, > Mark. > >> >> I will definitely say from experience that there is a significant operational cost to deploying any translation tool, and more so when there is active state tracking and overload involved. There are often (but not always) logging requirements to do these things at scale, and there are definitely operational costs in dealing with state table tracking and scaling. These don't exist at the same level for mechanisms that do not track state and that do not masquerade using port address translation. They may still incur application cost, or they may not, that is always going to be based on the application stack and is more likely in real time applications that don't use a third party intermediary, as you have stated. >> >> There are similarities in the translation toolkits, yes, they all perform translation at some level. However, what is generally referred to as "NAT" in the general term is typically PAT or NAPT or Masquerading, depending on the nomenclature. That said, *because* it is significantly easier to deploy NAPT, I do not believe that it is an apples to apples comparison. They're all tools in the "translation" category, but they're definitely not all created equally. NPTv6 does a 1:1 translation, the NAT that folks seem to be referencing in the IPv4 world does not, and I do not believe it is a reasonable comparison. It's a far better comparison to say that NPTv6 is like a traditional one-to-one NAT (which does still have notable, albeit significantly fewer considerations, which I believe are noted in the draft). >> >> >> nb >> >> -------------------------------------------------------------------- >>> >>> 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] Adoption call for draft-bctb-6man-rfc6296-… Bob Hinden
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Bob Hinden
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Templin (US), Fred L
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ed Horley
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Brian E Carpenter
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… mohamed.boucadair
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Jeremy Duncan
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Costello, Tom
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… IPv6
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Neil Hanlon
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… jordi.palet@consulintel.es
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Bob Hinden
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Tom Coffeen
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Tim Chown
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Vasilenko Eduard
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Eric Vyncke (evyncke)
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Dale W. Carder
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Brian E Carpenter
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ole Trøan
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Naoki Matsuhira
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ted Lemon
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Brian E Carpenter
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ted Lemon
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ole Troan
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Brian E Carpenter
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Tim Chown
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Naoki Matsuhira
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ole Troan
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ted Lemon
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ole Troan
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ted Lemon
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ole Trøan
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Brian E Carpenter
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ole Troan
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Michael Richardson
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Simon Hobson
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ted Lemon
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Mark Smith
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ole Troan
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Michael Richardson
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Brian E Carpenter
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ted Lemon
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Brian E Carpenter
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Philip Homburg
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Nick Buraglio
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ole Troan
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ole Troan
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Nick Buraglio
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ted Lemon
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Nick Buraglio
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ted Lemon
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Brian E Carpenter
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Lorenzo Colitti
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ole Trøan
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ted Lemon
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ole Troan
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Lorenzo Colitti
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ole Troan
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Brian E Carpenter
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Brian E Carpenter
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ole Troan
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Brian E Carpenter
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ted Lemon
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Nick Buraglio
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Brian E Carpenter
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… jordi.palet@consulintel.es
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ted Lemon
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ole Troan
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Tim Chown
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Mark Smith
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ted Lemon
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Lorenzo Colitti
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Philip Homburg
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Timothy Winters
- Re: [IPv6] First hop selection [was: Adoption cal… Ted Lemon
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ole Trøan
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Philip Homburg
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ole Trøan
- Re: [IPv6] signaling NPTv6 (was Re: Adoption call… Tim Chown
- Re: [IPv6] First hop selection [was: Adoption cal… Lorenzo Colitti
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ole Troan
- Re: [IPv6] First hop selection [was: Adoption cal… Philip Homburg
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ole Troan
- Re: [IPv6] First hop selection [was: Adoption cal… Ted Lemon
- Re: [IPv6] First hop selection [was: Adoption cal… Philip Homburg
- Re: [IPv6] First hop selection [was: Adoption cal… Ted Lemon
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Michael Richardson
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ted Lemon
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Tim Chown
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Mark Smith
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ole Trøan
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Mark Smith
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Mark Smith
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Lorenzo Colitti
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Erik Kline
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Michael Richardson
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ted Lemon
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Michael Richardson
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Jima
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ole Troan
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Tim Chown
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Brian E Carpenter
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ted Lemon
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Brian E Carpenter
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Michael Richardson
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Michael Richardson
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ted Lemon
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Lorenzo Colitti
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Mark Smith
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Michael Richardson
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Lorenzo Colitti
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Mark Smith
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Brian E Carpenter
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Nick Buraglio
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Michael Richardson
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ed Horley
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Nick Buraglio
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Brian E Carpenter
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Naoki Matsuhira
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Brian E Carpenter
- Re: [IPv6] First hop selection [was: Adoption cal… Philip Homburg
- Re: [IPv6] First hop selection [was: Adoption cal… Brian E Carpenter
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Tim Chown
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Nick Buraglio
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ole Troan
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Templin (US), Fred L
- Re: [IPv6] First hop selection [was: Adoption cal… Ole Troan
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Nick Buraglio
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Lorenzo Colitti
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Lorenzo Colitti
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Naoki Matsuhira
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Lorenzo Colitti
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Naoki Matsuhira
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Michael Richardson
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Michael Richardson
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ted Lemon
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Templin (US), Fred L
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ole Troan
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Brian E Carpenter
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ted Lemon
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Brian E Carpenter
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ted Lemon
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… David Lamparter
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Vasilenko Eduard
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Michael Richardson
- Re: [IPv6] First hop selection [was: Adoption cal… Ted Lemon
- Re: [IPv6] First hop selection [was: Adoption cal… Vasilenko Eduard
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Naoki Matsuhira
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Lorenzo Colitti
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Michael Richardson
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Brian E Carpenter
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ted Lemon
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Lorenzo Colitti
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ted Lemon
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Philip Homburg
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ole Troan
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Tim Chown
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ole Troan
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Tim Chown
- Re: [IPv6] signaling NPTv6 (was Re: Adoption call… Ted Lemon
- Re: [IPv6] signaling NPTv6 (was Re: Adoption call… Brian E Carpenter
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Tim Chown
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Michael Richardson
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Lorenzo Colitti
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Mark Smith
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Brian E Carpenter
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Mark Smith
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Jima
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Nick Buraglio
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Mark Smith
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Nick Buraglio
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ted Lemon
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Nick Buraglio
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… IPv6
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Brian E Carpenter
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Brian E Carpenter
- Re: [IPv6] signaling NPTv6 (was Re: Adoption call… Michael Richardson
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ted Lemon
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Michael Richardson
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ole Troan
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Nick Buraglio
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… David Lamparter
- Re: [IPv6] First hop selection [was: Adoption cal… Brian E Carpenter
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… mohamed.boucadair
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Michael Richardson
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ole Troan
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ackermann, Michael
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Nick Buraglio
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ole Troan
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Templin (US), Fred L
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ole Trøan
- [IPv6] First hop selection [was: Adoption call fo… Brian E Carpenter
- Re: [IPv6] First hop selection [was: Adoption cal… Nick Buraglio
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Templin (US), Fred L
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Lorenzo Colitti
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ted Lemon
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Jima
- Re: [IPv6] External address discovery (Was: Adopt… mohamed.boucadair
- [IPv6] Conclusion of Adoption call for draft-bctb… Bob Hinden
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ole Trøan
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Naoki Matsuhira
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ole Trøan
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… mohamed.boucadair
- [IPv6] External address discovery (Was: Adoption … Ole Troan
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Philip Homburg
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Nick Buraglio
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Brian E Carpenter
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… IPv6
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ted Lemon
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Brian E Carpenter
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ted Lemon
- Re: [IPv6] Conclusion of Adoption call for draft-… Michael Richardson
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Lorenzo Colitti
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Tim Chown
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Lorenzo Colitti
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Lorenzo Colitti
- [IPv6] signaling NPTv6 (was Re: Adoption call for… Michael Richardson
- Re: [IPv6] Conclusion of Adoption call for draft-… Behcet Sarikaya
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Lorenzo Colitti
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Brian E Carpenter
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Nick Buraglio
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Brian E Carpenter
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Michael Richardson
- Re: [IPv6] External address discovery (Was: Adopt… Ole Troan
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Brian E Carpenter
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Jima
- Re: [IPv6] External address discovery (Was: Adopt… mohamed.boucadair
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Ted Lemon
- Re: [IPv6] Adoption call for draft-bctb-6man-rfc6… Nick Buraglio