Subject: Re: [Autoconf] comments to autoconf PS

From: RYUJI WAKIKAWA <[email-masked]>
Date: Sun, 2 Dec 2007 03:09:50 +0900

Alex,

On 2007/11/30, at 19:59, Alexandru Petrescu wrote:

> RYUJI WAKIKAWA wrote:
> [...]
> Snipping much of the text you wrote to which I already agree.
>
>> - 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.
>
> If MR1 is right next to MR3 (no dots) then MR1 can be a DHCP Relay and
> the ISP Edge Router can be a DHCP Server, and MR3 the DHCP Client.   
> This

OK. If this is the intentional operation, authors should describe this  
in the draft.
>
> DHCPv6-PD is specified to work ok.  In implementation there are  
> however some issues with some DHCPv6-PD implementations.  For  
> example, this works ok with addresses (DHCPv6 for addresses not  
> prefixes), but for delegating a prefix: one implementation crashes  
> the Relay and another implementation does not add a route on the  
> Server, IIRC.

I see. I also think that DHCP behaviors are sometime different between  
implementations..

regards,
ryuji

>
>
> For reference the figure is:
>>                                                       ----- MR1...MR3
>>                                                      /      .
>>              +-------------+         +------------+ /       .
>>              |             |   p2p   |            |/        .   
>> (MANET)
>>              |  ISP Edge   |   Link  |  Border    |         .
>>              |   Router    +---------+  Router    |\        .
>>              |             |         |            | \       .
>>              +-------------+         +------------+  \----- MR2
>>                       Fig. 1. Connected MANET router topology.
>
>
>> 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 kind of agree.
>
>> - I'm not sure but "broadcast" may be IPv4 term!?
>
> I saw very little 'broadcast' in IPv6 contexts.  I mainly see  
> 'multicast' when discussing IPv6.  'Multicast' is also largely used  
> when talking link-layer MAC scope multicast.
>
> [...]
>
>> - 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).
>
> I agree.
>
> Alex
>
>
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email  
> ______________________________________________________________________

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

---

From: mase <[email-masked]>
Date: Sun, 02 Dec 2007 18:24:12 +0900

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.

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 that we cannot depend on link-local address, since MANET 
interface is SBI. 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.
>
>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.
>
>- 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 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).
>
>
>
>
>
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 02 Dec 2007 22:29:51 +0100

Hi mase, I have some opinions compared to your opinions, just some 
discussion.  I mainly agree with your suggestions to define addresses.

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.
> 

But looks as it is a recursive definition?

When you say 'reach' do you mean the packet can be forwarded by a
intermediary router?  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.

This has pretty good semantics in my understanding.  Opinions?

>  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.

> 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.

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
> 
>> 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.
>> 
>> 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?
>> 
>> MLP/MLA? Does the word "valid" below indicate this? It should 
>> explicitly write so.
>> 
>> 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."
>> 
>> 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?
>> 
>>  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?
>> 
>> - 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."
>> 
>> - Why do you say "p2p link" between border router and ISP edge 
>> router in figure 1???
>> 
>> 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.
>> 
>>  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.
>> 
>> - 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.
>> 
>> _______________________________________________ Autoconf mailing 
>> list [email-masked] 
> _______________________________________________ Autoconf mailing list
>  [email-masked] https://www1.ietf.org/mailman/listinfo/autoconf
>

---

From: mase <[email-masked]>
Date: Mon, 03 Dec 2007 12:19:24 +0900

Hi, Alex,

>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.
>

I have a suggestion of this style from the definition of link-local 
address of RFC4862.

>intermediary router?

Right.

>Or is it that the packet is reaching the

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.

>If so, then I agree with you.

I think that unique local address is a good candidate to be used in the MANET.

>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

>>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
>>>  some of my comments may be overlapped with others or already 
>>> be discussed in ML.
>>>(except for the description of uniqueness issue which is well explained!).
>>>  not deal with prefix assignment. If you want to assign 
>>> 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?
>>>"   MANET Local Prefix (MLP)  - An IP prefix delegated to a 
>>>MANET router, consisting in chunks of IP addresses valid for 
>>>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 
>>>- 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?
>>>  active, it will start assigning a link-local address. 
>>> However, a manet node may wait this operation until it detects characteristics
>>>  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 
>>>- Last general question: for the prefix assignment to manet 
>>>(not manet interface), There are two possibility depending on ICP 
>>>assigning prefix to manet.  Shall a solution support both scenarios?
>>>- 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.
>>>  DHCP messages by MR1. The document repeated to say that 
>>> "as-is" existing solution does not fit to manet environment. I don't think
>>>to explain the constraints of existing solutions, you should 
>>>have independent section how DHCP/NDP cannot fit to manet more in 
>>>  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.
>>>  (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 [email-masked] https://www1.ietf.org/mailman/listinfo/autoconf
>>
>>

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 3 Dec 2007 04:41:08 +0100

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.
I think MLA's are to be used for multi hop communications in the MANET.
I agree ULA is an obvious candidate for MLA.

Teco. 

> -----Oorspronkelijk bericht-----
> Van: mase [mailto:[email-masked]]
> Verzonden: maandag 3 december 2007 4:19
> Aan: Alexandru Petrescu
> CC: [email-masked]
> Onderwerp: Re: [Autoconf] comments to autoconf PS
> 
> Hi, Alex,
> 
> >>>mailing list [email-masked]

---

From: mase <[email-masked]>
Date: Mon, 03 Dec 2007 13:04:42 +0900

Teco,

Thank you for your comments. See in line.

>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?

Right.

>I agree ULA is an obvious candidate for MLA.

Thanks,
Kenichi

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 3 Dec 2007 09:35:06 +0100

Comments inline.

> Verzonden: maandag 3 december 2007 5:05
> Aan: Teco Boot; 'Alexandru Petrescu'
> CC: [email-masked]
> Onderwerp: RE: [Autoconf] comments to autoconf PS
> 
> Teco,
> 

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 that unique local address is a good candidate to be used in
> the
> > > MANET.
> > >
> > >
> > > >>PS domument, as you suggested. Sorry for the only partial answer
> to
> > > your
> > > >>comments.
> > > >>Regards, Kenichi
> > > >>> A "stateful" mechanism using NDP might be possible if we can
> design
> > > so.
> > > >>>MANET interface. You can not send packets from link-local scope
> to
> > > global
> > > >>>----------------------------------------------------------------
> ----
> > > ------------
> > > >>>
> > > >>>Detailed comments
> list

---

From: mase <[email-masked]>
Date: Mon, 03 Dec 2007 17:49:08 +0900

Comments in line.

>between MANET routing and NEMO, but in principle, this should work.

Agree, if global address is available. In the stand-alone MANET, MLA
should be used.

>connectivity is broken when getting out of transmission range.

If we use MLA and MANET routing, connectivity may not be broken even 
when getting out of transmission range thanks to multihop 
connectivity. This is the MANET.

Kenichi

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 03 Dec 2007 18:39:24 +0100

mase wrote:
[...]
>> When you say 'reach' do you mean the packet can be forwarded by a

In this sense I agree with you.  There are links with link-local scope 
(with link-local addresses) and IP routers between these links.

> 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.

In this sense, I agree.  So a MANET-local address (ULA candidate) has a 
scope larger than the link.

> I think that unique local address is a good candidate to be used in the 

I agree it's a good candidate.

> source/destination address.

right...

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 3 Dec 2007 18:46:25 +0100

Comments inline.

> Verzonden: maandag 3 december 2007 9:49
> > > >I think link-locals are essential to IPv6. I do not understand why
> we
> > > have a

I prefer global addresses, when available.
A connection using global addresses is maintained in the following scenario:
1) connection setup, in isolated manet, using global addresses
2) manet gets connected
3) mamet gets partitioned, the two parts are both still connected

> connectivity. This is the MANET.

Ok, but only for traffic that is not bound to single-hop.
I meant traffic that _is_ bound to single-hop, e.g. routing protocols.

Teco.

> > > > > >>What is MANET is given in the manetarch document, so I think
> that
> > > the
> > > > > >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
> > > > > >  I think I can build a MANET that does _not_ use SBI
> interfaces.
> > > In
> > > > > >>In this context, I think that link-local address must not be
> used
> > > in
> > > > > >>>First of all, i am sorry for my long silence, I needed some
> time
> > > to
> NDP
> > > does
> > > > > >>> prefix, stateless approach defined in RFC4862 is
> impossible,
> > > IMO.
> > > > > >>>there is no discussion whether manet nodes in a same manet
> uses
> > > the
> > > > > >>>communications inside the MANET. MANET Local Address (MLA)
> - An
> > > IP
> > > > > >>>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
> > > > > >>>There is related question. How can a manet node detects
> whether
> > > it
> > > > > >>> However, a manet node may wait this operation until it
> detects
> > > > > characteristics
> > > > > >>>  of attached network (regular IPv6 or manet)... This is
> also
> > > one of
> > > > > >>> In addition to this, a manet node may need to detect
> connected
> > > or
> > > > > >>>(not manet interface), There are two possibility depending
> on
> > > ICP
> > > > > >>>NDP actually does not consider "multi-hop" support at all.
> I
> > > think
> > > > > >>>less efficient than expected, due to large amounts of
> control
> > > > > signalling.
> > > > > >>> "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
> > > > > >>>have independent section how DHCP/NDP cannot fit to manet
> more
> > > in
> > > > > >>>detail, please.  Problem statement document should not
> suggest
> > > or
> > > > > >>>assume any solutions.
> > > > > >>>It is no clear to me what is the intention you refer only
> NDP
> > > here.
> mailing

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Mon, 3 Dec 2007 10:04:42 -0800

Hi Mase-san

> MANET-local unicast address.

I was asking what is the MANET-local scope? :-)
How can you map this manet-local into the current IPv6 scoping?
Do you suggest to define new address scope for MANET-local?

> 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  

The use of ULA is fine, but I expect this document help understanding  
the possible issues when using ULA.
And I want to see the reason why you call this as manet-local.
What is the difference between ULA and manet-local?
This is really confusing...

> partial answer to your comments.

ok.

regards,
ryuji

>> manet
>> manet

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Mon, 3 Dec 2007 10:10:29 -0800

On 2007/12/02, at 20:04, mase wrote:

>> we have a
> Do you prefer to change your source/destination address from a link- 
> local address to MLA?

The link-lcoal is still useful for any traffic transmitted only to 1- 
hop neighbor like NS/NA.

ryuji

>> that the
>> > I think that unique local address is a good candidate to be used  
>> in the
>> > MANET.
>> >
>> >
>> interfaces.  In
>> used in
>> > >>PS domument, as you suggested. Sorry for the only partial  
>> answer to
>> > your
>> > >>comments.
>> > >>Regards, Kenichi
>> time to
>> uses the
>> > >>>MANET interface. You can not send packets from link-local  
>> scope to
>> > global
>> address, an
>> whether it
>> connected or
>> mailing list

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Mon, 3 Dec 2007 10:15:50 -0800

Hi

On 2007/12/03, at 0:49, mase wrote:

>> > >I think link-locals are essential to IPv6. I do not understand  
>> why we
>> > have a
> Agree, if global address is available.

Do you say that if global address is available, global address is  
treated as MLA?
I think global address cannot be MLA, since some signaling (ex.  
DHCP!?) over mult-hop
to obtain global address are required.  chicken-egg problem !?

> In the stand-alone MANET, MLA
> should be used.

do you mean ULA as MLA?

regards,
ryuji

>> > > > >link.  I think a ULA addressed packet can reach a  
>> destination in a
>> > > > MANET
>> > > > >>In this context, I think that link-local address must not  
>> be used
>> > in
>> answer
>> > > > >>>First of all, i am sorry for my long silence, I needed  
>> some time
>> > to
>> scope
>> > > > >>>communications inside the MANET. MANET Local Address  
>> (MLA)  - An
>> > IP
>> > > > >>>NDP actually does not consider "multi-hop" support at  
>> all.  I
>> > think

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 04 Dec 2007 02:09:25 +0100

RYUJI WAKIKAWA wrote:
[...]
> Do you suggest to define new address scope for MANET-local?

There is this 'LL-MANET-Routers' address FF02:0:0:0:0:0:0:TBD4 defined 
in draft-ietf-manet-iana-07.txt.  This address has link-local scope.  A 
link-local scope is number '2', defined by RFC4291 "IPv6 Addressing 
Architecture".  That RFC defines other scopes as well: 0, 1, 4, 5, 8, E, F.

I'm not sure whether people really want/need to define another scope for 
MANET, not clear to me.

My personal opinion is to go with already reserved scopes.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 04 Dec 2007 02:20:37 +0100

mase wrote:
>> 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.
> 
> and only communicated over multi-hop. Do you prefer to change your
> source/destination address from a link-local address to MLA?

Ha!  That's right...

Src/dst address rewriting makes immediately think of NAT :-)

I think the case you describe above (former neighbor moves from a link 
to another) deserves deep analysis.  What are the mobility scenarios 
considered?  How do entities move, from where to where?

After a node moves from one subnet to another: does it keep its address? 
  Does it keep both its address _and_ its prefix?  When it keeps its 
address - nobody else on the previous link can use that address on that 
previous link?

Despite the apparent complexity of describing this, I think it's not so 
difficult - as long as two or more people have encountered the same 
movement scenario.

Alex

---

From: mase <[email-masked]>
Date: Tue, 04 Dec 2007 13:32:25 +0900

Hi, Ryuji,

Comments in line.

>Do you suggest to define new address scope for MANET-local?

MANET is a routing domain containing MANET routers, as defined in 
manetarch document. MANET-local sope is thus same as the set of MANET 
routers in a MANET. Whether to define a new address scope for 
addresses of MANET-local scope is another issue. We may define a new 
address scope for MANET-local or use unique-local address. This is 
one of the problems, which shold be clearly described in the PS draft.

>This is really confusing...

IMHO, MANET scope and address scope to be used for MANET scope is 
different issue.
ULA can be used for addresses of MANET scope, but ULA can be also 
used for another scope such as sites.

Kenichi

---

From: mase <[email-masked]>
Date: Tue, 04 Dec 2007 13:36:00 +0900

Comments in line.

At 03:10 07/12/04, RYUJI WAKIKAWA wrote:

>>link- local address to MLA?
>
>The link-lcoal is still useful for any traffic transmitted only to 
>1- hop neighbor like NS/NA.

Yes, but when this neighbor moves away far, address information 
obtained through NS/NA cannot work.

Kenichi

---

From: mase <[email-masked]>
Date: Tue, 04 Dec 2007 13:46:41 +0900

Hi,

At 03:15 07/12/04, RYUJI WAKIKAWA wrote:
>>>you.
>>>possible (there is a weak link problem, for this discussion: out-of- scope).

No, but global address can be used for intra-MANET communication, if 
they are maintained by MANET routers.

>to obtain global address are required.  chicken-egg problem !?

Right. a MANET router must therefore configure a MLA address first, 
then it may obtain a global prefix and configure a global address in principle.

>>In the stand-alone MANET, MLA

ULA is one of the candidates. I am not sure we should create a new 
address scope for MLA at this time. This may be answered in solution space.

Kenichi

>>> > > > I have a suggestion of this style from the definition of link- local
>>> > > > address of RFC4862.
>>> > > >
>>> > > >

---

From: mase <[email-masked]>
Date: Tue, 04 Dec 2007 13:58:27 +0900

Hi,

At 10:20 07/12/04, Alexandru Petrescu wrote:
>I think the case you describe above (former neighbor moves from a 
>link to another) deserves deep analysis.  What are the mobility 
>scenarios considered?  How do entities move, from where to where?

Any mobility. We do not assume a particular mobility scenario when 
designing MANET routing protocols.

>After a node moves from one subnet to another: does it keep its 
>address?  Does it keep both its address _and_ its prefix?  When it 
>keeps its address - nobody else on the previous link can use that 
>address on that previous link?

Yes, in the same MANET. We thus need to define MANET-local address.

Kenichi

>Despite the apparent complexity of describing this, I think it's 
>not so difficult - as long as two or more people have encountered 
>the same movement scenario.
>
>Alex
>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 04 Dec 2007 06:05:49 +0100

Hi Kenichi,

mase wrote:
[...]
>> I was asking what is the MANET-local scope? :-) How can you map
>> this manet-local into the current IPv6 scoping? Do you suggest to
>> define new address scope for MANET-local?
> 
>  routers in a MANET.

Along this line: because the LL-MANET-Routers address (ff02::tbd4) has
link-local multicast scope (draft-ietf-manet-iana), can we say that
MANET-local scope is actually the IPv6 link-local scope?

> Whether to define a new address scope for addresses of MANET-local
> scope is another issue. We may define a new address scope for
> MANET-local or use unique-local address. This is one of the problems,
> which shold be clearly described in the PS draft.

Right... that's a question.

>>>  the above definition is clear. In reality, I think that we may
>>> use unique local IPv6 unicast address for MANET-local address.
>> 
>> The use of ULA is fine, but I expect this document help
>> understanding the possible issues when using ULA. And I want to see
>> the reason why you call this as manet-local. What is the difference
>> between ULA and manet-local? This is really confusing...
> 
> different issue. ULA can be used for addresses of MANET scope, but
> ULA can be also used for another scope such as sites.

I understand by 'scope' the scope of an address, as per the IPv6 
Addressing Architecture RFC.

Terminology... :-)

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 04 Dec 2007 06:11:41 +0100

mase wrote:
>>>> 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?
>> 
>> Ha!  That's right...
>> 

I think that is a problem.  If we don't know the landmarks, the movement
patterns, the dependencies... then it's very difficult to design
something meaningful, that fits some initial goals and requirements.

I think people who have prototyped MANETs have always tested certain
movement scenarios.  At least these could be documented.

It's really very tough to design something that acomodates _any_ mobility...

Besides, such thing risks of not being able to be qualified, can not be
evaluated, can not be compared.  Of course, it _can_ be designed _and_
prototyped but how would one compare it.

Alex

>>  This email has been scanned by the MessageLabs Email Security
>> System. For more information please visit
>> http://www.messagelabs.com/email

---

From: mase <[email-masked]>
Date: Tue, 04 Dec 2007 14:27:29 +0900

Hi Alex,

>MANET-local scope is actually the IPv6 link-local scope?

No. not all MANET routers are neighbors to each other. 
LL-MANET-Routers address is used only to reach neighbors.

Kenichi

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 04 Dec 2007 06:38:05 +0100

mase wrote:
> No. not all MANET routers are neighbors to each other. LL-MANET-Routers 
> address is used only to reach neighbors.

So MANET Routers which are not part of the LL-MANET-Routers scope 
(link-local scope) are part of another scope.  Which scope?  Is this the 
MANET-local scope?

I think we may need to find another term for the "-local" part because 
it too easily leads to think it's the link-local scope, especially 
because of the LL-MANET-Routers address having the link-local scope.

Or maybe we want to suggest "MANET-local" scope to be a new scope 
suggested to the IPv6 Addressing Architecture RFC?  Sounds complicated 
:-) to me.

I don't know what you think.

Alex

---

From: mase <[email-masked]>
Date: Tue, 04 Dec 2007 14:46:02 +0900

Hi Alex,

>prototyped but how would one compare it.

I understand your concern. "Any mobility" may not be adequate. 
pedestrian ad hoc networks, vehicular ad hoc networks, ... 
Different ad hoc networks may have different mobility models 
(maximum speed, etc.). I only wanted to point out we do not assume 
a particular mobility model in developing  autoconfiguration 
solutions.  In general, we do not assume apriori knowledge on 
locations and movement of MANET routers.

Kenichi

---

From: mase <[email-masked]>
Date: Tue, 04 Dec 2007 15:52:18 +0900

At 14:38 07/12/04, Alexandru Petrescu wrote:
>(link-local scope) are part of another scope.  Which scope?  Is this 
>the MANET-local scope?

Right.

>I think we may need to find another term for the "-local" part 
>because it too easily leads to think it's the link-local scope, 
>especially because of the LL-MANET-Routers address having the link-local scope.
>
>suggested to the IPv6 Addressing Architecture RFC?  Sounds complicated :-) to me.
>

According to RFC4862,
link-local address -  an address having link-only scope that can be
       used to reach neighboring nodes attached to the same link.  All
       interfaces have a link-local unicast address.

Here the term link-only scope is used. Similarly, MANET-local 
address and MANET-only scope can be meaningful, since a definition 
of MANET is given in the manetarch document.

Kenichi

---

From: "Ulrich Herberg" <[email-masked]>
Date: Tue, 4 Dec 2007 18:46:49 +0100

Hi,

I agree with Kenichi. Maybe one could mention different scenarios in
the PS, but basically no particular mobility model should be
considered in my opinion. For Alex's concern about comparability, I
don't think this should be part of a PS (maybe more in a solution
space? or something like
draft-bernardos-autoconf-evaluation-considerations ?). The problem of
autoconfiguration should be applicable to all mobility patterns to my
understanding.

Ulrich

---

From: Yangwoo Ko <[email-masked]>
Date: Wed, 05 Dec 2007 03:11:19 +0900

I got lost. Can somebody clarify how mobility affects address 
configurations? It is very obvious that mobility affects decisions on 
which solutions are better than others. But it seems only related with 
how dynamic the characteristics of MANET-type links are rather than with 
what kinds of prefixes/addresses are to be given.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 04 Dec 2007 13:58:35 -0800

Ulrich Herberg wrote:
> considered in my opinion.

What are the risks of not considering the limits of each entity's
movement?  Do we risk anything?

Or is it just a problem of verbally/writenly communicating the movement
scenario - problem that we could ignore?

> For Alex's concern about comparability, I don't think this should be
>  part of a PS (maybe more in a solution space? or something like 
>  autoconfiguration should be applicable to all mobility patterns to 
> my understanding.

I kind of agree.  I'd say it should apply to a wide range of mobility
patterns.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 04 Dec 2007 14:08:15 -0800

Hi Yangwoo Ko,

Yangwoo Ko wrote:
> configurations?

Well, it's simple.  If we agree that mobility is when a node changes its
address (remark it's different than that 'mobility' that defines a node
that physically moves).  We may not, probably.

> It is very obvious that mobility affects decisions on which solutions
> are better than others. But it seems only related with how dynamic
> the characteristics of MANET-type links are rather than with what
> kinds of prefixes/addresses are to be given.

I kind of see what you mean.

But it is often important to have a good idea about what addresses and 
their scopes are going to be used because that has immediate 
consequences on the existing protocols.

Or maybe you mean something else I don't see?

Alex

> 
> Ulrich Herberg wrote:
>> Hi,
>> 
>> I agree with Kenichi. Maybe one could mention different scenarios
>> in the PS, but basically no particular mobility model should be 
>> draft-bernardos-autoconf-evaluation-considerations ?). The problem
>> of autoconfiguration should be applicable to all mobility patterns
>> to my understanding.
>> 
>> Ulrich
>> 
>>>>> Hi, At 10:20 07/12/04, Alexandru Petrescu wrote:
>>>>> 
>>>>>> mase wrote:
>>>>>> 
>>>>>>>> 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
>>>>>> Ha!  That's right... Src/dst address rewriting makes
>>>>>> immediately think of NAT :-) I think the case you describe
>>>>>> above (former neighbor moves from a link to another)
>>>>>> deserves deep analysis.  What are the mobility scenarios
>>>>> Any mobility. We do not assume a particular mobility scenario
>>>>> when designing MANET routing protocols.
>>>>> 
>>>> I think that is a problem.  If we don't know the landmarks, the
>>>>  movement patterns, the dependencies... then it's very
>>>> difficult to design something meaningful, that fits some
>>>> initial goals and requirements.
>>>> 
>>>> I think people who have prototyped MANETs have always tested
>>>> certain movement scenarios.  At least these could be
>>>> documented.
>>>> 
>>>> Besides, such thing risks of not being able to be qualified,
>>>> can not be evaluated, can not be compared.  Of course, it _can_
>>>> be designed _and_ prototyped but how would one compare it.
>>>> 
>>> (maximum speed, etc.). I only wanted to point out we do not
>>> assume a particular mobility model in developing
>>> autoconfiguration solutions.  In general, we do not assume
>>> apriori knowledge on locations and movement of MANET routers.
>>> 
>>> Kenichi
>>> 
>>> 
>>> 
>>>> Alex
>>>> 
>>>> 
>>>>>> After a node moves from one subnet to another: does it keep
>>>>>> its address?  Does it keep both its address _and_ its
>>>>>> prefix?  When it keeps its address - nobody else on the
>>>>>> previous link can use that address on that previous link?
>>>>>> 
>>>>> Yes, in the same MANET. We thus need to define MANET-local
>>>>> address. Kenichi
>>>>> 
>>>>> 
>>>>>> Despite the apparent complexity of describing this, I think
>>>>>> it's not so difficult - as long as two or more people have
>>>>>> encountered the same movement scenario. Alex
>>>>>> 
>>>>>> This email has been scanned by the MessageLabs Email
>>>>>> Security System. For more information please visit

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 05 Dec 2007 14:18:30 -0800

[to not follow up on my own post...]

Alexandru Petrescu wrote:
> RYUJI WAKIKAWA wrote: [...]
> There is this 'LL-MANET-Routers' address FF02:0:0:0:0:0:0:TBD4
> defined in draft-ietf-manet-iana-07.txt.  This address has link-local
> scope.  A link-local scope is number '2', defined by RFC4291 "IPv6
> Addressing Architecture".  That RFC defines other scopes as well: 0,
> 1, 4, 5, 8, E, F.
> 
> I'm not sure whether people really want/need to define another scope
> for MANET, not clear to me.
> 

I've been pointed out in private that maybe a permanent multicast Group
ID could be requested for use in MANET, following guidelines in RFC3307
"IPv6 Multicast Address Guidelines".

By my reading (could be wrong), an example would be to request Group ID
0x7FFFFFFE (and have an Expert Review this).

This Group ID would then be used within any of the defined IPv6
multicast scopes:

FF02::7FFF:FFFE - All MANET Routers on the same link
FF05::7FFF:FFFE - All MANET Routers on the same site
FF0E::7FFF:FFFE - All MANET Routers in the Internet

This Group ID would probably also map into a Ethernet group address:
33-33-7F-FF-FF-FE - IPv6 Neighbor Discovery - MANET

Not sure having got this straight.

Alex

---

From: "Marshall Eubanks" <[email-masked]>
Date: Wed, 5 Dec 2007 18:57:16 -0500

Hello;

> 0x7FFFFFFE (and have an Expert Review this).

That could certainly be done.

From
http://www.iana.org/assignments/ipv6-multicast-addresses

Variable Scope Multicast Addresses
----------------------------------

These permanently assigned multicast addresses are valid over all scope
ranges.  This is shown by an "X" in the scope field of the address that
means any legal scope value.

Note that, as defined in [RFC4291], IPv6 multicast addresses which
are only different in scope represent different groups.  Nodes must
join each group individually.

And,  (from rfc4291) scop is a 4-bit multicast scope value used to
limit the scope of
      the multicast group.  The values are as follows:

         0  reserved
         1  Interface-Local scope
         2  Link-Local scope
         3  reserved
         4  Admin-Local scope
         5  Site-Local scope
         6  (unassigned)
         7  (unassigned)
         8  Organization-Local scope
         9  (unassigned)
         A  (unassigned)
         B  (unassigned)
         C  (unassigned)
         D  (unassigned)
         E  Global scope
         F  reserved

So MANET could get an address set like :

 FF0X:0:0:0:0:0:0:133

This would represent 16 possible groups in total.

(Note that  the actual address would be assigned by IANA; I use this
value just for example.)

Would this request be part of an RFC ?

Regards
Marshall

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 05 Dec 2007 16:53:17 -0800

Thanks for the message Marshall,

Marshall Eubanks wrote:
[...]
> That could certainly be done.

Great!

> http://www.iana.org/assignments/ipv6-multicast-addresses

That?

> Variable Scope Multicast Addresses

Thanks, staying in the 'for example' discussion direction.

For my understanding, I need to distinguish between a Permanent IPv6 
Multicast Group Identifier (range 0x40000000-0x7fffffff) and a Permanent 
IPv6-only Multicast Address (0x100-0x3fffffff).  You giving example 
'133' seems to me you mean an address (and not a Group ID).   Is this so?

I think there may be differences between these two possibilities, at 
least in which registry are they to be assigned:
Group ID http://www.iana.org/assignments/perm-mcast-groupids or
Address  http://www.iana.org/assignments/ipv6-multicast-addresses

You're obviously the expert to ask :-)

Thanks,

Alex