IETF Logo Mail Archive

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

Tomoyuki Sahara <sahara@surt.net> Thu, 15 August 2013 00:36 UTC

Return-Path: <tomosann@gmail.com>
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 68C2F21E80F2 for <v6ops@ietfa.amsl.com>; Wed, 14 Aug 2013 17:36:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.377
X-Spam-Level:
X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001]
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 HQwlS-sn35Or for <v6ops@ietfa.amsl.com>; Wed, 14 Aug 2013 17:36:58 -0700 (PDT)
Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id 6562E21E80F1 for <v6ops@ietf.org>; Wed, 14 Aug 2013 17:36:58 -0700 (PDT)
Received: by mail-wi0-f176.google.com with SMTP id f14so2622555wiw.3 for <v6ops@ietf.org>; Wed, 14 Aug 2013 17:36:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ly6dI5BJNMN72wC3wGJUkmjuifXYZZQPLvT8bjYrWuk=; b=rPoEB2o/3xtP108ZQEZAES1QQHW/yEOjcxbtqO06VDPKxdE8WX5kPya/Ia9W1DZIyT upwpW8tp2o4hxjLWkm3qG8NksyZ6eH5AxmtHa27ZU2WkRyBrM9m0/o6OMJVRfOQIM4zu j9MK8PNDTyzLZuVZKXreZLhhF2Dq4RLAvR2QGmtGTc9cWzSN9zOraGY6X4mVfXLj1ta+ pSQBxpbwNZoW/EdYnn868dLpcFj1cjHiXCVJhdbyms3YS+ybYW3KJ7XsVRg7Vus/QN57 XgYCXX5B5POmc686WPu3j08FNRUQfH1AzcvqnptveZD6O7pt7I+lDbWfOnSdOLEX1jOS mocw==
MIME-Version: 1.0
X-Received: by 10.194.109.68 with SMTP id hq4mr8352779wjb.12.1376527017380; Wed, 14 Aug 2013 17:36:57 -0700 (PDT)
Sender: tomosann@gmail.com
Received: by 10.194.19.42 with HTTP; Wed, 14 Aug 2013 17:36:57 -0700 (PDT)
In-Reply-To: <C8117298-601B-4943-A30C-9B565A6839A5@employees.org>
References: <fbee5f0026234d29a904f12fd992947f@BL2PR05MB068.namprd05.prod.outlook.com> <A4643DDE-568C-4D22-9EBA-4E0A18C983E6@employees.org> <9c7c6df802614956a26a282513b9cdd4@BL2PR05MB068.namprd05.prod.outlook.com> <C8117298-601B-4943-A30C-9B565A6839A5@employees.org>
Date: Thu, 15 Aug 2013 09:36:57 +0900
X-Google-Sender-Auth: GLd9KgIw2T0ciRlQAaKTwTcupIw
Message-ID: <CAH=tA5tWwEQy+cbQ3Xx=wPd+=0__vmhoiox9Os-0M=Q5NYoNUg@mail.gmail.com>
From: Tomoyuki Sahara <sahara@surt.net>
To: Ole Troan <otroan@employees.org>
Content-Type: multipart/alternative; boundary="089e0102e6dae5117704e3f1abdf"
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: Thu, 15 Aug 2013 00:36:59 -0000

NetBSD, a KAME-derived implementation, rejects incoming packets if one of
the source/destination addresses is in fe80:XXXX::/32 where XXXX != 0, and
we cannot send such packets in normal way on NetBSD.


Thanks,
Tomoyuki


On Wed, Aug 14, 2013 at 8:52 PM, Ole Troan <otroan@employees.org> wrote:

> Praveen,
>
> > Yeah that's is the problem here, RFC 4291 says it must be followed by 54
> bits of 0.
> > So many implementations which may put this constraint and in such case
> fe80:4888:208:ff8b:aa:21:0:2 may get discarded.
> > Should not we have one fix definition :).
>
> probably. the formation of the link-local address is link-specific. which
> link-layer do you see this problem?
> or is this manual configuration? I remember BSD used to put interface
> index in those bits, but I can't remember if they masked out those bits
> before putting packets on the wire.
>
> cheers,
> Ole
>
>
> >
> > Thanks & Regards
> > Praveen
> > Juniper Networks
> >
> >
> > -----Original Message-----
> > From: Ole Troan [mailto:otroan@employees.org]
> > Sent: Wednesday, August 14, 2013 5:01 PM
> > To: Praveen Chaudhary
> > Cc: v6ops@ietf.org
> > Subject: Re: [v6ops] RFC 4291, link local address defination
> >
> > 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
> >
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>

v2.23.0 | Report a Bug | By Email