Subject: [manet] Re: [Manemo] FW: I-D ACTION:draft-templin-autoconf-dhcp-05.txt

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 17 Feb 2007 13:38:25 +0100

Hi Fred, I quickly looked over the description below, not to the draft.

I was wondering one thing.

If the MRs connect all their egress on only one real subnet, would
configuring MLA addresses as link-local addresses be equivalent to using
ULA addresses cited in your description?  The link-local addresses are
unique on a link and aren't routable on the Internet either (just like
ULA which in addition may span several links).

Just one thought.

Alex

Templin, Fred L wrote:
> See below for the announcement of a MANET/AUTOCONF proposal. This
> proposal deals with both IPv4 and IPv6, and introduces a conceptual
> "virtual ethernet" to which all MANET Routers (MRs) in a MANET
> connect (see attachment). The virtual ethernet concept is not new,
> but provides an abstraction of a MANET that is useful for the
> purposes of address configuration, neighbor discovery, service
> discovery and duplicate address detection/avoidance. MRs can be
> considered to embody both a host and router function that communicate
> over a virtual p2p interface configured over the virtual ethernet.
> 
> In this model, a MANET router (MR) performs an initial MANET-Local
> Address (MLA) configuration to obtain an address that is unique
> within the MANET using a mechanism such as RFC4193 (for IPv6) or a
> suitable equivalent for IPv4. The MR next engages in the MANET
> routing protocol and discovers an identity for the virtual ethernet
> that abstracts the MANET. Next, if a MANET Border Router (MBR) is
> available, the MR configures global IP addresses and/or prefixes
> using standard services such as DHCP and IPv6 StateLess Address Auto-
>  Configuration (SLAAC) - although duplicate address detection 
> considerations for SLAAC are for further study.
> 
> MRs connect to the virtual ethernet via an interface that supports
> two access methods. The "raw" access method sends IP packets
> unencapsulated on the underlying MANET interface and may require
> multiple IP hops to span the MANET. The "cooked" access method sends
> IP packets encapsulated in an outer IP header such that all nodes
> connected to the MANET appear as 1-hop neighbors on the virtual
> ethernet.
> 
> MRs and MBRs may have aribtrarily-complex networks connected on
> downstream-attached links which they can provision with IP prefixes
> obtained by RFC3633 (for IPv6) or a suitable equivalent for IPv4. MRs
> can use MBRs as default routers to send packets to off-MANET
> destinations. MRs are "sites" unto themselves, and a MANET is
> therefore a "site of sites".
> 
> Comments/questions are welcome,
> 
> Fred [email-masked]
> 
> 
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] Sent: Thursday, February 08, 2007
> 3:50 PM To: [email-masked] Subject: I-D
> ACTION:draft-templin-autoconf-dhcp-05.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 
> Title		: MANET Autoconfiguration Author(s)	: F. Templin, et al. 
> Filename	: draft-templin-autoconf-dhcp-05.txt Pages		: 14 Date		:
> 2007-2-8  Mobile Ad-hoc Networks (MANETs) consist of routers
> operating over wireless links and may or may not connect to other
> networks.  Routers in MANETs that connect to the Internet must have a
> way to automatically provision globally routable and unique IP
> addresses/ prefixes.  This document specifies mechanisms for MANET 
> autoconfiguration.  Both IPv4 and IPv6 are discussed.
> 
> A URL for this Internet-Draft is: 
> http://www.ietf.org/internet-drafts/draft-templin-autoconf-dhcp-05.txt
> 
> 
> To remove yourself from the I-D Announcement list, send a message to
>  [email-masked] with the word unsubscribe in the body
> of the message. You can also visit
> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your
> subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then "get
> draft-templin-autoconf-dhcp-05.txt".
> 
> A list of Internet-Drafts directories can be found in 
> http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to: [email-masked]. In the body type: "FILE
> /internet-drafts/draft-templin-autoconf-dhcp-05.txt".  NOTE:	The mail
> server at ietf.org can return the document in MIME-encoded form by
> using the "mpack" utility.  To use this feature, insert the command
> "ENCODING mime" before the "FILE" command.  To decode the
> response(s), you will need "munpack" or a MIME-compliant mail reader.
> Different MIME-compliant mail readers exhibit different behavior,
> especially when dealing with "multipart" MIME messages (i.e.
> documents which have been split up into multiple messages), so check
> your local documentation on how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader 
> implementation to automatically retrieve the ASCII version of the 
> Internet-Draft.
> 
> 
> ------------------------------------------------------------------------
> 
> 
> _______________________________________________ Manemo mailing list 
> [email-masked] http://www.mobileip.jp/mailman/listinfo/manemo

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Templin, Fred L" <[email-masked]>
Date: Sat, 17 Feb 2007 09:08:07 -0800

Hi Alex, 

> Hi Fred, I quickly looked over the description below, not to the
draft.

OK, but you might find the draft an interesting read too.

> configuring MLA addresses as link-local addresses be 
> equivalent to using ULA addresses cited in your description?

Numbering the MR's MANET interfaces with link-local
addresses is still in-scope, and may be useful, e.g.,
for operating the standard IPv6 neighbor discovery
protocols. Link-locals may also be useful for numbering
virtual interfaces configured over the MANET interfaces
if an enhanced (aka, "cooked") view of the entire MANET
as a single shared link is desired - the draft notes this
as a valid abstraction. But, there are several reasons
why configuring ULA's may be beneficial.

First, we require a means for procuring unique MLAs
as identifiers that can be used to operate the MANET
routing protocol (and possibly also as locators for
packet forwarding, but link-local addresses are not
routeable). Also, in an unenhanced (aka, "raw") view,
a MR can be considered a site unto itself, and a MANET
therefore can be considered as a peering point between
sites. So, use of ULAs which were explicitly designed
for this purpose would seem a natural fit.

Secondly, MLAs should be either managed for uniqueness
or statistically unique to the greatest extent possible
to avoid duplication. One way of configuring statistically
unique link-local addresses is to use RFC3972 CGAs, which
gives 59(?) bits for random assignment. That's pretty good,
but configuring a ULA-plus-CGA would give 40+59 bits for
random assignment (much better) and a 'draft-jelger'-style
ULA-plus-CGA would give 56+59 bits (better still).

An additional reason for configuring ULAs is that portions
of the ULA prefix that the MR does not use to number its
MANET interfaces can be assigned on downstream-attached
interfaces. Since a MR can connect anything from a singleton
to a large enterprise network, having ample IPv6 prefix
space to assign to downstream-attached links could be
beneficial for many use cases.

But, none of these reasons preclude also using link-locals;
rather, link-locals and ULAs could be a "both/and" rather
than an "either/or" design alternative. 

> The link-local addresses are

The draft shows that in an unenhanced view, a MR (and its
downstream-attached links) is a "site" unto itself, and a
MANET is therefore a "site-of-sites" - so, an unenhanced
view of the MANET appears as a multilink peering point
between sites and this is the problem space that ULAs were
designed to address. The draft also shows that an enhanced
view sees the MANET as a single shared link that can use
link-local addresses as for any IP link - but, either or
both of the enhanced and unenhanced views are valid.
 
> Just one thought.

Thanks for it.

Fred
[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 19 Feb 2007 07:17:35 -0800

Hi Jim,

Thanks for the comments. I was getting ready to send out
an update that includes NA/NS as well as RA/RS, and based
on your comments can also relax the CGA language. Also,
DHCP may not be the only way, but DAD considerations for
SLAAC need further study.

I do not know whether the autoconf group will pick this
up as a wg item but will keep on with an individual sub
until told otherwise. Hope the work will be useful in
whatever context.

Fred

> -----Original Message-----
> From: Bound, Jim [mailto:[email-masked]] 
> Sent: Monday, February 19, 2007 7:08 AM
> To: Templin, Fred L; [email-masked]
> Cc: [email-masked]; Yi, Seung; Chakeres, Ian D; 
> [email-masked]; [email-masked]
> Subject: RE: [Autoconf] RE: [Manemo] FW: 
> I-DACTION:draft-templin-autoconf-dhcp-05.txt
> 
> Fred,
> 
> I have read your draft in depth once.  Still parsing.  Overall I think
> there is far to much state but that may be required in reality. Do not
> support your using CGA because to much IPR in real life for vendors to
> absorb (not just vendors here but SDR and Radio Net vendors you and I
> know all to well :--)), and there are no vendors coming on 
> board to use
> CGA at this time, but this is less of an IETF comment and more of a if
> this happens this won't work (e.g. CGA) IMHO. I think 
> optimization from
> manemo discussion perspective is also the use of NA and NS from node
> directly too in addition to RS and RA annoucements.  I do 
> like the DHCP
> enhancement but need to go through what that means and for an 
> ad hoc net
> having such a server will not always be possible (e.g. Fire Dept
> appearing on 911 scene, NATO bluelight or 101st airborne spec ops
> mission), but if enhanced with MESH network properties that is very
> possible.  But then we could put very small server on microprocessor I
> guess :--).  I like the term virtual ethernet but believe 
> subnetting is
> important for large ad hoc network, and think that would add value to
> the spec to distribute nodes across a large ad hoc network and manemo
> has ideas on this too that impact NEMO. I was not clear I could apply
> NEMO architecture to the autoconf architecture, which I think is
> important. ULA is fine for intra MLA communications but nodes will
> require global addresses to obtain peer-to-peer to external 
> networks via
> MBRs (my assumption here?) and that was not clear to me how 
> that happens
> in your draft but need to keep reading :--).
> 
> This is good work and manemo needs to parse what you and other authors
> are proposing in AUTOCONF.  I had to get off AUTOCONF list 
> did not find
> it useful is your work achieving consensus in the WG as working group
> draft item?  I don't mind jumping back into AUTOCONF list if they are
> moving forward with solution architectures as opposed to 
> brain storming?
> I believe one outcome of manemo is autoconfiguration thus 
> might require
> some collaboration with you and others within AUTOCONF or we come to
> AUTOCONF and roll up our sleeves?
> 
> Good work/spec as always Fred, and way better than what we have for
> today in real life for ad hoc nets.
> 
> Thanks
> /jim 
> 
> > -----Original Message-----
> > From: Templin, Fred L [mailto:[email-masked]] 
> > Sent: Saturday, February 17, 2007 12:08 PM
> > To: [email-masked]
> > Cc: [email-masked]; Yi, Seung; Chakeres, Ian D; 
> > [email-masked]; [email-masked]
> > Subject: [Autoconf] RE: [Manemo] FW: 
> > I-DACTION:draft-templin-autoconf-dhcp-05.txt
> > 
> > Hi Alex, 
> > 
> equivalent to 
> > > using ULA addresses cited in your description?
> > 
> > Numbering the MR's MANET interfaces with link-local addresses 
> > is still in-scope, and may be useful, e.g., for operating the 
> > standard IPv6 neighbor discovery protocols. Link-locals may 
> > also be useful for numbering virtual interfaces configured 
> > over the MANET interfaces if an enhanced (aka, "cooked") view 
> > of the entire MANET as a single shared link is desired - the 
> > draft notes this as a valid abstraction. But, there are 
> > several reasons why configuring ULA's may be beneficial.
> > 
> > First, we require a means for procuring unique MLAs as 
> > identifiers that can be used to operate the MANET routing 
> > protocol (and possibly also as locators for packet 
> > forwarding, but link-local addresses are not routeable). 
> > Also, in an unenhanced (aka, "raw") view, a MR can be 
> > considered a site unto itself, and a MANET therefore can be 
> > considered as a peering point between sites. So, use of ULAs 
> > which were explicitly designed for this purpose would seem a 
> > natural fit.
> > 
> > Secondly, MLAs should be either managed for uniqueness or 
> > statistically unique to the greatest extent possible to avoid 
> > duplication. One way of configuring statistically unique 
> > link-local addresses is to use RFC3972 CGAs, which gives 
> > 59(?) bits for random assignment. That's pretty good, but 
> > configuring a ULA-plus-CGA would give 40+59 bits for random 
> > assignment (much better) and a 'draft-jelger'-style 
> > An additional reason for configuring ULAs is that portions of 
> > the ULA prefix that the MR does not use to number its MANET 
> > interfaces can be assigned on downstream-attached interfaces. 
> > Since a MR can connect anything from a singleton to a large 
> > enterprise network, having ample IPv6 prefix space to assign 
> > to downstream-attached links could be beneficial for many use cases.
> > 
> > MANET is therefore a "site-of-sites" - so, an unenhanced view 
> > of the MANET appears as a multilink peering point between 
> > sites and this is the problem space that ULAs were designed 
> > to address. The draft also shows that an enhanced view sees 
> > the MANET as a single shared link that can use link-local 
> > addresses as for any IP link - but, either or both of the 
> > enhanced and unenhanced views are valid.
> >  
> > > Just one thought.
> > 
> > Thanks for it.
> > 
> > Fred
> > > > [email-masked] 
> http://www.mobileip.jp/mailman/listinfo/manemo
> > > 
> > > 
> > 
> > Autoconf mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/autoconf
> > 
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 21 Feb 2007 12:21:26 -0800

'draft-templin-autoconf-dhcp' has been updated based on
on- and off-list comments, and two derivative drafts have
also been published. The drafts are available as follows:

1) "MANET Autoconfiguration"
   The "combined" draft. This version supports both
   tunneling and non-tunneling access methods, and views
   the MANET as either a unified link or a multilink site
   (or "site-of-sites") based on the operational scenario:
 
http://www.ietf.org/internet-drafts/draft-templin-autoconf-dhcp-06.txt

2) "MANET Autoconfiguration over Virtual Ethernets"
   The "all-tunneling" draft. This version views the
   entire MANET as a unified shared link, or "virtual
   ethernet" using IP-in-IP tunneling: 
 
http://www.ietf.org/internet-drafts/draft-templin-autoconf-virtual-00.tx
t

3) "MANET Autoconfiguration over Multilink Sites"
   The "non-tunneling" draft. This version views the
   MANET as one or more multilink site(s). It proposes
   changes to neighbor discovery to support this view:
 
http://www.ietf.org/internet-drafts/draft-templin-autoconf-multilink-00.
txt

On- or off-list comments are welcome.

Fred