RE: [Autoconf] RE: [Manemo] FW: I-DACTION:draft-templin-autoconf-dhcp-05.txt

["Bound, Jim" <[e-mail]>]

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:[e-mail]] 
> Sent: Saturday, February 17, 2007 12:08 PM
> To: [e-mail]
> Cc: [e-mail]; Yi, Seung; Chakeres, Ian D; 
> [e-mail]; [e-mail]
> 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
> [e-mail]
> 
> > 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 [e-mail]
> > > 
> > > 
> > > -----Original Message----- From: [e-mail] 
> > > [mailto:[e-mail]] Sent: Thursday, 
> February 08, 2007 
> > > 3:50 PM To: [e-mail] 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  
> > > [e-mail] 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: [e-mail]. 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 
> > > [e-mail] http://www.mobileip.jp/mailman/listinfo/manemo
> > 
> > 
> 
> _______________________________________________
> Autoconf mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/autoconf
> 

_______________________________________________
Autoconf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/autoconf