Re: [v6ops] RFC 4291, link local address defination

Ole Troan <otroan@employees.org> Wed, 14 August 2013 11:31 UTC

Return-Path: <otroan@employees.org>
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 004CA11E81AB for <v6ops@ietfa.amsl.com>; Wed, 14 Aug 2013 04:31:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 2aog+kaetaZT for <v6ops@ietfa.amsl.com>; Wed, 14 Aug 2013 04:31:24 -0700 (PDT)
Received: from banjo.employees.org (banjo.employees.org [IPv6:2001:1868:205::19]) by ietfa.amsl.com (Postfix) with ESMTP id 8742111E8131 for <v6ops@ietf.org>; Wed, 14 Aug 2013 04:31:24 -0700 (PDT)
Received: from dhcp-lys02-vla252-10-147-116-13.cisco.com (173-38-208-169.cisco.com [173.38.208.169]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: otroan) by banjo.employees.org (Postfix) with ESMTPSA id 510485E9C; Wed, 14 Aug 2013 04:31:22 -0700 (PDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <fbee5f0026234d29a904f12fd992947f@BL2PR05MB068.namprd05.prod.outlook.com>
Date: Wed, 14 Aug 2013 13:31:19 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <A4643DDE-568C-4D22-9EBA-4E0A18C983E6@employees.org>
References: <fbee5f0026234d29a904f12fd992947f@BL2PR05MB068.namprd05.prod.outlook.com>
To: Praveen Chaudhary <cpraveen@juniper.net>
X-Mailer: Apple Mail (2.1508)
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] RFC 4291, link local address defination
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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, 14 Aug 2013 11:31:25 -0000

Praveen,

> As per RFC 4291 section 2.5.6 link local address are defines with the prefix fe80::/64, but many definition says even fe80::/10 qualifies as link local address.
> Like on wiki:
> “In the Internet Protocol Version 6 (IPv6), the address block fe80::/10 has been reserved for link-local unicast addressing.[2] The actual link local addresses are assigned with the prefix fe80::/64.[6][note 2] They may be assigned by automatic (stateless) or stateful e.g. manual) mechanisms.”
>  
> So if we have an address as below, which does not match prefix condition, how an implementation should treat them.
> fe80:4888:208:ff8b:aa:21:0:2
>  
> process as global address surely not ??, but as link local , it does not qualify. Kindly suggest.

FE80::/10 are reserved for link-local addresses, so they should be treated as link-locals in your implementation.

RFC4291 does not say that link-local addresses must be assigned from FE80::/64. it states that the prefix must be followed by 54 bits of 0. I agree that RFC4291 is a little ambiguous, and that the link-local address format should be defined like the global unicast address in section 2.5.4.

cheers,
Ole