Re: [Autoconf] Re: Some Thoughts on Problem Statement.

"Ulrich Herberg" <ulrich.herberg@polytechnique.edu> Tue, 27 November 2007 08:34 UTC

Return-path: <autoconf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwvtM-0001Ss-LH; Tue, 27 Nov 2007 03:34:04 -0500
Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IwvtL-0001Se-1t for autoconf-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 03:34:03 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwvtH-0001Ro-Qa for autoconf@ietf.org; Tue, 27 Nov 2007 03:33:59 -0500
Received: from wr-out-0506.google.com ([64.233.184.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwvtD-0002Wf-Sr for autoconf@ietf.org; Tue, 27 Nov 2007 03:33:59 -0500
Received: by wr-out-0506.google.com with SMTP id 68so695164wra for <autoconf@ietf.org>; Tue, 27 Nov 2007 00:33:55 -0800 (PST)
Received: by 10.78.204.1 with SMTP id b1mr3812173hug.1196152433918; Tue, 27 Nov 2007 00:33:53 -0800 (PST)
Received: by 10.78.170.19 with HTTP; Tue, 27 Nov 2007 00:33:53 -0800 (PST)
Message-ID: <25c114b90711270033k1a05e8b5ld3547e20949521ea@mail.gmail.com>
Date: Tue, 27 Nov 2007 09:33:53 +0100
From: Ulrich Herberg <ulrich.herberg@polytechnique.edu>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Subject: Re: [Autoconf] Re: Some Thoughts on Problem Statement.
In-Reply-To: <474AE536.8070400@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <e9c684940711230826p323a818fg114da3c710841f2@mail.gmail.com> <474AE536.8070400@gmail.com>
X-Google-Sender-Auth: 6dc408da9390f8cd
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92
Cc: autoconf@ietf.org, Shubhranshu <shubranshu@gmail.com>
X-BeenThere: autoconf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/autoconf>
List-Post: <mailto:autoconf@ietf.org>
List-Help: <mailto:autoconf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe>
Errors-To: autoconf-bounces@ietf.org

Hello Alexandru, hello Shubhranshu,

I also think that the text by Shubhranshu is very useful; some
comments inline...

On 11/26/07, Alexandru Petrescu <alexandru.petrescu@gmail.com> wrote:
> > A MANET router needs to configure an IPv6 prefix(es) on its host
> > interface and/or an IPv6 address on its loopback interface. Besides,
> > it needs to configure a /128 (or /32 in case of IPv4) and/or a link
> > local address on its MANET interface.
>
> I yet have to understand why MANET router has to configure a prefix on
> its loopback interface.  It's probably by proper definition of MANET -
> in that case, sorry, froget  it.

To my understanding, this loopback interface serves as a "logical"
host on the MANET node (correct me if I am wrong). As in real-life
scenarios, most of the time a mobile node will not only be a router
but some mobile device (PDA, laptop, ...), it will run some
applications on it (e.g. web browser). The loopback interface
definitely needs to be explained in the manetarch draft as I am also
not sure whether my explanation is correct.

Another reason of using the loopback interface could be to not
attribute an IP address to the MANET interface but using unnumbered
interfaces (as specified by Cisco).

> On another hand, if a Router has a prefix in its config file and looks
> for a way to configure a address from that prefix on one of its real
> interfaces, then one possibility is to derive itself an address from its
> Ethernet MAC address, attach it to that prefix and then 'ifconfig' and
> 'route add'.  Another alternative is to send RAs on its loopback
> interface with that prefix, and let the IPv6 stack autoconfigure
> address, prefix and route as usual.  These are two choices.

I think that this is correct. While the first case is simpler, it
would mean changing the way of how a network interface is configured.
By the way, do you know how the loopback interface in for example
Linux is configured? That would be an interesting comparison. Sure, it
normally has ::1/128 as fixed address, but could one assign prefixes
to it using RA messages?

> > A MANET router may also configure a prefix shorter than /128 (or /32)
> > on its MANET interface provided prefix uniqueness is guaranteed
> > [MANET-Arch I-D]. MANET node needs to configure "MANET scope" address
> > to communicate among themselves. "MANET Scope" addresses are
> > currently not specified / standardized within / outside the IETF.
>
> Ok, I think "prefix uniqueness" is something not simple to define.
>
> I think comparing addresses /128 is simple because they're fixed length.
>
> Comparing a /128 address to a set of prefixes is also simple because we
> have the "longest prefix match".
>
> But comparing two prefixes has many other undefined possibilities.
>
> I think though a human administrator can easily plan an addressing
> architecture and static routing where prefixes are unique, store those
> in a set of files.

I think your concern is what happens if you compare two prefixes which
are shorter than /128. My guess is that you still have to check for
uniqueness of all 128 bits, as you we still talk about IP addresses
(not prefixes) on the MANET interface. (prefixes are only later
assigned on the egress interface of the router). However, the
following situation could appear: two MANET interfaces configured with
the following addresses:
  -- node A: a:b:c:d/64  (where each letter means 2 bytes)
  -- node B: a:b:c:d:e/64
The IP addresses are still unique, however, B would be in the subnet
of A. That's probably bad...

> Also, MANET Scope is somehting I need to understand better.  Is MANET
> Scope in any relationship with the existing scopes: link-local scope,
> global scope?  Is MANET Scope in some relationship with the scope of the
> all-manet-routers IP multicast group requested by manet-iana document?
>
> Is MANET scope in some relationship with the scopes of the following
> Ethernet MAC multicast addresses: 33::1 (all Ethernet hosts), 33::2 (all
> Ethernet routers), or other Ethernet MAC multicast group scopes?
>
> _some_ relationship?  _No_ relationship whatsoever?

I don't know... I do not think that there is a common agreement on
this term. The border between a MANET and the Internet using an ICP
might be understandable (even though it has also been remarked that
when a MANET is connected to the Internet, it is at that moment part
of the Internet). However, when two or more MANETs are in the direct
neighborhod and do not merge but instead add inter-MANET routes
between them using aggregation, the MANET scope is less evident for
me. If MANETs could for example use aggregation for different
hierarchical levels of prefixes, it might be difficult to say: "The
MANET ends _here_".

> > As mentioned above, there are three interfaces under consideration
> > for address  auto-configuration. Further detail related to these
> > address auto-configuration is provided below:
> >
> > 1) Configuration of loopback interface:
> >
> > It is possible that a MANET Router does not have any host attached to
> >  its network interface or it has only MANET interface which can be
> > used for intra-manet communication. In the absence of any "external"
> > host, MANET router may configure an IPv6 global address on its
> > loopback interface. The traditional auto configuration procedure such
> > as RFC 2462, can be used for this purpose provided the MANET router
> > has been assigned a suitable prefix. As usual, this interface is
> > expected to send multicast RA/RS messages. However, in this case,
> > these messages would be limited to the Router's loopback interface
> > only.
>
> This makes me think the MANET Router doesn't communicate  to anybody
> else than self.  Its (real) network interface has no hosts attached to
> it (has Routers attached to it?), MANET interface is virtual and
> loopback interface leads to self.  I may misunderstand you.
>
> Also, I will have to read other documents to understand why the loopback
> interface needs to have address/prefix. If I understand that then maybe
> I can understand the above as well.

Same for me :-) That's why a description of the loopback interface
would be nice in the manetarch draft.

>
> > 2) Configuration of MANET interface:
> >
> > MANET Router uses this interface to communicate with other MANET
> > Routers. MANET routing and other MANET specific protocols are
> > expected to run on this interface. This interface SHOULD be
> > configured with a link local address and/or a /128 (in case of IPv6)
> > or with /32 (in case of IPv4) address. MANET interface may also use
> > smaller prefix provided the prefix uniqueness is guaranteed.
> > Configuration of MANET interface with a link local address and/or a
> > /128 address is straightforward, as it can use existing mechanisms,
> > except the issue of address uniqueness test over "multi-hop network".
>
> I agree.
>
> If the MANET interface is virtual then I think there's no standard for
> defining link-local address on a virtual interface.  People do different
> things for these, sometimes random.

I don't understand this. Why do you say it is a virtual interface? I
thought that it is a real interface on a mobile node, and that it is
the only interface on the node which knows and cares about MANET
characteristics (e.g. by running a MANET routing protocol on it).

>
> I think a good virtual interface (MANET interface or other) would need:
> -a link-local address (/128 length).
> -a link-local prefix (the fe80 /10 length).
> -maybe a global subnet prefix with global address.
> -maybe another global subnet prefix with a global address.
>
> I think you mean that "MANET Interface" means a sort of a label we put
> on a real network interface.  Something that in some contexts some
> people call "egress interface", or "ingress interface".
>
> So, if you mean MANET Interface is a real interface, then we may already
> have a means to form a link-local address for it.

Ah, know I think I understood you. So you mean that a MANET interface
is virtual in the sense that it only a "caption" somehow for a real
(e.g. 802.11) network interface, do you? Well, to my understanding it
probably makes thinks more complicate to talk about a virtual
interface instead of a "real" MANET interface

Regards,
Ulrich


_______________________________________________
Autoconf mailing list
Autoconf@ietf.org
https://www1.ietf.org/mailman/listinfo/autoconf