Subject: [Autoconf] comments to autoconf PS

From: RYUJI WAKIKAWA <[email-masked]>
Date: Fri, 30 Nov 2007 03:33:35 +0900

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/autoconf

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 30 Nov 2007 11:59:39 +0100

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

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 in the security consideration section. It will be nice if you
> can list up all possible security threats regarding AUTOCONF 

I agree.

Alex

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