[manet] RE: [Autoconf] RE: [Manemo] FW: I-DACTION:draft-templin-autoconf-dhcp-05.txt
"Templin, Fred L" <Fred.L.Templin@boeing.com> Mon, 19 February 2007 15:18 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJAHJ-0008Ux-B7; Mon, 19 Feb 2007 10:18:09 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJAHH-0008Uk-Ng; Mon, 19 Feb 2007 10:18:07 -0500
Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJAHD-00046u-PF; Mon, 19 Feb 2007 10:18:07 -0500
Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l1JFHbhF008551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Feb 2007 09:17:38 -0600 (CST)
Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l1JFHbcP004194; Mon, 19 Feb 2007 07:17:37 -0800 (PST)
Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l1JFHWW3004075; Mon, 19 Feb 2007 07:17:36 -0800 (PST)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Feb 2007 07:17:36 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 19 Feb 2007 07:17:35 -0800
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017746F7@XCH-NW-7V2.nw.nos.boeing.com>
In-Reply-To: <816DD9299957E547B5D758D7F977D6DC0163A44A@tayexc14.americas.cpqcorp.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Autoconf] RE: [Manemo] FW: I-DACTION:draft-templin-autoconf-dhcp-05.txt
Thread-Index: AcdSkJtfO/3YvJqwRWOtv5GG7YGNuwAFFFuAAGQiKGAAALZKwA==
References: <39C363776A4E8C4A94691D2BD9D1C9A101774696@XCH-NW-7V2.nw.nos.boeing.com><45D6F741.7000506@motorola.com> <39C363776A4E8C4A94691D2BD9D1C9A1017746F4@XCH-NW-7V2.nw.nos.boeing.com> <816DD9299957E547B5D758D7F977D6DC0163A44A@tayexc14.americas.cpqcorp.net>
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Jim.Bound@hp.com, alexandru.petrescu@motorola.com
X-OriginalArrivalTime: 19 Feb 2007 15:17:36.0169 (UTC) FILETIME=[15F67190:01C75439]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bd8a74b81c71f965ca7918b90d1c49c0
Cc: autoconf@ietf.org, manemo@mobileip.jp, "Chakeres, Ian D" <ian.d.chakeres@boeing.com>, manet@ietf.org, "Yi, Seung" <Seung.Yi@boeing.com>
Subject: [manet] RE: [Autoconf] RE: [Manemo] FW: I-DACTION:draft-templin-autoconf-dhcp-05.txt
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
Errors-To: manet-bounces@ietf.org
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 fred.l.templin@boeing.com > -----Original Message----- > From: Bound, Jim [mailto:Jim.Bound@hp.com] > Sent: Monday, February 19, 2007 7:08 AM > To: Templin, Fred L; alexandru.petrescu@motorola.com > Cc: autoconf@ietf.org; Yi, Seung; Chakeres, Ian D; > manet@ietf.org; manemo@mobileip.jp > 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:Fred.L.Templin@boeing.com] > > Sent: Saturday, February 17, 2007 12:08 PM > > To: alexandru.petrescu@motorola.com > > Cc: autoconf@ietf.org; Yi, Seung; Chakeres, Ian D; > > manet@ietf.org; manemo@mobileip.jp > > Subject: [Autoconf] RE: [Manemo] FW: > > I-DACTION:draft-templin-autoconf-dhcp-05.txt > > > > 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. > > > > > 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? > > > > 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 > > > unique on a link and aren't routable on the Internet either > > (just like > > > ULA which in addition may span several links). > > > > 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 > > fred.l.templin@boeing.com > > > > > 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 fred.l.templin@boeing.com > > > > > > > > > > > > -----Original Message----- From: Internet-Drafts@ietf.org > > > > [mailto:Internet-Drafts@ietf.org] Sent: Thursday, > > February 08, 2007 > > > > 3:50 PM To: i-d-announce@ietf.org 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 > > > > i-d-announce-request@ietf.org 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: mailserv@ietf.org. 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 > > > > Manemo@mobileip.jp > http://www.mobileip.jp/mailman/listinfo/manemo > > > > > > > > > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www1.ietf.org/mailman/listinfo/autoconf > > > _______________________________________________ manet mailing list manet@ietf.org https://www1.ietf.org/mailman/listinfo/manet
- [manet] Re: [Manemo] FW: I-D ACTION:draft-templin… Alexandru Petrescu
- [manet] RE: [Manemo] FW: I-D ACTION:draft-templin… Templin, Fred L
- [manet] RE: [Autoconf] RE: [Manemo] FW: I-DACTION… Templin, Fred L
- [manet] New ID's (was: FW: I-D ACTION:draft-templ… Templin, Fred L