RE: [Autoconf] comments to autoconf PS

["Teco Boot" <[e-mail]>]

Comments inline.

> -----Oorspronkelijk bericht-----
> Van: mase [mailto:[e-mail]]
> Verzonden: maandag 3 december 2007 5:05
> Aan: Teco Boot; 'Alexandru Petrescu'
> CC: [e-mail]
> Onderwerp: RE: [Autoconf] comments to autoconf PS
> 
> 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?

No. I prefer using Global Address over MLA over link-local address.

With Global Addresses, inner-MANET communication is to be used whenever
possible (there is a weak link problem, for this discussion: out-of-scope).
In case of partitioning, communication can continue if NEMO (or equivalent)
is used and both partitions are still part of the Internet (or connected to
Internet, this is a definition question). Maybe we need some interaction
between MANET routing and NEMO, but in principle, this should work.

If traffic is bound to single-hop, link-local addresses shall be used and
connectivity is broken when getting out of transmission range.

Teco.


> 
> >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:[e-mail]]
> > > Verzonden: maandag 3 december 2007 4:19
> > > Aan: Alexandru Petrescu
> > > CC: [e-mail]
> > > 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 [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/autoconf
> > > >>
> > > >>
> > > >>_______________________________________________ Autoconf mailing
> list
> > > >>  [e-mail]
> 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
> > > [e-mail]
> > > https://www1.ietf.org/mailman/listinfo/autoconf




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