RE: [Autoconf] comments to autoconf PS
mase <mase@ie.niigata-u.ac.jp> Mon, 03 December 2007 04:23 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 1Iz2q0-0003Qi-7V; Sun, 02 Dec 2007 23:23:20 -0500
Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Iz2py-0003QP-FE for autoconf-confirm+ok@megatron.ietf.org; Sun, 02 Dec 2007 23:23:18 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz2py-0003QB-3Y for autoconf@ietf.org; Sun, 02 Dec 2007 23:23:18 -0500
Received: from ccmail.cc.niigata-u.ac.jp ([133.35.23.1] helo=mxav01.cc.niigata-u.ac.jp) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iz2pv-0006dU-Kv for autoconf@ietf.org; Sun, 02 Dec 2007 23:23:17 -0500
Received: from mxav01.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id E754F4F6927 for <autoconf@ietf.org>; Mon, 3 Dec 2007 13:21:49 +0900 (JST)
Received: from mxav01.cc.niigata-u.ac.jp (localhost.localdomain [127.0.0.1]) by mxav01.cc.niigata-u.ac.jp (Postfix) with SMTP id 2C2834F6E4D for <autoconf@ietf.org>; Mon, 3 Dec 2007 13:04:37 +0900 (JST)
Received: (qmail 21821 invoked from network); 3 Dec 2007 13:04:36 +0900
Received: from unknown (HELO chamame.ie.niigata-u.ac.jp) (133.35.169.34) by mxav01.cc.niigata-u.ac.jp with SMTP; 3 Dec 2007 13:04:36 +0900
Received: (qmail 31325 invoked from network); 3 Dec 2007 13:04:36 +0900
Received: from unknown (HELO neccomputer.ie.niigata-u.ac.jp) (133.35.156.66) by chamame.ie.niigata-u.ac.jp with SMTP; 3 Dec 2007 13:04:36 +0900
Message-Id: <7.0.0.16.2.20071203125837.049dbf18@ie.niigata-u.ac.jp>
X-Mailer: QUALCOMM Windows Eudora Version 7J rev1.0
Date: Mon, 03 Dec 2007 13:04:42 +0900
To: Teco Boot <teco@inf-net.nl>, 'Alexandru Petrescu' <alexandru.petrescu@gmail.com>
From: mase <mase@ie.niigata-u.ac.jp>
Subject: RE: [Autoconf] comments to autoconf PS
In-Reply-To: <002301c8355e$639a3e70$2acebb50$@nl>
References: <B1CA250F-56DE-4F6E-89D4-E138AF9A4F8C@gmail.com> <7.0.0.16.2.20071202181233.04971348@ie.niigata-u.ac.jp> <475323CF.4080604@gmail.com> <7.0.0.16.2.20071203115230.04bda790@ie.niigata-u.ac.jp> <002301c8355e$639a3e70$2acebb50$@nl>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8d89ee9312a95de8ee48d1c94511f1bb
Cc: autoconf@ietf.org
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
Teco, Thank you for your comments. See in line. At 12:41 07/12/03, Teco Boot wrote: >Alex, Kenichi, > >I want to share my thoughts on link-local addresses and MLA with you. >I think link-locals are essential to IPv6. I do not understand why we have a >discussion on this. It is to be used for single hop communication, which is >also very applicable in MANET. Yes, but your former neighbor may be now out-of-transmission range and only communicated over multi-hop. Do you prefer to change your source/destination address from a link-local address to MLA? >I think MLA's are to be used for multi hop communications in the MANET. Right. >I agree ULA is an obvious candidate for MLA. Thanks, Kenichi >Teco. > > > -----Oorspronkelijk bericht----- > > Van: mase [mailto:mase@ie.niigata-u.ac.jp] > > Verzonden: maandag 3 december 2007 4:19 > > Aan: Alexandru Petrescu > > CC: autoconf@ietf.org > > Onderwerp: Re: [Autoconf] comments to autoconf PS > > > > Hi, Alex, > > > > At 06:29 07/12/03, Alexandru Petrescu wrote: > > >Hi mase, I have some opinions compared to your opinions, just some > > >discussion. I mainly agree with your suggestions to define addresses. > > > > Thanks. > > > > > > >mase wrote: > > >>Dear Ryuji, > > >>Thank you for your good comments. I agree that it is very > > >>important to make clear the scope when discussing autoconfiguration. > > >>With regard to the definition of MANET-local address, I am also > > >>not satisfied with the current definition. My proposal is as > > >>follows: MANET-local address an address having MANET-only scope > > >>that can be used to reach destinations in the MANET. All MANET > > >>interfaces have a MANET-local unicast address. > > > > > >But looks as it is a recursive definition? > > > > I have a suggestion of this style from the definition of link-local > > address of RFC4862. > > > > > > >When you say 'reach' do you mean the packet can be forwarded by a > > >intermediary router? > > > > Right. > > > > >Or is it that the packet is reaching the > > >destination without being forwarded by any router? > > > > > >Otherwise all packets have to reach their destinations. > > > > > >I'm tempted to define like this: > > > > > > MANET-local address > > > > > > An IPv6 link-local address. > > > > IMHO, this is not reasonalbe because forwarding is necessary to > > deliver packets to the destination, when source and destinatio > > MANET routers are not neighbors to each other. > > > > > > >This has pretty good semantics in my understanding. Opinions? > > > > > >>What is MANET is given in the manetarch document, so I think that the > > >> above definition is clear. In reality, I think that we may use > > >> unique local IPv6 unicast address for MANET-local address. > > > > > >I think ULA (Unique Local Addresses) don't have a scope related to the > > >link. I think a ULA addressed packet can reach a destination in a > > MANET > > >and sometimes it has to be forwarded to achieve that goal. > > > > > >You seem to say: > > > > > > MANET-local address > > > > > > A Unique Local Address (ULA RFCxxxx) > > > > > >If so, then I agree with you. > > > > I think that unique local address is a good candidate to be used in the > > MANET. > > > > > > >>I think that we cannot depend on link-local address, since MANET > > >>interface is SBI. > > > > > >I think it is strange to assume that a MANET uses _only_ SBI > > interfaces. > > > I think I can build a MANET that does _not_ use SBI interfaces. In > > >such a case I think IPv6 link-local addresses can be useful. > > > > As mentioned above, packet forwarding is necessary in general in a > > MANET. Thus link-local address is not appropriate as the > > source/destination address. > > > > Kenichi > > > > > > >Alex > > > > > >>In this context, I think that link-local address must not be used in > > >>MANET routing messages as well as data forwarding. This is my > > >>personal opinion at this time and need to discuss with the > > >>co-authors. Anyway, these points must be clearly described in the > > >>PS domument, as you suggested. Sorry for the only partial answer to > > your > > >>comments. > > >>Regards, Kenichi > > >>At 03:33 07/11/30, RYUJI WAKIKAWA wrote: > > >>>Hi Emmanuel and all, > > >>>First of all, i am sorry for my long silence, I needed some time to > > >>> recover from MANEMO wars in previous IETFs:-p > > >>>I finally reviewed this document and have a lot of comments, though > > >>> some of my comments may be overlapped with others or already > > >>> be discussed in ML. > > >>>To be honest, I am not such comfortable with this document > > >>>(except for the description of uniqueness issue which is well > > explained!). > > >>> There are so many unclear explanation. Let me explain the > > >>> general comments first and then detail my comments later. > > >>>- Do you assume DHCP and RA(NDP) as solutions of AUTOCONF? NDP does > > >>> not deal with prefix assignment. If you want to assign > > >>> prefix, stateless approach defined in RFC4862 is impossible, IMO. > > >>> A "stateful" mechanism using NDP might be possible if we can design > > so. > > >>>- Scope Issue There is nowhere to discuss which scope of > > >>>address/prefix should be assigned to which interface. It is very > > >>>important to consider the address scope in IPv6. For example, > > >>>there is no discussion whether manet nodes in a same manet uses the > > >>> same scope for MLP/MLA. Can MANET-A having link-local sends > > >>> packets to MANET-B having only global ? This goes against IPv6 > > spec. > > >>>According to manet-arch, each manet node needs to obtain > > >>>"unique prefix" instead of address for its local network and also > > >>>must obtain "unique prefix or address" for manet interface, too. > > >>>Am I right? For the first prefix, there are two possibility: > > >>>global prefix or uniquelocal prefix. For the second, five > > >>>possibility: global prefix, global address, uniquelocal prefix, > > >>>uniquelocal address, link local address. > > >>>How can AUTOCONF deal with these scope and differences? I > > >>>think it's very important to use the same scope specially for > > >>>MANET interface. You can not send packets from link-local scope to > > global > > >>> scope over link. Other direction is OK. Do we agree on > > >>> relaxing this scope limitation in manet? > > >>>Is there any definition that the same scope MUST be used for > > >>>MLP/MLA? Does the word "valid" below indicate this? It should > > >>>explicitly write so. > > >>>" MANET Local Prefix (MLP) - An IP prefix delegated to a > > >>>MANET router, consisting in chunks of IP addresses valid for > > >>>communications inside the MANET. MANET Local Address (MLA) - An IP > > >>> address configured on a MANET interface, and valid for > > >>> communications inside the MANET." > > >>>Actually, I am not clear what is MLA/MLP... The document said > > >>>in section 4.1 "a MANET router needs to configure at least one IP > > >>>address on its MANET interface, this being a link local address, an > > >>> MLA or a global address." > > >>>Does it mean MLA is unique local address?? > > >>>- How can each manet node decide whether it can obtain prefix > > >>>or address on a manet interface? In IPv6, it is simpler that > > >>>every node generates a link-local address on its interface, while > > >>>manet node may not assign a link-local address on manet interface. > > >>>How can this node decide whether it should wait for prefix or > > >>>simply generate a link-local address? > > >>>There is related question. How can a manet node detects whether it > > >>> attaches to manet or not? In IPv6, as soon as an interface becomes > > >>> active, it will start assigning a link-local address. > > >>> However, a manet node may wait this operation until it detects > > characteristics > > >>> of attached network (regular IPv6 or manet)... This is also one of > > >>> issue how a node can deploy both in manet and regular IPv6. > > >>> In addition to this, a manet node may need to detect connected or > > >>> standalone manet when it attaches to a network in order to discover > > >>> ICP?!. > > >>>- Last general question: for the prefix assignment to manet > > >>>(not manet interface), There are two possibility depending on ICP > > >>>availability: topologically correct prefix or non correct prefix. I > > >>>think this is two different things though the goal is same > > >>>assigning prefix to manet. Shall a solution support both scenarios? > > >>>-------------------------------------------------------------------- > > ------------ > > >>> > > >>>Detailed comments > > >>>- In section 4.1.1, it only said " IPv6 Stateless Address > > >>>Autoconfiguration [5] and Neighbor Discovery for IPv6 [3] do not > > >>>account for potential address duplication beyond a single > > >>>multicast-capable link." > > >>>NDP actually does not consider "multi-hop" support at all. I think > > >>> this address duplication is side-effect of no multi-hop > > consideration. > > >>>- Why do you say "p2p link" between border router and ISP edge > > >>>router in figure 1??? > > >>>- In section 4.1.2, it said Fig. 1, even if MR1 would be able > > >>>to provision MR3 with prefixes, using DHCP [4], it cannot be > > >>>assumed that MR1 or MR3 will not move and become unable to > > >>>communicate directly. On the other hand, frequent reconfiguration > > >>>may cause IPv6 Stateless Address Autoconfiguration [5] to be much > > >>>less efficient than expected, due to large amounts of control > > signalling. > > >>>This paragraph assume running DHCP and AUTOCONF over multihop. > > >>>Do you assume that MR1 is DHCP relay ?? There is no way to forward > > >>> DHCP messages by MR1. The document repeated to say that > > >>> "as-is" existing solution does not fit to manet environment. I > > don't think > > >>> these texts are useful explanation in this document. If you want > > >>>to explain the constraints of existing solutions, you should > > >>>have independent section how DHCP/NDP cannot fit to manet more in > > >>>detail, please. Problem statement document should not suggest or > > >>>assume any solutions. > > >>>- I'm not sure but "broadcast" may be IPv4 term!? > > >>>- Section 4.2.3 When a router changes its ICP affiliation, some > > >>>routes may be broken, affecting MANET packet forwarding performance > > >>> and applications. In a multiple border router / > > >>> multiple-prefixes MANET, frequent reconfiguration could cause a > > >>> large amount of control signalling (for instance if [5] is used). > > >>>Isn't this problem of DHCP? Do you assume that a manet node > > >>>can unicast renew message over connected ICP to the previous ICP > > >>>and continue using the same address?!:-p Or you just mention NDP? > > >>>It is no clear to me what is the intention you refer only NDP here. > > >>>- Section 5, It contains only general considerations. Not > > >>>specific to AUTOCONF solutions. > > >>>- Section 6, if you mention the security issue specific to AUTOCONF > > >>> (Not NDP), you should write in the section 4. You can refer > > >>> the section in the security consideration section. It will be > > >>> nice if you can list up all possible security threats regarding > > >>> AUTOCONF solutions (rather than referring security considerations > > >>> of existing solutions). > > >>> > > >>> > > >>> > > >>>_______________________________________________ Autoconf > > >>>mailing list Autoconf@ietf.org > > https://www1.ietf.org/mailman/listinfo/autoconf > > >> > > >> > > >>_______________________________________________ Autoconf mailing list > > >> Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf > > > > > > > > >______________________________________________________________________ > > >This email has been scanned by the MessageLabs Email Security System. > > >For more information please visit > > >http://www.messagelabs.com/email > > >______________________________________________________________________ > > > > > > > > > > > > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www1.ietf.org/mailman/listinfo/autoconf _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf
- [Autoconf] comments to autoconf PS RYUJI WAKIKAWA
- Re: [Autoconf] comments to autoconf PS Alexandru Petrescu
- Re: [Autoconf] comments to autoconf PS RYUJI WAKIKAWA
- Re: [Autoconf] comments to autoconf PS mase
- Re: [Autoconf] comments to autoconf PS Alexandru Petrescu
- Re: [Autoconf] comments to autoconf PS mase
- RE: [Autoconf] comments to autoconf PS Teco Boot
- RE: [Autoconf] comments to autoconf PS mase
- RE: [Autoconf] comments to autoconf PS Teco Boot
- RE: [Autoconf] comments to autoconf PS mase
- Re: [Autoconf] comments to autoconf PS Alexandru Petrescu
- RE: [Autoconf] comments to autoconf PS Teco Boot
- Re: [Autoconf] comments to autoconf PS RYUJI WAKIKAWA
- Re: [Autoconf] comments to autoconf PS RYUJI WAKIKAWA
- Re: [Autoconf] comments to autoconf PS RYUJI WAKIKAWA
- Re: scope of multicast address (was: [Autoconf] c… Alexandru Petrescu
- Re: movement scenario (was: [Autoconf] comments t… Alexandru Petrescu
- Re: [Autoconf] comments to autoconf PS mase
- Re: [Autoconf] comments to autoconf PS mase
- Re: [Autoconf] comments to autoconf PS mase
- Re: movement scenario (was: [Autoconf] comments t… mase
- Re: [Autoconf] comments to autoconf PS Alexandru Petrescu
- [Autoconf] Re: movement scenario Alexandru Petrescu
- Re: [Autoconf] comments to autoconf PS mase
- Re: [Autoconf] comments to autoconf PS Alexandru Petrescu
- [Autoconf] Re: movement scenario mase
- Re: [Autoconf] comments to autoconf PS mase
- Re: [Autoconf] Re: movement scenario Ulrich Herberg
- Re: [Autoconf] Re: movement scenario Yangwoo Ko
- Re: [Autoconf] Re: movement scenario Alexandru Petrescu
- Re: [Autoconf] Re: movement scenario Alexandru Petrescu
- [Autoconf] Re: scope of multicast address Alexandru Petrescu
- Re: [Autoconf] Re: scope of multicast address Marshall Eubanks
- Re: [Autoconf] Re: scope of multicast address Alexandru Petrescu