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

"Hemant Singh (shemant)" <> Tue, 07 July 2015 16:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 07F161ACE26 for <>; Tue, 7 Jul 2015 09:28:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EyFaoCWG_geI for <>; Tue, 7 Jul 2015 09:27:54 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7929F1ACE29 for <>; Tue, 7 Jul 2015 09:27:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=3679; q=dns/txt; s=iport; t=1436286474; x=1437496074; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zY9QiJAE5ykWk2cLZLv2c8qefq4uMSxu1wwvkNu1kfo=; b=TINtdplJWjsGRgyKxGCG4QCO8q9BIhuqkMLWaniXooqlQGfQ2+xyzTXD hJ0vBR1tW4SeT33391siTE9JUthbIMtsuaRV/Xmrbf1XkhAin3vW6o47J sDVl3ifD3L6s305AaBgELMJKGAX9N/xTChRD5Fn0cUVtzpD5hKQmoaF1z 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.15,424,1432598400"; d="scan'208";a="13357860"
Received: from ([]) by with ESMTP; 07 Jul 2015 16:27:53 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t67GRras019242 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 Jul 2015 16:27:53 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Tue, 7 Jul 2015 11:27:53 -0500
From: "Hemant Singh (shemant)" <>
To: "Fred Baker (fred)" <>, Andrew Yourtchenko <>
Thread-Topic: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability
Thread-Index: AQHQt+GUs8uYiRy2iUusolpZfA8qWp3PTI+AgAAnzoCAALsP8A==
Date: Tue, 7 Jul 2015 16:27:53 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Tue, 07 Jul 2015 16:28:00 -0000

Seeing Fred's response, I do agree with him.   My comments are included below.

1. The IPv6 node requirements document does not block any host from using multiple addresses.  So why write a new draft whose abstract says "use multiple addresses for hosts"?  Thus more problem definition is needed in the abstract. 
2. In section 3 and other places in the document, using a /64 die tethering is a hack even if the IETF has an RFC covering the hack.  Use the DHCPv6-PD for tethering. 
3. In section 3, "running virtual machines on hosts" is obvious and falls out from the fact that each virtual machine needs it IPv6 address and mac-address.  This problem does not relate to a host with one mac-address using multiple IPv6 addresses.
4. Section 7.  SLAAC as defined in RFC4862 supports only one IPv6 global address if one prefix is advertised in the RA to the host.  Thus the text in this section can be improved.  If the RA includes multiple prefixes, then the host can generate a global IPv6 address using SLAAC.  
5. Section 8.1.  SAVI for a non-DHCPv6 network also needs a DAD Proxy.  Just add a DAD Proxy to the router and the DAD Proxy programs the dataplane's SAVI.  Also, anywhere the document says DHCPv6 is the only means for admins at universities or corporate deployments to track host sources is questionable.   The router can add DAD Proxy support and then the admin grabs data from the routers DAD proxy for host sources.  I have already made such a statement to v6ops in another thread.  
6.  Please read the IPv6 CE router documents which describer use of an IPv6 loopback address and interface.  Such a loopback interface can serve any app that needs a stable address.

In summary, I have not seen enough of a problem statement nor do I agree with many technical statements in the document to support this version of the document for WG adoption.



-----Original Message-----
From: v6ops [] On Behalf Of Fred Baker (fred)
Sent: Monday, July 06, 2015 8:02 PM
To: Andrew Yourtchenko
Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability

Thanks. One question. Chair hat off.

Section 2 identifies the current deployment model - each interface has a link-local address, a SLAAC address, and one or more temporary addresses. I haven't heard anyone complaining about that. Section 3 goes on to discuss virtual machines/containers, which might each have additional addresses, and the model Facebook is reportedly using, which gives individual addresses to processes. It also mentions draft-herbert-nvo3-ila, which is not a stupid model - I still have some comments on it in a multi-administration environment or for running applications in an "inside" and an "outside" address ("NAT has well-known drawbacks"), but it at least gets rid of the random encapsulations predominant in data centers today.

In other words, we already assign multiple addresses, by some means, to each interface in a network.

You mention SLAAC. Lorenzo mentions that in section 7. He also mentions DHCP address and prefix allocation.

The statement that I don't see in the document, which would help me personally, is a problem statement. I would guess that the problem statement is "we think some networks are limiting host interfaces to a single IPv6 address." I'd want a little more detail, but I'll bet that's the crux of it.

So my question is: "precisely what problem are we solving here?".