Subject: Re: [Autoconf] MANET subnet model

From: Shubhranshu <[email-masked]>
Date: Mon, 30 Oct 2006 18:09:26 +0530

Hello Seung,

Please find a few inline comments. 

> To: <autoconf at ietf.org>
> Subject: MANET subnet model
> From: "Yi, Seung" <Seung.Yi at boeing.com>
> IPv6 Subnet Model for MANETs
<snip>
> 
> A key challenge with link-local addresses is providing duplicate address
> detection (DAD).  To satisfy the uniqueness on the link, the link-local
> address for a MR's MANET interface must be unique among all MANET
> interfaces on the link.  However, assuming mobility the neighbor
> relationship of an MR may change over time.  Since RFC 2462 (DAD) is
> performed only when the link-local address is configured, there is a
> chance that two nodes that were originally not on-link with respect to
> one another might configure the same link-local address.  If this occurs
> and the two nodes then move into each other's transmission range, this
> situation would violate the on-link address uniqueness condition. 

Considering these complicacies and overhead involved in maintaining uniqueness
of the link local address, do you suggest that manet node be allowed to have 
flexibility to configure only MANET local address (and optionally global addresses) ?

> 2.  Non-link-local addresses and prefixes
> MRs can configure non-link-local addresses and prefixes such as Unique
> Local Addresses (ULA), MANET Local Addresses (MLA) or globally routable
> IP addresses. 

sounds like you are assuming ULA and MLA as different addresses. IMO 
ULA can be used as Manet local address. 

> One possible configuration is that each MR can assign addresses from the
> same prefix to a MANET interface so that interfaces on multiple MRs
> belong to the same subnet. This method is feasible only when all MANET
> nodes that configure addresses from the same prefix are operationally
> assured to be reachable in one IP hop on the same link.

that would be hard to assure considering the dynamicity of manet topology and 
hence this method will mostly result in all those issues discussed in 
draft-iab-multilink-subnet-issues.

> 
> Another possible configuration is for each MR to assign prefixes to a
> MANET interface so that no two MRs belong to a same subnet.  MANET
> routing protocol behavior need not change since it will still inject
> appropriate routes to provide connectivity.  

this sounds fine and better way of doing things compared to the previous one 
provided we can assign appropriate prefixes. This approach would avoid most of 
the issues due to the assumptions related with TTL value.  

-- Shubhranshu

The simplest case would be
> configuring MANET interfaces with an address with a /128 prefix length.
> However, an application might make an incorrect assumption; e.g., a host
> application might assume that the MANET interface is configured with a
> /64 instead of a /128. If a host makes this assumption, it could fail to
> connect with another node in the same subnet due to an incorrect on-link
> assumption. But, the IPv6 scenario should be no different than for IPv4
> since IPv4 applications must honor CIDR prefix assignments on interfaces
> in order to avoid incorrect on-link assumptions.
> 
> 2.2   Delegation from prefix to a non-MANET interface
> With prefix delegation, an MR acquires/chooses one or more prefixes for
> assignment to non-MANET interfaces and other downstream hosts on those
> links.  For applications on the router itself that require a
> non-link-local address, a technique of delegating a small prefix to the
> router's loopback interface and having the router's applications bind to
> an address in that prefix has proven to be operationally useful.  To an
> attached node, this set-up appears as a normal link where link-local
> scope addressing and on-link determination works as usual. Again, MANET
> routing protocol behavior does not change and the MR injects appropriate
> routes over its MANET interface to provide connectivity.
> 
> 2.3 Combined model
> Prefix assignment and prefix delegation are not disjoint.  An MR can
> both assign addresses from shared prefixes to its MANET interface and
> receive prefix delegations for assignment to non-MANET interfaces, but
> it should keep the prefixes for each operation disjoint.  An MR should
> not use a same prefix for both assignment and delegation on different
> interfaces.
> 
> 3.  Prefix Aggregation
> Section 2 presents certain implications about prefix aggregation in
> MANETs.  MANET border routers may be able to present the MANET as a
> whole to external entities by enforcing a common network prefix for the
> all the nodes inside the MANET. For instance, all of the addresses in
> the prefixes delegated to each MR may be aggregated.  However, there is
> an operational risk to doing so if the MANET becomes partitioned.
> 
_______________________________________________
Autoconf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/autoconf

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 30 Oct 2006 10:43:20 -0800

Hi Shubhranshu,

> draft-iab-multilink-subnet-issues.

This may depend on the particular access link technology and/or
deployment scenario. True, the most widely-anticipated scenario
seems to be for mobile wireless techonolgies with dynamically-
changing topologies; this also seems to be well-articulated
(in RFC2501, Section 3.)

But, could a MANET also entail, e.g., nodes permanently attached
to a common Ethernet cable or even wireless nodes that are somehow
operationally assured to remain as one-hop neighbors even as they
move about? If so, couldn't it be possible to configure a shared
on-link prefix on MANET interfaces in such scenarios without it
becoming a multilink subnet?

Fred
[email-masked]

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 30 Oct 2006 12:20:45 -0800

Hello Fred,

> becoming a multilink subnet?
I would certainly agree that it should be possible.  The role of the subnet
leader in AODV was to perform exactly this function of sharing a subnet
prefix with every node on the subnet, without it being a multilink subnet.
We worked this out in quite some detail, to the point of being careful
about which ICMP messages needed to be sent.  This is also supported in
DYMO (section 5.7) and, presumably, OLSR but I did not verify the latter.

In fact, I think the internal structure of the subnet is nobody's business,
as long as the external interface (of a router that offers connectivity 
to every
live node in the subnet) is maintained.

Regards,
Charlie P.

-- 
Please address return e-mail to [email-masked]

---

From: "Yi, Seung" <[email-masked]>
Date: Mon, 30 Oct 2006 14:58:29 -0800

Hi, Shubhranshu,

Comments inline. 

________________________________
>Flexibility to configure only MANET local address (and optionally
global addresses) ?
 
Fred pointed out that a MANET router seems to be required to configured
link-local address too per RFC2461(bis). However I don't see any
architectural reason why one cannot go with MANET-local addresses only.

>ULA can be used as Manet local address. 
 
Agreed. I was referring to ULA as in RFC4193 and MLA as in
draft-jelger-autoconf-mla-01.txt. They are indeed quite similar. As long
as it serves as a unique identifier within MANET, it should do.

>That would be hard to assure considering the dynamicity of manet
topology and 
>draft-iab-multilink-subnet-issues.
 
Fred's reply seems reasonable to me.

>This sounds fine and better way of doing things compared to the
previous one 
>the issues due to the assumptions related with TTL value.  
 
I agree. Again, I'm leaning toward a design that eliminates the
headaches of multilink subnet. However, I'm not yet fully convinced that
the first choice (resulting in multilink subnet) is completely without
merit. Any opinions?

Thanks,

- Seung

---

From: Jari Arkko <[email-masked]>
Date: Tue, 31 Oct 2006 15:44:41 +0200

>> provided we can assign appropriate prefixes. This approach would avoid
>>     
> most of 
>   
If it is the case that you have a well understood approach
that avoids the multilink subnet issues you should go for
that. You have a complicated enough problem in your
hands even without having to support multiple ways to
do things. If you have a solution that works and has no
major drawbacks, standardize that.

--Jari

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 31 Oct 2006 08:38:36 -0800

Jari,

> major drawbacks, standardize that.

Can you clarify what you mean by this? I believe Seung's post
is essentially listing the following options for prefix
assignment to MANET interfaces:

 1) shared prefix for both address configuration and on-link
    determination (i.e., prefix length shorter than 128) -
    requires that all MANET interfaces that assign the prefix
    and configure addresses from the prefix be attached to
    the same link always and run DAD on the link
 2) shared prefix for address configuration but not on-link
    determination (i.e., prefix length = 128) - requires
    MANET-wide proxy-DAD in case multiple MANET interfaces
    configure duplicate addresses, but does not require
    attachment to same link
 3) unique prefix for each MANET interface - DAD avoidance
    through operational assurance against duplication
 4) link-local-only - requires MANET-wide proxy-DAD in case
    multiple MANET interfaces that configure the same link-local
    address might move onto the same link at some point in time.

There would seem to be potential use-cases for all of these
options, so why do you say "pick one" when it seems like all
may have their appropriate use-cases?

Note 1: option 4) also needs to be considered along with
        options 1) thru 3) since all MANET interfaces must
        configure a link-local address.
Note 2: DAD can be avoided through operational assurance
        against duplication in all cases, but that would
        tend to negate SEND.

Thanks - Fred

---

From: "Joe Macker" <[email-masked]>
Date: Tue, 31 Oct 2006 12:09:33 -0500

Fred:

It's a good idea to enumerate prefix assignment cases to help scope the
work.

Do we really need to REQUIRE multi-hop DAD for all deployments?  Having
mechanisms TO SUPPORT IT defined is ok, but requiring it is not IMHO.  So
can we talk about prefix assignment cases without DAD off-link issues for
now. Just a thought.

-joe

>-----Original Message-----
>From: Templin, Fred L [mailto:[email-masked]] 
>Sent: Tuesday, October 31, 2006 11:39 AM
>To: Jari Arkko; Yi, Seung
>Cc: [email-masked]
>Subject: RE: [Autoconf] MANET subnet model
>
>Jari,
>
>that avoids 
>> the multilink subnet issues you should go for that. You have a 
>> complicated enough problem in your hands even without having to 
>> support multiple ways to do things. If you have a solution 
>that works 
>> and has no major drawbacks, standardize that.
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 31 Oct 2006 10:16:42 -0800

Joe and Jari,

> It's a good idea to enumerate prefix assignment cases to help scope
the

OK.

> Do we really need to REQUIRE multi-hop DAD for all deployments?

Only for deployments that want to use self-generated addresses
like SEND/CGA that have non-negligible probability of collision.
Because if two MRs configure the same non-link-local address
on their MANET interface communications might fail. (Same is
true if two MRs configure the same link-local address and move
onto the same link at some point in time.)

> Having mechanisms TO SUPPORT IT defined is ok, but requiring it
> is not IMHO.

DAD avoidance through operational assurance against address
duplication (e.g., interface identifier assignment by a central
authority) is certainly an option, but self-generated addresses
like SEND/CGA can collide so you would need proxy-DAD for that. 

> So can we talk about prefix assignment cases without DAD off-link
> issues for now. Just a thought.

James Kempf indicated that Jari Arkko and Dave Thaler have
had previous discussions about proxy-DAD and implied that
there may be barriers to its adoption:
 
http://www1.ietf.org/mail-archive/web/netlmm/current/msg00850.html
http://www1.ietf.org/mail-archive/web/netlmm/current/msg00860.html

Jari, I'd appreciate if you could shed some light on those
prior discussions on the list.

Thanks - Fred