Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: Forgot one [Was: RFC 5889)

Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr> Wed, 11 August 2010 12:08 UTC

Return-Path: <emmanuel.baccelli@gmail.com>
X-Original-To: autoconf@core3.amsl.com
Delivered-To: autoconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D33A3A6829 for <autoconf@core3.amsl.com>; Wed, 11 Aug 2010 05:08:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.976
X-Spam-Level:
X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hUxQYbtLxwy for <autoconf@core3.amsl.com>; Wed, 11 Aug 2010 05:08:49 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id D2E3B3A6828 for <autoconf@ietf.org>; Wed, 11 Aug 2010 05:08:48 -0700 (PDT)
Received: by eyb7 with SMTP id 7so4920173eyb.31 for <autoconf@ietf.org>; Wed, 11 Aug 2010 05:09:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=d/GDZggb7Ra0qvKcWUaxeZY9/pJZM4jz089cBYhIB0M=; b=YSLWTgy3IIMOBCWLTo+/lNW3b3fIOJ68ub8yUzxQGRbPGb6p2k+ZdybEelkhClzGHG uNlRQzXl1ngxZ8HgqjjhxacNOYsxkRH66ZVQ/sNydrmmRSAsOvVxKnbik5msu3c7hiNT HnEb0RyOP+MCAZFBnZrT3FmnwNeLIFiN5S58o=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=Txa1fF4YnUSKQcCRnt5uREDrfFt1NcNe+jApP8501iQ8tqGVLNLzkQkEeY72rZPg3r Eg0wnrx8hZLBaQ6GenVC1bUbLFe98yqTd5iCQpUDoTwIgY3WGpHQydv9fi1QlQt8ZOoU lX1Ie5fobBdv7pPRAkEncbMIaAqHXOT02C7wU=
Received: by 10.213.20.132 with SMTP id f4mr15071033ebb.19.1281528564228; Wed, 11 Aug 2010 05:09:24 -0700 (PDT)
MIME-Version: 1.0
Sender: emmanuel.baccelli@gmail.com
Received: by 10.14.37.4 with HTTP; Wed, 11 Aug 2010 05:01:17 -0700 (PDT)
In-Reply-To: <E21BA9FD-4715-4DA8-9586-9380126763E2@gmail.com>
References: <4C528979.7010006@oracle.com> <E21BA9FD-4715-4DA8-9586-9380126763E2@gmail.com>
From: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>
Date: Wed, 11 Aug 2010 14:01:17 +0200
X-Google-Sender-Auth: fnhtXlSByal_6G_DGAEU9X0iLrk
Message-ID: <AANLkTimKQqB3GzWL9VqWNcnvZjv0xW=-TYKDs67GxY4e@mail.gmail.com>
To: Ryuji Wakikawa <ryuji.wakikawa@gmail.com>
Content-Type: multipart/alternative; boundary="0015174c409ad7246b048d8b1e0e"
Cc: "autoconf@ietf.org autoconf@ietf.org" <autoconf@ietf.org>, Autoconf Chairs <autoconf-chairs@tools.ietf.org>, Ralph Droms <rdroms@cisco.com>
Subject: Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd: Forgot one [Was: RFC 5889)
X-BeenThere: autoconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/autoconf>
List-Post: <mailto:autoconf@ietf.org>
List-Help: <mailto:autoconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Aug 2010 12:08:50 -0000

Hi Ryuji,

I support the proposed changes, although I'm not particularly keen on
altering the title (actually I have not noticed anybody who is, I just
noticed some people who oppose it ;) and I would prefer to simply skip the
last sentence about EUI-64.

Cheers

Emmanuel


On Tue, Aug 3, 2010 at 2:14 AM, Ryuji Wakikawa <ryuji.wakikawa@gmail.com>wrote:

> Hello all,
>
> At the IETF78 meeting, we had the rough consensus to adapt
> the Erik's modification for RFC5889 in the room.
>
> To confirm our consensus on the list, we ask the WG consensus call
> for adaption of Erik's modification for RFC5889.
>
> The detailed modifications can be found at the attached email below. Thanks
> Erik.
>
> Please vote for your opinion before "Aug 9th 12:00PM (PST)".
> If you have any objections, please give us clear reason and propose your
> text.
>
> thanks in advance,
> Thomas, ryuji
>
>
>
>
> Begin forwarded message:
>
> > From: Erik Nordmark <erik.nordmark@oracle.com>
> > Date: 2010/07/30 01:12:41GMT-07:00
> > To: autoconf@ietf.org
> > Subject: Re: [Autoconf] Forgot one [Was: RFC 5889
> >
> >
> > Please double-check this, but I think it has all the list of changes that
> Jari said verbally.
> >
> >  Erik
> >
> > ----
> >
> > Change the title
> > FROM
> >                IP Addressing Model in Ad Hoc Networks
> > TO
> >                A Router Addressing Model in Ad Hoc Networks
> >
> > In section 5:
> > OLD:
> > Routing protocols running on a router may exhibit different
> > requirements for uniqueness of interface addresses; some have no such
> > requirements, others have requirements ranging from local uniqueness
> > only, to uniqueness within, at least, the routing domain (as defined
> > in [RFC1136]).
> >
> > Configuring an IP address that is unique within the routing domain
> > satisfies the less stringent uniqueness requirements of local
> > uniqueness, while also enabling protocols which have the most
> > stringent requirements of uniqueness within the routing domain.  This
> > suggests the following principle:
> >
> > o  an IP address assigned to an interface that connects to a link
> >   with undetermined connectivity properties should be unique, at
> >   least within the routing domain.
> > NEW:
> > Routing protocols running on a router may exhibit different
> > requirements for uniqueness of interface addresses; some have no such
> > requirements, others have requirements ranging from local uniqueness
> > only, to uniqueness within, at least, the routing domain (as defined
> > in [RFC1136]).
> > Routing protocols that do not require unique IP addresses within the
> > routing domain utilize a separate unique identifier within the routing
> > protocol itself; such identifiers could be based on factory assignment
> > or configuration.
> >
> > Nevertheless, configuring an IP address that is unique within the routing
> > domain satisfies the less stringent uniqueness requirements of local
> > uniqueness, while also enabling protocols which have the most
> > stringent requirements of uniqueness within the routing domain.  As a
> result, the following principle allows for IP autoconfiguration to
> > apply to the widest array of routing protocols:
> >
> > o  an IP address assigned to an interface that connects to a link
> >   with undetermined connectivity properties should be unique, at
> >   least within the routing domain.
> >
> > In Section 6.1:
> > OLD:
> > o  There is no mechanism to ensure that IPv6 link-local addresses are
> >   unique across multiple links, hence they cannot be used to
> >   reliably identify routers (it is often desirable to identify a
> >   router with an IP address).
> > NEW:
> > o  In general there is no mechanism to ensure that IPv6 link-local
> >   addresses are unique across multiple links, however link-local
> >   addresses using an IID that are of the modified EUI-64 form are
> >   globally unique. Thus if link-local addresses are used to reliably
> >   identify routers then they must be of the modified EUI-64 form.
> >
> > ---
> > _______________________________________________
> > Autoconf mailing list
> > Autoconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/autoconf
>
> _______________________________________________
> Autoconf mailing list
> Autoconf@ietf.org
> https://www.ietf.org/mailman/listinfo/autoconf
>