Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem

Mark ZZZ Smith <markzzzsmith@yahoo.com.au> Wed, 23 October 2013 19:09 UTC

Return-Path: <markzzzsmith@yahoo.com.au>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6292111E834F for <v6ops@ietfa.amsl.com>; Wed, 23 Oct 2013 12:09:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.324
X-Spam-Level:
X-Spam-Status: No, score=-1.324 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_13=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDLSf80GDZsT for <v6ops@ietfa.amsl.com>; Wed, 23 Oct 2013 12:09:43 -0700 (PDT)
Received: from nm49-vm3.bullet.mail.bf1.yahoo.com (nm49-vm3.bullet.mail.bf1.yahoo.com [216.109.115.190]) by ietfa.amsl.com (Postfix) with ESMTP id E536111E81DF for <v6ops@ietf.org>; Wed, 23 Oct 2013 12:09:42 -0700 (PDT)
Received: from [98.139.215.141] by nm49.bullet.mail.bf1.yahoo.com with NNFMP; 23 Oct 2013 19:09:42 -0000
Received: from [98.139.212.196] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 23 Oct 2013 19:09:42 -0000
Received: from [127.0.0.1] by omp1005.mail.bf1.yahoo.com with NNFMP; 23 Oct 2013 19:09:42 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 215623.87756.bm@omp1005.mail.bf1.yahoo.com
Received: (qmail 15827 invoked by uid 60001); 23 Oct 2013 19:09:42 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com.au; s=s1024; t=1382555382; bh=z3UPXsIumBqJJS1Fgz0robaqAWeRxijbi3r0ce2c8Oc=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5UT2iqB4BdtO8ir/tFjZtBfhynJr/mV1ImDfpa3VBdFb3LKsw1dtRxJLlHwCQX7HgseX7KGCEpG9vbrWZqpPVNJj6b6MuZ+/ag6EPGqJZdNbj9d3F4wwRVlMuT7OT/4wkcrHRGb0eP1PIgIaNe0LCWFMgrBE9tpstja0Jivxa0A=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=zJnpYN6h0epdXmay0kJ3j5Y9zStCGn5Fr1yLf+EpkOzoTujEPtlWDL6DH4paGQux+ZzRoGmo3MKIzpJKmRlkodjWBbRHqE8sbIvJeFm/oQq2RU39J/5HjosdGLdvQ/pyfDe3+35IxmOQtjNeU3KX8Uu1ZmzCSD83HPchsA8MClg=;
X-YMail-OSG: ZHUT_0oVM1mLZHmvoLs0JatBXq3dVdUd0Bdw2QAO.tWZYq9 rT.4lLetViR5DG3afiPH0uemTWZ8mr0javF7AR5eKhPQIKfkwIbHDtj31DLa GFIh6cZtbIkFQKkIYj_NL..nT4taTFclaW.BxyymUVY60eIXc0n.o5cj8eVJ Qn0bALT7Smumo4sU_U7FR029IVDGqy2nKTzIGzg.wkq8fzEAgKJZqIGNj4jA 3wCuZrLJh1rVno8ttgTXRqJ._IOnS9q5ec6vHxqr1IWAHmm0gTUsUogd_EzH aRfT7VL.tyDw9Wzy3FhS0LuhvLnY23FD1c5z1hA0nP7G7STkOO8Hb91mQmYN QapppXB29MerqOfo2982X6jVhlbEmTSO2tFOZRaSKBW5qt3y4THWH_Kdj3sd Igzl2ikGzeGONmOxWhkgX6TBzPGB_vDSBvzSKI2HMM5XS4zkFRxg5jVNPjvb Qt7LJeDrrlWPtP_88rtxjidy_cP9CLiE4nqHiEs7nnVDoTp7G2hXsr18vutC szl234iX_0zM3S32pi7nbOn1Sm0VinHqUp1DqcVilG0PbKFk1oi5cOX4eCxh 9ksINBAjx7dzvWjluzpCeQQNhPmQKfchedTqD069DPRMw
Received: from [150.101.221.237] by web142505.mail.bf1.yahoo.com via HTTP; Wed, 23 Oct 2013 12:09:41 PDT
X-Rocket-MIMEInfo: 002.001, CgoKCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiBGcm9tOiBPbGUgVHJvYW4gKG90cm9hbikgPG90cm9hbkBjaXNjby5jb20.Cj4gVG86IE1hcmsgWlpaIFNtaXRoIDxtYXJrenp6c21pdGhAeWFob28uY29tLmF1Pgo.IENjOiBNaWthZWwgQWJyYWhhbXNzb24gPHN3bWlrZUBzd20ucHAuc2U.OyAidjZvcHNAaWV0Zi5vcmciIDx2Nm9wc0BpZXRmLm9yZz47ICJkcmFmdC1saXUtYm9uaWNhLXY2b3BzLWRoY3B2Ni1zbGFhYy1wcm9ibGVtQHRvb2xzLmlldGYub3JnIiA8ZHJhZnQtbGl1LWJvbmljYS12Nm8BMAEBAQE-
X-Mailer: YahooMailWebService/0.8.160.587
References: <201310211245.r9LCj0B29668@ftpeng-update.cisco.com> <alpine.DEB.2.02.1310211454090.26825@uplift.swm.pp.se> <8AE0F17B87264D4CAC7DE0AA6C406F453D7CC14B@nkgeml506-mbx.china.huawei.com> <alpine.DEB.2.02.1310221511520.8663@uplift.swm.pp.se> <1382469405.56346.YahooMailNeo@web142504.mail.bf1.yahoo.com> <alpine.DEB.2.02.1310230533340.1838@uplift.swm.pp.se> <1382519509.39565.YahooMailNeo@web142502.mail.bf1.yahoo.com> <55F2A998-0417-4C19-B248-AA2A80EBF29C@cisco.com>
Message-ID: <1382555381.11936.YahooMailNeo@web142505.mail.bf1.yahoo.com>
Date: Wed, 23 Oct 2013 12:09:41 -0700 (PDT)
From: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
To: "Ole Troan \(otroan\)" <otroan@cisco.com>
In-Reply-To: <55F2A998-0417-4C19-B248-AA2A80EBF29C@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" <draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org>
Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Oct 2013 19:09:52 -0000




----- Original Message -----
> From: Ole Troan (otroan) <otroan@cisco.com>
> To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
> Cc: Mikael Abrahamsson <swmike@swm.pp.se>se>; "v6ops@ietf.org" <v6ops@ietf.org>rg>; "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" <draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org>
> Sent: Wednesday, 23 October 2013 8:21 PM
> Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem
> 
> A single address does not have a mask. 
> DHCP gives out addresses, not prefixes that can be used for onlink 
> determination. 
> 

That makes it clearer. There was no need for Mikael to use "/128", which to me implied that the DHCPv6 server conveyed a prefix length when handing out addresses, and that a specific /128 prefix length mattered to Mikael, which is why I asked the question.

Thanks,
Mark.

> Cheers,
> Ole
> 
>>  On 23 Oct 2013, at 11:11, Mark ZZZ Smith <markzzzsmith@yahoo.com.au> 
> wrote:
>> 
>>  Hi,
>> 
>> 
>>  ----- Original Message -----
>>>  From: Mikael Abrahamsson <swmike@swm.pp.se>
>>>  To: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
>>>  Cc: Liubing (Leo) <leo.liubing@huawei.com>om>; 
> "v6ops@ietf.org" <v6ops@ietf.org>rg>; 
> "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" 
> <draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org>
>>>  Sent: Wednesday, 23 October 2013 2:40 PM
>>>  Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: 
> draft-liu-bonica-v6ops-dhcpv6-slaac-problem
>>> 
>>>>  On Tue, 22 Oct 2013, Mark ZZZ Smith wrote:
>>>> 
>>>>    Is this saying that the prefix length of the address on host is 
> /128?
>>> 
>>>  A single address is always a /128. This /128 can be part of an on-link 
>>>  other network, or it isn't.
>> 
>>  My question was more specificaly about you using "/128", rather 
> than "an address" or "a single address", because I wondered 
> if the DHCPv6 server supplies a /128 prefix length and the host configures a 
> /128 prefix length on the address.
>> 
>>  As you say below, address prefix length doesn't indicate on-link or 
> off-link presence. So I'd expect a DHCPv6 server to hand out single IPv6 
> addresses with a /64 prefix length, as I think that would be more consistent and 
> more expected when the subnet's prefix length is /64.
>> 
>>  For somebody with a IPv4 experience, who wasn't aware an IPv6 prefix 
> length doesn't indicate on-link presence, I think the use of a /128 prefix 
> length in this scenario would imply that prefix length does indicate on-link 
> presence. Somewhat pedantic perhaps, however I think anything that may give 
> false indications of IPv6's behaviour, when it is different to IPv4's, 
> is better to avoid.
>> 
>> 
>>  Regards,
>>  Mark.
>> 
>>>>    If that is the case, as the prefix length in doesn't indicate 
> on-link
>>>  or 
>>>>    off-link status (as RA PIOs do), is there any specific reason for 
> the 
>>>>    prefix length the DHCPv6 server hands out to be /128 instead of 
> the 
>>>>    subnet's prefix length of /64? 
>>> 
>>>  The DHCPv6 server always hands out /128. This /128 can be within a 
> subnet 
>>>  advertised in RA, or it can be outside of it. The host doesn't 
> care. When 
>>>  a subnet is being advertised in RA you get a network route pointing to 
> the 
>>>  interface without an IPv6 address as next-hop.
>>> 
>>>  So it's perfectly achievable today (and it works) to have the 
> following:
>>> 
>>>  Host gets 2001:db8:fff::1/128 from dhcp
>>>  host gets on-link 2001:db8:1::/64 from RA and creates a route towards 
> the 
>>>  interface for this, but doesn't do SLAAC because A=0.
>>>  Host gets default route from router and installs it.
>>> 
>>>  Now, the *router* needs to understand that 2001:db8:fff::1/128 is 
> on-link, 
>>>  but no other hosts on the network does not.
>>> 
>>>  So what networks are being announced in RA is completely decoupled from 
> 
>>>  addresses handed out by DHCPv6 IA_NA. It's perfectly valid to hand 
> out a 
>>>  /128 and then have no on-link prefixes at all, or have some with A=0.
>>> 
>>> 
>>>  -- 
>>>  Mikael Abrahamsson    email: swmike@swm.pp.se
>>  _______________________________________________
>>  v6ops mailing list
> 
>>  v6ops@ietf.org
>>  https://www.ietf.org/mailman/listinfo/v6ops
>