Re: [Autoconf] new charter

Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Sat, 28 February 2009 13:43 UTC

Return-Path: <cjbc@it.uc3m.es>
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 E9EA428C104 for <autoconf@core3.amsl.com>; Sat, 28 Feb 2009 05:43:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.101
X-Spam-Level:
X-Spam-Status: No, score=-4.101 tagged_above=-999 required=5 tests=[AWL=-1.598, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, J_CHICKENPOX_54=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_56=0.6, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
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 23bwgB9OEXK7 for <autoconf@core3.amsl.com>; Sat, 28 Feb 2009 05:43:26 -0800 (PST)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id AFCED3A69E0 for <autoconf@ietf.org>; Sat, 28 Feb 2009 05:43:25 -0800 (PST)
Received: from [192.168.1.209] (213.37.82.74.static.user.ono.com [213.37.82.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 843FCB4D48F; Sat, 28 Feb 2009 14:43:47 +0100 (CET)
From: Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es>
To: Teco Boot <teco@inf-net.nl>
In-Reply-To: <006801c998fd$06c5bd60$14513820$@nl>
References: <499F0BA7.90501@piuha.net> <7E8A76F7-2CE0-463A-8EE8-8877C46B4715@gmail.com> <49A6D436.7020505@gmail.com> <000001c99845$1dc56190$595024b0$@nl> <49A6F125.40400@gmail.com> <1235680887.4585.5.camel@localhost> <49A7BB89.5040807@gmail.com> <003901c998cb$42b71e90$c8255bb0$@nl> <49A7E97A.2010503@gmail.com> <006801c998fd$06c5bd60$14513820$@nl>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-zKizSSc/tvdYOWw3T8XP"
Organization: Universidad Carlos III de Madrid
Date: Sat, 28 Feb 2009 14:43:42 +0100
Message-Id: <1235828622.6096.25.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16490.007
Cc: autoconf@ietf.org
Subject: Re: [Autoconf] new charter
X-BeenThere: autoconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: cjbc@it.uc3m.es
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: Sat, 28 Feb 2009 13:43:27 -0000

Hi Teco,

El vie, 27-02-2009 a las 18:01 +0100, Teco Boot escribió:
> Inline.
> 
> |-----Oorspronkelijk bericht-----
> |Van: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]
> |Verzonden: vrijdag 27 februari 2009 14:24
> |Aan: Teco Boot
> |CC: 'Alexandru Petrescu'; autoconf@ietf.org
> |Onderwerp: Re: [Autoconf] new charter
> |
> |Teco Boot a écrit :
> |> Hi Alex,
> |>
> |> Let's try to be accurate:
> |>
> |> [skip]
> |> |Sorry... in the picture above the addresses are also /128.  It was an
> |> |abbreviation for me to show only 2001:db8:1::1/64 assigned to Host1.
> |> |The full notation should have been 2001:db8:1::/64 prefix and
> |> |2001:db8:1::1/128.  Would the following picture satisfy the need for
> |> |/128 addresses?:
> |>
> |> When prefix::/64 is assigned to a host, it configures a /64 address
> |and not
> |> an /128 address.
> |
> |I'm not sure I understand.
> |
> |The prefix::/64 is typically assigned to a link, not to a host.  If a
> |host is connected to that link then it configures a /128 address and a
> |/64 subnet prefix, both "128" and "64" numbers are visible in its
> |tables.
> |
> |I don't understand why the need for /128 prefixes, why isn't the above
> |/64-prefix-and-/128address not sufficient?
> 
> This is interesting. I meant generating an address in the /64 prefix.
> I don't know what is specified in RFCs. I checked behavior on Vista, 
> Linux and IOS: 
>   o Linux (debian lenny) adds a /128 prefix in the routing table, to 
>     the loopback interface, similar to what I propose in my addressing 
>     model mail. It also adds a /64 address-prefix to the Ethernet interface
>     this is a bit weird, as two interfaces has the same address configured.

	You mean the /64 for the link local addresses? this is not weird, they
have scope of a link, so there can perfectly be the same address on
different interfaces.

> 
>   o Vista assigns addresses to the Ethernet interface (in my case),
>     and adds /128 prefixes in the routing table. Vista also adds the 
>     /64 in the routing table.
>   o IOS behavior is as Vista, addresses to interfaces and /128 in 
>     routing table.
> 
> Details on Linux behavior: the /64 are on Ethernet (eth0) and the /128 
> are on loopback (lo).
> 
> # ifconfig lo | egrep 'inet6|encap'
> lo        Link encap:Local Loopback  
>           inet6 addr: ::1/128 Scope:Host
> # netstat -6rn | grep 128
> ::1/128                        ::       Un   0   1    17 lo
> 2001:db8:1:0:20c:29ff:fee3:bdf5/128 ::  Un   0   1    11 lo
> fe80::20c:29ff:fee3:bdf5/128   ::       Un   0   1     3 lo
> fe80::20c:29ff:fee3:bdff/128   ::       Un   0   1     0 lo
> 
> # ifconfig eth0 | egrep 'inet6|encap'
> eth0      Link encap:Ethernet  HWaddr 00:0c:29:e3:bd:f5  
>           inet6 addr: 2001:db8:1:0:20c:29ff:fee3:bdf5/64 Scope:Global
>           inet6 addr: fe80::20c:29ff:fee3:bdf5/64 Scope:Link
> # netstat -6rn | grep 64 
> 2001:db8:1::/64                ::       UAe  256 0    15 eth0
> fe80::/64                      ::       U    256 0     0 eth0
> fe80::/64                      ::       U    256 0     0 eth1
> 

Just a suggestion (OT to this mailing list): it's better to use the
'ip' (iproute) command (ifconfig, route and netstat are deprecated, as
far as I know since 2.4 kernels). Besides, 'ipi command is far easier to
use: 'ip -6 addr', 'ip -6 ro'

Thanks,

Carlos

> 
> Conclusion: I was wrong with my statement. Linux behaves as I mentioned, 
> other IPv6 stacks have different characteristics.
> 
> 
> 
> 
> 
> |> Routers may generate a /128 prefix-address, and advertize this in the
> |> routing domain.
> |
> |A host-based route propagated and deleted throughout a domain?  I don't
> |see the necessity of doing so.  Assuming the routers are mobile within
> |25m ranges then they wouldn't need to change their addresses, thus no
> |need to propagate host-based routes.
> 
> If the /128 is not propagated, there will be no multi-hop network. In a
> MANET, I expect nodes to run a MANET Routing protocol and forward packets.
> In ad hoc networks, one (you ?) would say nodes could be hosts or Mobile
> Routers acting as hosts. 
> 
> 
> |Do you agree we consider routers mobile only within 25m ranges?
> 
> Absolutely not. For me, 25km is a reasonable distance! Just 10^3 times the
> distance and 10^6 times the power per bit (single hop) or 10^3 times the
> power per bit if multi-hop is enabled (and 1000 intermediate nodes....).
> Just physical laws here.
> 
> 
> Teco.
> 
> 
> |Alex
> |
> |> Some mechanisms should make sure the /128 routing prefix is unique, if
> |> required. It is not required if the prefix is meant as anycast
> |address,
> |> routers may use "duplicate prefixes" if this is useful. I think
> |anycast is
> |> out-of-scope for [Autoconf], but we should be careful when specifying
> |"MUST"
> |> for prefix uniqueness. We should use "SHOULD" instead.
> |>
> |> Teco.
> |>
> |>
> |>
> |>
> 
> 
> _______________________________________________
> Autoconf mailing list
> Autoconf@ietf.org
> https://www.ietf.org/mailman/listinfo/autoconf
-- 
 Carlos Jesús Bernardos Cano     http://www.netcoms.net
 GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
        Deployment Experiences on Vehicular networks
                  http://www.weedev.org/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++