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

["Templin, Fred L" <[e-mail]>]

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
[e-mail]

> -----Original Message-----
> From: Bound, Jim [mailto:[e-mail]] 
> Sent: Monday, February 19, 2007 7:08 AM
> To: Templin, Fred L; [e-mail]
> Cc: [e-mail]; Yi, Seung; Chakeres, Ian D; 
> [e-mail]; [e-mail]
> 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:[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