Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability

Lorenzo Colitti <> Wed, 05 August 2015 08:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D4E091B2D50 for <>; Wed, 5 Aug 2015 01:13:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.788
X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bh8eN5j6sJMe for <>; Wed, 5 Aug 2015 01:13:33 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 82B161B2D91 for <>; Wed, 5 Aug 2015 01:13:25 -0700 (PDT)
Received: by ykoo205 with SMTP id o205so29364867yko.0 for <>; Wed, 05 Aug 2015 01:13:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ArXXsOIv+mvP2r2GKtbv031fLliKj2ibTq6wGSDiAaY=; b=QGJB39/1UMccLI1uUkhOBqPF0RxNExPwBjvaPSLTazTqpYRuy45jLHgWAMOhePyI6v MvrXIIa2A8ip8C+nKLjH2W6agN6MOf04yK+fElOBCKTxNRPrqNUpOH6LpkLW7Avnd6Ob sDZyH0H/GTQy7j41OJYVkWFOoToqULgTlc3oSdmR1XnEp2YFf7yfS3p0rdCy1ANQj8yg APzf5TqL1AereGxBxP4CW0qXDZRrMLE97miZWFB+uP2pwPKk25c1pZ9le3DUjDcVguhi p972l9MuZWU8e58AtSAcFS4/toO/rnAa/OP53REquPpWRfUB8lG8zInV1RjYfUpXexAW etdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ArXXsOIv+mvP2r2GKtbv031fLliKj2ibTq6wGSDiAaY=; b=DeI6r84w0MqTRVRWZNmVrVo1HVkZ/y/Sc5Z2icYboxzDdHabn6EObVPj1aKDrIPfpI 5CKT9M/XP+uQVpROcVso4s24Bl4Xxu7qXLMeHB5edjIqQW4xTq2c+hWkVYSU/edY7wnw w39W7HnsPGgMWY5h31q3DVajjwRyoFy6yiZZf0XOYEOq46Bwz2tJQKSSQF0uCUNz4pR0 cs6ik3zurhMKFhNS0c695NTeF3E9GIFSVcRw1MePiV1qLxnJfNNxEanpWDIIz3QQOAjJ VfC16H1poyOtmVqGiHJhngeffKs7mSRGdN7P1tQAR34EGXZa+PDyLlUrSb4w/DSIzt43 IPbQ==
X-Gm-Message-State: ALoCoQmOEheuH5+saBI9v2mFD6vsduJFPU148syITw8RiE/bQ313Hf9yfJcXzc9PNvQBHmFwmARR
X-Received: by with SMTP id u82mr8265959ykc.53.1438762404713; Wed, 05 Aug 2015 01:13:24 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 5 Aug 2015 01:13:04 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Lorenzo Colitti <>
Date: Wed, 5 Aug 2015 17:13:04 +0900
Message-ID: <>
To: "George, Wes" <>
Content-Type: multipart/alternative; boundary=001a113b396e0d1f8f051c8bfab6
Archived-At: <>
Cc: "" <>, "" <>
Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 05 Aug 2015 08:13:35 -0000


many of these comments will be addressed in a respin, so I'm picking only
one to answer here.

Section 5 - I think we need to cut this section down to a bare minimum or
> eliminate it. Waving the NAT boogeyman isn't really the argument to lead
> with, unless the authors or other OS manufacturers actually see this as a
> credible alternative and are willing to implement it instead of other
> options. Otherwise it's just FUD. It's more accurate at this point to say
> that NAT doesn't exist for IPv6, because the IETF document is experimental
> (IIRC, I'm writing this on a plane and can't check) and no implementations
> really exist in the wild, so another solution is required. We've already
> written plenty about why NATs are bad elsewhere.

Unfortunately NAT66 *is* a credible alternative, and implementations
definitely do exist. I know for sure that Juniper ships a fully-stateful
NAT implementation on the SRX (and I don't mean NPTv6, I mean
fully-stateful NAT44-style address+port NAT), and I think I head that Cisco
does too.

That said, this document is about general-purpose hosts, so let's take
Android as an example. Linux has had a fully-stateful NAT66 implementation
since late 2012 - - and
members of the Android community have proposed enabled it multiple times,
for example:

These changes ended up not being included in the OS, but I think part of
the motivation is that they would not have added any useful functionality
that could not be obtained in a better way. The VPN code was rewritten in
5.0 to use per-app routing instead of in-device NAT (which fixed a series
of IPv4 bugs as well), and that brought IPv6 support without needing to use
NAT66. And even though stock Android does not yet support IPv6 tethering,
NAT66 would not have provided any benefit because Android doesn't support
networks that require explicit requests to obtain IPv6 addresses (i.e.,
DHCPv6-only networks) and thus can use ND proxying for tethering with no
loss of functionality.

On the other hand, for a device that supports DHCPv6-only networks that
provide only one address, NAT66 *would* provide useful functionality: it
would make it possible to provide IPv6 tethering and other functions that
require more than one address on those networks.