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