Subject: [Autoconf] new charter

From: Jari Arkko <[email-masked]>
Date: Fri, 20 Feb 2009 21:59:35 +0200

In the light of the new direction for the working group,
we are planning to update the charter as follows. Comments
appreciated.

Jari & the chairs

----

Ad-Hoc Network Autoconfiguration (autoconf) 
------------------------------------------------------------- 
Last Modified: 2009-02-18 
 
Cuurent Status: Active Working Group 
 
Additional information is available at tools.ietf.org/wg/autoconf 
 
Chair(s): 
Ryuji Wakikawa [[email-masked]] 
Thomas Clausen [[email-masked]] 
 
Internet Area Director(s): 
Jari Arkko [[email-masked]] 
Mark Townsley [[email-masked]] 
 
Internet Area Advisor: 
Jari Arkko [[email-masked]] 
 
Mailing Lists: 
General Discussion: [email-masked] 
To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf 
Archive: 
http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html 
 
Description of Working Group: 
 
In order to communicate among themselves, ad hoc nodes (refer to RFC 
2501) need to configure their network interface(s) with local addresses 
that are valid within an ad hoc network. Ad hoc nodes may also need to 
configure globally routable addresses, in order to communicate with 
devices on the Internet. From the IP layer perspective, an ad hoc 
network presents itself as a L3 multi-hop network formed over a 
collection of links. 
 
The main purpose of the AUTOCONF WG is to describe the addressing model 
for ad hoc networks and how nodes in these networks configure their 
addresses. It is required that such models do not cause problems for ad 
hoc-unaware parts of the system, such as standard applications running 
on an ad hoc node or regular Internet nodes attached to the ad hoc 
nodes. This group's effort may include the development of new protocol 
mechanisms, should the existing IP autoconfiguration mechanisms be found 
inadequate. However, the first task of the working group is to describe 
one practical addressing model for ad hoc networks. 
 
Once this sole work item is completed, the group can be rechartered to 
work on additional issues. 
 
Goals and Milestones: 
 
Apr 2009 Submit initial draft on address configuration in ad hoc networks
Sep 2009 Submit address configuration draft to IESG as Informational or 
close WG

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 20 Feb 2009 21:29:46 +0100

Hi Jari,

	One quick comment (I haven't read the proposed text in detail yet): are
we considering IPv6 only? IPv6 and IPv4? IPv4 only? previous charter
focused only on IPv6 solutions...

	Kind Regards,

	Carlos

El vie, 20-02-2009 a las 21:59 +0200, Jari Arkko escribió:
> _______________________________________________
> Autoconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/autoconf
-- 
 Carlos Jesús Bernardos Cano     http://www.netcoms.net
 GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
        Deployment Experiences on Vehicular networks
                  http://www.weedev.org/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

---

From: Jari Arkko <[email-masked]>
Date: Fri, 20 Feb 2009 22:57:08 +0200

I intentionally made the new charter not say anything about that. My 
belief is that the type of architecture document that we are looking at 
can easily talk about both IPv4 and IPv6.

Jari

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 20 Feb 2009 22:05:18 +0100

OK, understood. If we finally go to new solutions space (if existing IP
autoconfiguration mechanisms cannot be used), then this would have to be
discussed, I guess, because there IPv4 vs IPv6 might have an impact.

thanks for the clariffication,

Carlos

---

From: Paul Lambert <[email-masked]>
Date: Sun, 22 Feb 2009 23:59:38 -0800

I'm glad to see IPv4 be in scope in the new charter.  I've been lurking on the list for awhile hoping to find existing or emerging IETF solutions for ad hoc address assignment.  Specifically there is a real need for IP address assignment solutions for 802.11 ad hoc networks.  There are unique issues when security is included based on WPA2 or WPA2 using WPS (Wi-Fi Protected Setup).

Security for WPA2 is connection oriented and requires the pair-wise establishment of the keying relationships.  This means that WPA2 secured multicast can not be used for peer discovery or address assignment in an 802.11 ad hoc network.  New mechanisms are required for rapid peer identification and IP address assignment.

I'd be very interested in collaborating on solutions for the specific issues of 802.11 ad hoc networks.

Regards,

Paul

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Carlos Jesús Bernardos Cano
> Sent: Friday, February 20, 2009 1:05 PM
> To: Jari Arkko
> Cc: [email-masked]
> Subject: Re: [Autoconf] new charter
>

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 24 Feb 2009 01:23:19 +0900

Hi all,

It seems the line break is missed from Jari's mail.
so, resend the new charter.

regards,
ryuji

Chair(s):
Ryuji Wakikawa <[email-masked]>
Thomas Clausen <[email-masked]>

Internet Area Director(s):
Jari Arkko <[email-masked]>
Mark Townsley <[email-masked]>

Internet Area Advisor:
Jari Arkko <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf
Archive: http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html

In order to communicate among themselves, ad hoc nodes (refer to RFC  
2501) need to configure their network interface(s) with local  
addresses that are valid within an ad hoc network. Ad hoc nodes may  
also need to configure globally routable addresses, in order to  
communicate with devices on the Internet. From the IP layer  
perspective, an ad hoc network presents itself as a L3 multi-hop  
network formed over a collection of links.

The main purpose of the AUTOCONF WG is to describe the addressing  
model for ad hoc networks and how nodes in these networks configure  
their addresses. It is required that such models do not cause problems  
for ad hoc-unaware parts of the system, such as standard applications  
running on an ad hoc node or regular Internet nodes attached to the ad  
hoc nodes. This group's effort may include the development of new  
protocol mechanisms, should the existing IP autoconfiguration  
mechanisms be found inadequate. However, the first task of the working  
group is to describe one practical addressing model for ad hoc networks.

Goals and Milestones:

Apr 2009 Submit initial draft on address configuration in ad hoc  
networks
Sep 2009 Submit address configuration draft to IESG as Informational  
or close WG.

On 2009/02/21, at 4:59, Jari Arkko wrote:

> ------------------------------------------------------------- Last  
> Modified: 2009-02-18 Cuurent Status: Active Working Group Additional  
> information is available at tools.ietf.org/wg/autoconf Chair(s):  
> Ryuji Wakikawa [[email-masked]] Thomas Clausen [[email-masked] 
> ] Internet Area Director(s): Jari Arkko [[email-masked]] Mark  
> Townsley [[email-masked]] Internet Area Advisor: Jari Arkko [[email-masked] 
> ] Mailing Lists: General Discussion: [email-masked] To Subscribe: https://www.ietf.org/mailman/listinfo/autoconf 
>  Archive: http://www.ietf.org/mail-archive/web/autoconf/current/maillist.html 
>  Description of Working Group: In order to communicate among  
> themselves, ad hoc nodes (refer to RFC 2501) need to configure their  
> network interface(s) with local addresses that are valid within an  
> ad hoc network. Ad hoc nodes may also need to configure globally  
> routable addresses, in order to communicate with devices on the  
> Internet. From the IP layer perspective, an ad hoc network presents  
> itself as a L3 multi-hop network formed over a collection of links.  
> The main purpose of the AUTOCONF WG is to describe the addressing  
> model for ad hoc networks and how nodes in these networks configure  
> their addresses. It is required that such models do not cause  
> problems for ad hoc-unaware parts of the system, such as standard  
> applications running on an ad hoc node or regular Internet nodes  
> attached to the ad hoc nodes. This group's effort may include the  
> development of new protocol mechanisms, should the existing IP  
> autoconfiguration mechanisms be found inadequate. However, the first  
> task of the working group is to describe one practical addressing  
> model for ad hoc networks. Once this sole work item is completed,  
> the group can be rechartered to work on additional issues. Goals and  
> Milestones: Apr 2009 Submit initial draft on address configuration  
> in ad hoc networks
> Sep 2009 Submit address configuration draft to IESG as Informational  
> or close WG
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 26 Feb 2009 18:41:10 +0100

Ryuji Wakikawa a écrit :
[gracefully re-formatted]
> Additional information is available at tools.ietf.org/wg/autoconf
[snipped]
> one practical addressing model for ad hoc networks.

Would a straightforward addressing model along the following lines fit 
the bill?:

         -----  wifi "adhoc1"  ------  wifi "adhoc2"  -----
        |Host1|---------------|Router|---------------|Host2|
         ----- LL1         LL2 ------ LL3        LL4  -----
               G1                                G4

        "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode.
                               Each is an IPv6 subnet.
        LL1...4: IPv6 link-local addresses.
                 Self-formed according to rfc2464.
        G1, G4:  IPv6 global addresses, for example
                 2001:db8::1/64 and 2001:db8::4/64.
                 Manually assigned, or pre-configured with SNMP
                 or according to stateless autoconf rfc4862.

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 26 Feb 2009 20:04:57 +0100

Inline:

|-----Oorspronkelijk bericht-----
|Van: [email-masked] [mailto:[email-masked]] Namens
|Alexandru Petrescu
|Verzonden: donderdag 26 februari 2009 18:41
|Aan: Ryuji Wakikawa
|CC: [email-masked]
|Onderwerp: Re: [Autoconf] new charter
|
|Ryuji Wakikawa a écrit :
|[gracefully re-formatted]
|> Ad-Hoc Network Autoconfiguration (autoconf)
|>
|> Last Modified: 2009-02-18
|>
|> Additional information is available at tools.ietf.org/wg/autoconf
|[snipped]
|> Description of Working Group:
|>
|> In order to communicate among themselves, ad hoc nodes (refer to RFC
|> 2501) need to configure their network interface(s) with local
|addresses
|> that are valid within an ad hoc network. Ad hoc nodes may also need to
|> configure globally routable addresses, in order to communicate with
|> devices on the Internet. From the IP layer perspective, an ad hoc
|> network presents itself as a L3 multi-hop network formed over a
|> collection of links.
|>
|> The main purpose of the AUTOCONF WG is to describe the addressing
|model
|> for ad hoc networks and how nodes in these networks configure their
|> addresses. It is required that such models do not cause problems for
|ad
|> hoc-unaware parts of the system, such as standard applications running
|> on an ad hoc node or regular Internet nodes attached to the ad hoc
|> nodes. This group's effort may include the development of new protocol
|> mechanisms, should the existing IP autoconfiguration mechanisms be
|found
|> inadequate. However, the first task of the working group is to
|describe
|> one practical addressing model for ad hoc networks.
|
|Would a straightforward addressing model along the following lines fit
|the bill?:
|
|         -----  wifi "adhoc1"  ------  wifi "adhoc2"  -----
|        |Host1|---------------|Router|---------------|Host2|
|         ----- LL1         LL2 ------ LL3        LL4  -----
|               G1                                G4
|
|
|
|        "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode.
|                               Each is an IPv6 subnet.
|        LL1...4: IPv6 link-local addresses.
|                 Self-formed according to rfc2464.
|        G1, G4:  IPv6 global addresses, for example
|                 2001:db8::1/64 and 2001:db8::4/64.
|                 Manually assigned, or pre-configured with SNMP
|                 or according to stateless autoconf rfc4862.

I do not understand why the router doesn't advertize prefixes. If so, the
hosts can autoconfigure globally unique addresses, with distinct prefixes.
If not, and one configures globally unique addresses with same prefix on
different segments, (s)he is fully responsible for what services are and are
not provided. I would never design such a network.
So I would say: no.

My 2ct, Teco

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 26 Feb 2009 20:44:37 +0100

> hosts can autoconfigure globally unique addresses, with distinct prefixes.

Sorry, I made an error indeed putting same prefix.  How about this 
updated picture with the prefixes being distinct:

        "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode.
                               Each is an IPv6 subnet.
        LL1...4: IPv6 link-local addresses.
                 Self-formed according to rfc2464.
        G1, G4:  IPv6 global addresses, for example
                 2001:db8:1::1/64 and
                 2001:db8:2::4/64
                 Manually assigned, or pre-configured with SNMP
                 or formed according to stateless autoconf rfc4862;
                 the prefixes are advertised by Router in RAs.

> not provided. I would never design such a network.

I agree.

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 26 Feb 2009 11:58:28 -0800

Hello folks,

I have issues with the proposed charter.

Jari Arkko wrote:
> addresses that are valid within an ad hoc network. 

Dymo and AODV allow a node with a global address to work in an ad-hoc 
network
without configuing any local address.  I think this is an important 
feature to maintain.

Of course, such nodes wouldo not _necessarily_ have to initiate address
configuration protocols as will be specified within [autoconf].

> their addresses.

I would say the main purpose of [autoconf] is to _specify_ how nodes
in such networks configure their addresses.  Describing the addressing
model is simply a crucial step along the way, but it ought to be very
simple to do once we get past these initial conceptual roadblocks.

> Sep 2009 Submit address configuration draft to IESG as Informational 

This doesn't have any deliverable for the autoconfiguration protocol.  
As such,
it seems to me to be overly pessimistic about the ability of the group 
to make
progress.  Perhaps it is felt that pessimism is justified by various 
cyclical
processes that have consumed the energy of the group over the last three
years.  I'd recommend a more constructive outlook, which in itself would
motivate stronger contributions from the members of the team.

Otherwise, the working group devolves into some exercise in (perhaps
useful) abstraction.  Imagine what would have happened if [ipv6] were
initially chartered only to develop an addressing model!

Regards,
Charlie P.

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 26 Feb 2009 21:25:29 +0100

Now I think the addressing fits an acceptable model.
Teco

|-----Oorspronkelijk bericht-----
|Van: Alexandru Petrescu [mailto:[email-masked]]
|Verzonden: donderdag 26 februari 2009 20:45
|Aan: Teco Boot
|CC: 'Ryuji Wakikawa'; [email-masked]
|Onderwerp: Re: [Autoconf] new charter
|
|Teco Boot a écrit :
|> Inline:
|>
|> |-----Oorspronkelijk bericht-----
|> |Van: [email-masked] [mailto:[email-masked]]
|Namens
|> |Alexandru Petrescu
|> |Verzonden: donderdag 26 februari 2009 18:41
|> |Aan: Ryuji Wakikawa
|> |CC: [email-masked]
|> |Onderwerp: Re: [Autoconf] new charter
|> |
|> |Ryuji Wakikawa a écrit :
|> |[gracefully re-formatted]
|> |> Ad-Hoc Network Autoconfiguration (autoconf)
|> |>
|> |> Last Modified: 2009-02-18
|> |>
|> |> Additional information is available at tools.ietf.org/wg/autoconf
|> |[snipped]
|> |> Description of Working Group:
|> |>
|> |> In order to communicate among themselves, ad hoc nodes (refer to
|RFC
|> |> 2501) need to configure their network interface(s) with local
|> |addresses
|> |> that are valid within an ad hoc network. Ad hoc nodes may also need
|to
|> |> configure globally routable addresses, in order to communicate with
|> |> devices on the Internet. From the IP layer perspective, an ad hoc
|> |> network presents itself as a L3 multi-hop network formed over a
|> |> collection of links.
|> |>
|> |> The main purpose of the AUTOCONF WG is to describe the addressing
|> |model
|> |> for ad hoc networks and how nodes in these networks configure their
|> |> addresses. It is required that such models do not cause problems
|for
|> |ad
|> |> hoc-unaware parts of the system, such as standard applications
|running
|> |> on an ad hoc node or regular Internet nodes attached to the ad hoc
|> |> nodes. This group's effort may include the development of new
|protocol
|> |> mechanisms, should the existing IP autoconfiguration mechanisms be
|> |found
|> |> inadequate. However, the first task of the working group is to
|> |describe
|> |> one practical addressing model for ad hoc networks.
|> |
|> |Would a straightforward addressing model along the following lines
|fit
|> |the bill?:
|> |
|> |         -----  wifi "adhoc1"  ------  wifi "adhoc2"  -----
|> |        |Host1|---------------|Router|---------------|Host2|
|> |         ----- LL1         LL2 ------ LL3        LL4  -----
|> |               G1                                G4
|> |
|> |
|> |
|> |        "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode.
|> |                               Each is an IPv6 subnet.
|> |        LL1...4: IPv6 link-local addresses.
|> |                 Self-formed according to rfc2464.
|> |        G1, G4:  IPv6 global addresses, for example
|> |                 2001:db8::1/64 and 2001:db8::4/64.
|> |                 Manually assigned, or pre-configured with SNMP
|> |                 or according to stateless autoconf rfc4862.
|>
|> I do not understand why the router doesn't advertize prefixes. If so,
|the
|> hosts can autoconfigure globally unique addresses, with distinct
|prefixes.
|
|Sorry, I made an error indeed putting same prefix.  How about this
|updated picture with the prefixes being distinct:
|
|
|         -----  wifi "adhoc1"  ------  wifi "adhoc2"  -----
|        |Host1|---------------|Router|---------------|Host2|
|         ----- LL1         LL2 ------ LL3        LL4  -----
|               G1                                G4
|
|
|        "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode.
|                               Each is an IPv6 subnet.
|        LL1...4: IPv6 link-local addresses.
|                 Self-formed according to rfc2464.
|        G1, G4:  IPv6 global addresses, for example
|                 2001:db8:1::1/64 and
|                 2001:db8:2::4/64
|                 Manually assigned, or pre-configured with SNMP
|                 or formed according to stateless autoconf rfc4862;
|                 the prefixes are advertised by Router in RAs.
|
|> If not, and one configures globally unique addresses with same prefix
|on
|> different segments, (s)he is fully responsible for what services are
|and are
|> not provided. I would never design such a network.
|
|I agree.
|
|Alex
|
|> So I would say: no.
|>
|> My 2ct, Teco
|>
|>
|>
|> |Alex
|> |
|> |
|> |_______________________________________________
|> |Autoconf mailing list
|> [email-masked]
|> |https://www.ietf.org/mailman/listinfo/autoconf
|>
|>

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Thu, 26 Feb 2009 21:41:27 +0100

Hi Alex:

	One question below.

>                  the prefixes are advertised by Router in RAs.

Does this model only apply to Host-Router-Host scenarios? I mean, does
this model apply for Router-Router-Router scenarios? I fully agree the
model fits the first scenario, but I don't for the second, since
routers' mobility within the ad-hoc network would force them to change
prefixes often, I guess. For those scenarios it might be better to think
of addressing models in which MANET routers are configured with /128
(or /32 for IPv4) addresses, so they don't need to change their
addresses as a result of link changes.

Kind Regards,

Carlos

---

From: HyungJin Lim <[email-masked]>
Date: Fri, 27 Feb 2009 10:37:16 +0900

Hi Carlos,

This is Hyung-Jin, Lim
I have a question.
See the inline....

2009/2/27 Carlos Jesús Bernardos Cano <[email-masked]>

> addresses as a result of link changes.

 Does AUTOCONF not consider "ad-hoc network to Internet" scenario ?
If so, I agree your comment.
But if not, your pointing out is not reasonable I think.
In case of this situation, MANET routers may need to change their addresses
for connectivity/packet forwarding/packet routing to Internet.

Best regards,
Hyung-Jin Lim

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 27 Feb 2009 08:24:34 +0100

Hi Hyung-Jin,

	Answer inline below...

El vie, 27-02-2009 a las 10:37 +0900, HyungJin Lim escribió:
> In case of this situation, MANET routers may need to change their
> addresses for connectivity/packet forwarding/packet routing to
> Internet.

I think AUTOCONF considers connection to Internet, but even in that
case, I think my comment still holds. It's true that in a connected
scenario, the addressing depends on the infrastructure the MANET is
attached to, but this doesn't necessarily imply that inner nodes have to
change their addresses when move within the same MANET.

Kind Regards,

Carlos

---

From: HyungJin Lim <[email-masked]>
Date: Fri, 27 Feb 2009 17:01:10 +0900

Hi Carlos,

See inline...

> attached to,

 Right !

> but this doesn't necessarily imply that inner nodes have to

In here, I think there are many assumptions and requirements.
We should identify some aspects in relation to address configuration in
MANET and AUTOCONF.

Best regards,
Hyung-Jin, Lim

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 27 Feb 2009 10:41:26 +0100

All,

Here my opinion on the to be defined addressing model for MANETs / Autoconf.
I opened a separate thread, as I think (and hope) there will be an intensive
and productive discussion.

Some of us like an address model with /32 (IPv4) or /128 (IPv6)
prefix-length addresses attached to an interface to a multi-access link.
These addresses do not have an  Interface-ID. 

Such a model excludes usage of /64 "prefix swapping", which is IMHO an
extremely important attribute of IPv6. And it is specified as mandatory in
some standard track RFCs (e.g. RFC2464). 

We could discuss and analyze the effect of adopting the /128 (or /32) prefix
lengths for MANET interfaces, but I prefer taking this option as last
resort. I think there is a much more obvious option, using the RFC2464 model
for the MANET interface and /128 (or /32) for loopback interfaces. Both
would use high probability globally unique Interface IDs like EUI-64
(Extended Unique Identifier).

RFC4291   2.1.  Addressing Model:
 All interfaces are required to have at least one Link-Local unicast
 address (see Section 2.8 for additional required addresses).  A
 single interface may also have multiple IPv6 addresses of any type
 (unicast, anycast, and multicast) or scope.  Unicast addresses with a
 scope greater than link-scope are not needed for interfaces that are
 not used as the origin or destination of any IPv6 packets to or from
 non-neighbors.  This is sometimes convenient for point-to-point
 interfaces.

RFC2464   4.  Stateless Autoconfiguration:
 An IPv6 address prefix used for stateless autoconfiguration [ACONF]
 of an Ethernet interface must have a length of 64 bits.

It is not only because the RFC texts that I dislike the /128 in MANET
interfaces, it is also backward compatibility with current IP stacks (and
probably many applications). I think an interface with /128 is stub, and
thus protocols may assume that there is no other node on this link in the
same subnet. Think of ARP and routing protocols. I verified this with some
product, the outcome confirmed my assumption. I was able to adjust the
configuration on one platform so that it worked (Linux), but still the
indication is that the model has a high impact.

I think using /128 for loopback interfaces fits the requirements for the
addressing model. If a loopback interface is used, MANET interfaces do not
require a globally unique address. RFC4291 once more (out of section, also
cited above):
 Unicast addresses with a
 scope greater than link-scope are not needed for interfaces that are
 not used as the origin or destination of any IPv6 packets to or from
 non-neighbors.
So "host functionality" can be provided using the globally (or MANET local)
unique address assigned to a loopback address, or another non-MANET
interface.

This results in the following addressing model, where all nodes are routers:

    +-------+ wifi "adhoc1" +-------+ wifi "adhoc2" +-------+
    |Router1|>-------------<|Router2|>-------------<|Router3|
    +---L---+ LL1      LL21 +---L---+ LL22      LL3 +---L---+
        |M1                     |M2                     |M3

    "adhoc1" and "adhoc2": 802.11 SSIDs in "IBSS" mode.
    Each IBSS is an IPv6 subnet.

    L: Loopback interface.

    >, <: MANET interface.

    LL1, LL21, LL22, LL3: IPv6 link-local addresses.
       Self-formed according to rfc2464.

    M1, M2, M3: IPv6 MANET local addresses, for example
       FD01:db8::1/128, FD01:db8::2/128 and FD01:db8::3/128.
       Manually assigned, or pre-configured (e.g. with SNMP)
       or formed according to a to be defined [Autoconf for MANETs]
       protocol, with a to-be-defined prefix (e.g. ULA, RFC4193).

Although all nodes are marked as router, this does not imply all nodes
forward packets. All nodes run a MANET routing protocol for learning the
MANET topology.

In case one of the routers is connected to the Internet or private network,
this router can advertize a prefix in the MANET, and this information is
distributed in the MANET with an [Autoconf for MANETs] protocol.

                            Internet
                                |
                                |
                        +-------+-------+
                        | Access Router |
                        +-------+-------+
                                |
                                | | Prefix information
                                | V
                                |
    +-------+ wifi "adhoc1" +---+---+ wifi "adhoc2" +-------+
    |Router1|>-------------<|Router2|>-------------<|Router3|
    +---L---+ LL1      LL21 +---L---+ LL22      LL3 +---L---+
        |M1                     |M2                     |M3
        |G1                     |G2                     |G3
                   <-------           ------->
         Prefix information           Prefix information 

    G1, G2, G3: IPv6 globally unique addresses, for example
       2001:db8:G:1/128, 2001:db8:G:2/128 and 2001:db8:G:3/128.
       Formed according to a to be defined [Autoconf for MANETs]
       protocol, with the prefix provided by (via) the Access Router.

Multi-homing can easily be supported:

     ---+-------Internet--------+---
        |                       |
        |                       |
+-------+-------+       +-------+-------+
|Access Router H|       |Access Router G|
+-------+-------+       +-------+-------+
        |                       |
        ||Prefix information H  | |Prefix information G
        |V                      | V
        |                       |
    +---+---+ wifi "adhoc1" +---+---+ wifi "adhoc2" +-------+
    |Router1|>-------------<|Router2|>-------------<|Router3|
    +---L---+ LL1      LL21 +---L---+ LL22      LL3 +---L---+
        |M1                     |M2                     |M3
        |G1                     |G2                     |G3
        |H1                     |H2                     |H3
                   <-------           ------->
       Prefix information G         Prefix information G, H
              --------->
              Prefix information H

    H1, H2, H3: IPv6 globally unique addresses, for example
       2001:db8:H:1/128, 2001:db8:H:2/128 and 2001:db8:H:3/128.
       Formed according to a to be defined [Autoconf for MANETs]
       protocol, with the prefix provided by (via) Access Router H.

Note that the impact of the number of interfaces is minimal, the address
configuration of Router2 is very similar to Router1 and Router3. Also, the
status of the MANET interface has no impact on communication in case of
multi-homing and redundant paths. (OK, we might need MIP6 / HIP / SHIM6 or
application layer address swapping mechanisms).

It doesn't matter how many ad hoc segments there are. In the following
scenario, the link to Access router G disappeared, Router 3 disappeared and
a Router4 joined IBSS "adhoc1".

     ---+-------Internet------
        |                     
        |           
+-------+-------+      
|Access Router H|       
+-------+-------+        
        |                       
        ||Prefix information H  
        |V                     wifi "adhoc1"
        |                   <---------------------------v--------> 
 <------|--v---------------------->                     | 
        |<-|--------------------v-----------------------|--->
        |  |                    |                       |
    +---+--'+               +---'---+               +---'---+
    |Router1|>-------------<|Router2|>-------------<|Router4|
    +---L---+ LL1      LL21 +---L---+ LL22      LL4 +---L---+
        |M1                     |M2                     |M4
        |H1                     |H2                     |H4

              --------->               --------->
              Prefix information H     Prefix information H

Now, Router2 acts as a relay for Router4, so Router4 can reach Router1 and
the Internet. Router1 acts as Border Router for all nodes in the MANET.

I have some thoughts on IPv4 supports. Of course IPv4 misses lots of
flexibility that is used in above model. But there are ways to support it,
e.g. IPv4 link local (RFC3927) accompanied by some extended form of
duplicate address detection (passive checking routing tables). For globally
unique address assignment I think of DHCP-IPv4 over an IPv6 path, provided
as described above. (e.g. Router4 gets its /32 address for its loopback
interface from/via Access Router H, using M4 or H4 address and the IPv6
MANET protocol.

Any comments?
Teco.

|-----Oorspronkelijk bericht-----
|Van: Carlos Jesús Bernardos Cano [mailto:[email-masked]]
|Verzonden: donderdag 26 februari 2009 21:41
|Aan: Alexandru Petrescu
|CC: Teco Boot; [email-masked]
|Onderwerp: Re: [Autoconf] new charter
|
|Hi Alex:
|
|	One question below.
|
|El jue, 26-02-2009 a las 20:44 +0100, Alexandru Petrescu escribió:
|> Sorry, I made an error indeed putting same prefix.  How about this
|> updated picture with the prefixes being distinct:
|>
|>
|>          -----  wifi "adhoc1"  ------  wifi "adhoc2"  -----
|>         |Host1|---------------|Router|---------------|Host2|
|>          ----- LL1         LL2 ------ LL3        LL4  -----
|>                G1                                G4
|>
|>
|>         "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode.
|>                                Each is an IPv6 subnet.
|>         LL1...4: IPv6 link-local addresses.
|>                  Self-formed according to rfc2464.
|>         G1, G4:  IPv6 global addresses, for example
|>                  2001:db8:1::1/64 and
|>                  2001:db8:2::4/64
|>                  Manually assigned, or pre-configured with SNMP
|>                  or formed according to stateless autoconf rfc4862;
|>                  the prefixes are advertised by Router in RAs.
|>
|
|Does this model only apply to Host-Router-Host scenarios? I mean, does
|this model apply for Router-Router-Router scenarios? I fully agree the
|model fits the first scenario, but I don't for the second, since
|routers' mobility within the ad-hoc network would force them to change
|prefixes often, I guess. For those scenarios it might be better to think
|of addressing models in which MANET routers are configured with /128
|(or /32 for IPv4) addresses, so they don't need to change their
|addresses as a result of link changes.
|
|Kind Regards,
|
|Carlos
|
|--
| Carlos Jesús Bernardos Cano     http://www.netcoms.net
| GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
|++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|  WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
|        Deployment Experiences on Vehicular networks
|                  http://www.weedev.org/
|++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Feb 2009 11:08:09 +0100

Carlos Jesús Bernardos Cano a écrit :
>> |Host1|---------------|Router|---------------|Host2| ----- LL1
>> LL2 ------ LL3        LL4  ----- G1
>> G4
>> 
>> 
>> "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode. Each is an
>> IPv6 subnet. LL1...4: IPv6 link-local addresses. Self-formed
>> according to rfc2464. G1, G4:  IPv6 global addresses, for example 
>> 2001:db8:1::1/64 and 2001:db8:2::4/64 Manually assigned, or
>> pre-configured with SNMP or formed according to stateless autoconf
>> rfc4862; the prefixes are advertised by Router in RAs.
>> 
> 
> Does this model only apply to Host-Router-Host scenarios?

Yes.

> I mean, does this model apply for Router-Router-Router scenarios?

Something like this?:

        -------  wifi "adhoc1"  -------  wifi "adhoc2"  -------
       |Router1|---------------|Router2|---------------|Router3|
        ------ LL1          LL2 -------LL3          LL4 -------
               G1                                    G4

       G1, G4: ?

> I fully agree the model fits the first scenario, but I don't for the
>  second, since routers' mobility within the ad-hoc network would
> force them to change prefixes often, I guess.

Ah.  But before being forced to change a prefix, a Router could still
move around as much as it wants.  I think the limit is within 25m range,
as imposed by the wifi 50m area (25m for two routers in opposite
directions).  What do you think about this practical limit?

> For those scenarios it might be better to think of addressing models
> in which MANET routers are configured with /128 (or /32 for IPv4)
> addresses, so they don't need to change their addresses as a result
> of link changes.

Sorry... in the picture above the addresses are also /128.  It was an 
abbreviation for me to show only 2001:db8:1::1/64 assigned to Host1. 
The full notation should have been 2001:db8:1::/64 prefix and 
2001:db8:1::1/128.  Would the following picture satisfy the need for 
/128 addresses?:

         -----  wifi "adhoc1"  ------  wifi "adhoc2"  -----
        |Host1|---------------|Router|---------------|Host2|
         ----- LL1    P1   LL2 ------ LL3   P2   LL4  -----
               G1                                G4

        G1, G4:  IPv6 global addresses, for example
                 2001:db8:1::1/128 and
                 2001:db8:2::4/128
                 Manually assigned, or pre-configured with SNMP
                 or formed according to stateless autoconf rfc4862;
                 the prefixes are advertised by Router in RAs.
        P1, P2:  IPv6 global prefixes, for example
                 2001:db8:1::/64 and
                 2001:db8:2::/64
                 Manually assigned, or pre-configured with SNMP.

Or is it not what you mean?

I also don't understand why you think that if /128 addresses are 
assigned to routers then they don't need to change them as a result of 
link changes.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Feb 2009 11:12:16 +0100

HyungJin Lim a écrit :
> Hi Carlos,
>  
> This is Hyung-Jin, Lim
> I have a question.
> See the inline....
> 
>  
> 2009/2/27 Carlos Jesús Bernardos Cano <[email-masked] 
> <mailto:[email-masked]>>
> 
>     Hi Alex:
> 
>            One question below.
> 

Do you mean something like this?:

    -----  wifi "adhoc1"  ------  wifi "adhoc2"  --------     /
   |Host1|---------------|Router|---------------|Gatewway|---| Internet
    ----- LL1         LL2 ------ LL3        LL4  --------     \
          G1                                G4

Alex

---

From: HyungJin Lim <[email-masked]>
Date: Fri, 27 Feb 2009 19:46:15 +0900

Hi Alex,

Long time, no hear...
See inline....

2009/2/27 Alexandru Petrescu <[email-masked]>

> HyungJin Lim a écrit :
>
>> Hi Carlos,
>>  This is Hyung-Jin, Lim
>> I have a question.
>> See the inline....
>>
>>  2009/2/27 Carlos Jesús Bernardos Cano <[email-masked] <mailto:
>> [email-masked]>>
>>
>>
>>    Hi Alex:
>>
>>           One question below.
>>

Okey!!.

>                Self-formed according to rfc2464.

 Host1 may be a Router I think.
 This router may be mobile router.i.e, NEMO.
In disaster environment, this scenario is possible. Then, gateway will use
satelite channel.
Considering your case, Host1 will get his address from the upper router
(case 1) or the gateway (case 2).
According to which case is configured, this network has other aspects.

anyway,

Already, Teco described satifactory aspects relation to this situation in
previous message.
Do you also agree with his comments ?

Thanks,
Hyung-Jin, Lim

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 27 Feb 2009 12:05:12 +0100

Hi Alex,

Let's try to be accurate:

[skip]
|Sorry... in the picture above the addresses are also /128.  It was an
|abbreviation for me to show only 2001:db8:1::1/64 assigned to Host1.
|The full notation should have been 2001:db8:1::/64 prefix and
|2001:db8:1::1/128.  Would the following picture satisfy the need for
|/128 addresses?:

When prefix::/64 is assigned to a host, it configures a /64 address and not
an /128 address.
Routers may generate a /128 prefix-address, and advertize this in the
routing domain.
Some mechanisms should make sure the /128 routing prefix is unique, if
required. It is not required if the prefix is meant as anycast address,
routers may use "duplicate prefixes" if this is useful. I think anycast is
out-of-scope for [Autoconf], but we should be careful when specifying "MUST"
for prefix uniqueness. We should use "SHOULD" instead.

Teco.

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Feb 2009 14:07:24 +0100

Whoa, that's text Teco :-)  Let me see where can I practically agree 
with you:

Teco Boot a écrit :
[...]
> resort.

I fully agree with you.  I find /128 prefix lengths for subnets to be a 
departure from the typical less-than-64 prefix lengths for subnets.  It 
may even break networks.

> I think there is a much more obvious option, using the RFC2464 model

I don't agree going that way.  I think loopback addresses are for self 
addressing not for talking to other nodes.

[rfc4291 and 2464 citations]
> probably many applications).

I agree.

> require a globally unique address.

I'm not sure I could agree with the MANET interface being the loopback 
interface.  It sounds as a significant departure.

> RFC4291 once more (out of section, also
> cited above):
>  Unicast addresses with a

An address assigned to an address?  I think it risks many misunderstandings.

>     Each IBSS is an IPv6 subnet.

The MANET interface is a loopback interface?  I disagree.  The loopback 
interface is needed for local inter-process communication, I don't want 
that to go on to the network.

But, most importantly, why is there a need to add other special 
interfaces to the example pictured above?

>        FD01:db8::1/128, FD01:db8::2/128 and FD01:db8::3/128.

For my clarification, what's fd01? (2001:db8:: is a prefix for 
documentation rfc3849, ULA is fc00 rfc4193).

> distributed in the MANET with an [Autoconf for MANETs] protocol.

Why shouldn't it be distributed with DHCP and with OSPF, for example.

>                             Internet

Above, and in the following figures, I don't understand "--->, Prefix 
Information".  Is that RA?  Or OSPF?  Or routing protocol?   Or DHCP 
Prefix Delegation?

> Multi-homing can easily be supported:

maybe.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Feb 2009 14:16:49 +0100

Hi Hyung-Jin,

HyungJin Lim a écrit :
[...]
> Host1 may be a Router I think. This router may be mobile router.i.e,
> NEMO. In disaster environment, this scenario is possible. Then,
> gateway will use satelite channel. Considering your case, Host1 will
> get his address from the upper router (case 1) or the gateway (case
> 2). 

Something along these lines?:

  ------  wifi "adhoc1"  ------  wifi "adhoc2"  -------- Satelite /
|NEMOMR|---------------|Router|---------------|Gatewway|--------Int'net
  ------ LL1         LL2 ------ LL3        LL4  --------          \
         G1                                 G4

        LL1...4: IPv6 link-local addresses.
                 Self-formed according to rfc2464.
        G1: formed by NEMOMR either from RA sent by Router, or by
        DHCPv6 considering Router is a DHCPRelay and Gateway is
        a DHCPServer.
        G4: ?

I agree.

Alex

> 
> anyway,
> 
> Already, Teco described satifactory aspects relation to this
> situation in previous message. Do you also agree with his comments ?
> 
> Thanks, Hyung-Jin, Lim
> 
> 
> Alex
> 
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Feb 2009 14:24:10 +0100

> When prefix::/64 is assigned to a host, it configures a /64 address and not

I'm not sure I understand.

The prefix::/64 is typically assigned to a link, not to a host.  If a 
host is connected to that link then it configures a /128 address and a 
/64 subnet prefix, both "128" and "64" numbers are visible in its tables.

I don't understand why the need for /128 prefixes, why isn't the above 
/64-prefix-and-/128address not sufficient?

> Routers may generate a /128 prefix-address, and advertize this in the

A host-based route propagated and deleted throughout a domain?  I don't 
see the necessity of doing so.  Assuming the routers are mobile within 
25m ranges then they wouldn't need to change their addresses, thus no 
need to propagate host-based routes.

Do you agree we consider routers mobile only within 25m ranges?

Alex

---

From: HyungJin Lim <[email-masked]>
Date: Fri, 27 Feb 2009 23:04:53 +0900

Hi Alex,

>       DHCPv6 considering Router is a DHCPRelay and Gateway is

   G4 is Router? or G4 is Gateway ? I guess G4 is located on the link to
Gateway, in side of Router.
First of all, Gateway now has topologically correct address(TCA) to
Internet.
Also, Router should have TCA by any address configuration mechanisms.
For example, RA sent by Gateway, or any other address conf. mechanisms.
Is it right ?

Hyung-Jin, Lim

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Feb 2009 15:27:24 +0100

HyungJin Lim a écrit :
> Hi Alex,
> 
> 2009/2/27 Alexandru Petrescu <[email-masked] 
> <mailto:[email-masked]>>
> 
>     Hi Hyung-Jin,
> 
>     HyungJin Lim a écrit :
>     [...]
> 
>    G4 is Router? or G4 is Gateway ?

G4 denotes the Global address of the Gateway, on the wifi "adhoc2" subnet.

> I guess G4 is located on the link to 

Yes, Gateway has a topologically-correct address, TCA if you wish; on 
its Satelite  interface.

> Also, Router should have TCA by any address configuration mechanisms.

Why should Router have a TCA?

> For example, RA sent by Gateway, or any other address conf. mechanisms.

I'm not sure why the intermediary Router should have any other address 
than its link-local addresses.

Alex

---

From: HyungJin Lim <[email-masked]>
Date: Fri, 27 Feb 2009 23:45:43 +0900

> HyungJin Lim a écrit :
>
>> Hi Alex,
>>
>> 2009/2/27 Alexandru Petrescu <[email-masked] <mailto:
>> [email-masked]>>
>>
>>    Hi Hyung-Jin,
>>
>>    HyungJin Lim a écrit :
>>    [...]
>>
> I guess G4 is located on the link to Gateway, in side of Router.
> Yes, Gateway has a topologically-correct address, TCA if you wish; on its
> Satelite  interface.
>

  Is the Router fixed one ? I think "no". Do you assume this router only has
a function for packet routing ? I don't think so. This router also should be
managed from remote location in any case.
In realistic MANET environment, exactly, mesh network, this router can have
some roles as host I think.

I think we consider MANET-like situation.

> I'm not sure why the intermediary Router should have any other address than
> its link-local addresses.
>

Please refers to the above my opinion.

Hyung-Jin Lim

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Feb 2009 15:58:44 +0100

------  wifi "adhoc1"  ------  wifi "adhoc2"  -------- Satelite /
|NEMOMR|---------------|Router|---------------|Gatewway|--------Int'net
  ------ LL1         LL2 ------ LL3        LL4  --------  TCA     \
         G1                                 G4

        LL1...4: IPv6 link-local addresses.
                 Self-formed according to rfc2464.
        G1: address formed by NEMOMR either from RA sent by Router, or
            by DHCPv6 considering Router is a DHCPRelay and Gateway is
            a DHCPServer.
        G4: ?
        TCA: Topologically-Correct Address, for Gateway.  It can be
             manually configured on Gateway, or DHCP, or stateless
             autoconf.

HyungJin Lim a écrit :
> Is the Router fixed one ? I think "no".

Right - Router is not fixed: it can move in a circular area of radius
25m. No more than that. Is this sufficient?

> Do you assume this router only has a function for packet routing ?

Mostly yes.

> I don't think so. This router also should be managed from remote 
> location in any case. In realistic MANET environment, exactly, mesh 
> network, this router can have some roles as host I think.

Ok, Router should be contacted from the Internet.  Then we should find 
some practical way to configure G addresses for Router too. I'm not sure 
how to come up with G addresses for Router, for the above topology.

I'm not sure how to configure G4 on Gateway either.

Alex

>     I'm not sure why the intermediary Router should have any other
>     address than its link-local addresses.
> 
>

---

From: HyungJin Lim <[email-masked]>
Date: Sat, 28 Feb 2009 00:04:58 +0900

> I don't think so. This router also should be managed from remote location
>> in any case. In realistic MANET environment, exactly, mesh network, this
>> router can have some roles as host I think.
>>
>
> Ok, Router should be contacted from the Internet.  Then we should find some
> practical way to configure G addresses for Router too. I'm not sure how to
> come up with G addresses for Router, for the above topology.
>

  If the gateway has one hop distance from the router, and has IPv6
capability,
 then, the router can get TCA from the gateway I think.
This operation is the basic operation.
 Is it right ?

Hyung-Jin, Lim

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Feb 2009 16:18:46 +0100

------  wifi "adhoc1"  ------  wifi "adhoc2"  -------- Satelite /
|NEMOMR|---------------|Router|---------------|Gatewway|--------Int'net
  ------ LL1         LL2 ------ LL3        LL4  --------  TCA1    \
         G1                                 G4

HyungJin Lim a écrit :
> capability,  then, the router can get TCA from the gateway I think.

Yes, it could. But in that case we should come up with a means for
Gateway to obtain not only a TCA1 from the Internet but additionally an
entire prefix. Out of this prefix Gateway could form its G4 and put it
in RA, and finally Router forms its G address (TCA2 let's say). Without
that prefix Router couldn't get a TCA2 from Gateway.

(Now I realize that by "G" and "TCA" we actually mean the same thing; we
should use just one.)

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 27 Feb 2009 18:01:26 +0100

Inline.

|-----Oorspronkelijk bericht-----
|Van: Alexandru Petrescu [mailto:[email-masked]]
|Verzonden: vrijdag 27 februari 2009 14:24
|Aan: Teco Boot
|CC: 'Alexandru Petrescu'; [email-masked]
|Onderwerp: Re: [Autoconf] new charter
|
|Teco Boot a écrit :
|> Hi Alex,
|>
|> Let's try to be accurate:
|>
|> [skip]
|> |Sorry... in the picture above the addresses are also /128.  It was an
|> |abbreviation for me to show only 2001:db8:1::1/64 assigned to Host1.
|> |The full notation should have been 2001:db8:1::/64 prefix and
|> |2001:db8:1::1/128.  Would the following picture satisfy the need for
|> |/128 addresses?:
|>
|> When prefix::/64 is assigned to a host, it configures a /64 address
|and not
|> an /128 address.
|
|I'm not sure I understand.
|
|The prefix::/64 is typically assigned to a link, not to a host.  If a
|host is connected to that link then it configures a /128 address and a
|/64 subnet prefix, both "128" and "64" numbers are visible in its
|tables.
|
|I don't understand why the need for /128 prefixes, why isn't the above
|/64-prefix-and-/128address not sufficient?

This is interesting. I meant generating an address in the /64 prefix.
I don't know what is specified in RFCs. I checked behavior on Vista, 
Linux and IOS: 
  o Linux (debian lenny) adds a /128 prefix in the routing table, to 
    the loopback interface, similar to what I propose in my addressing 
    model mail. It also adds a /64 address-prefix to the Ethernet interface
    this is a bit weird, as two interfaces has the same address configured.

  o Vista assigns addresses to the Ethernet interface (in my case),
    and adds /128 prefixes in the routing table. Vista also adds the 
    /64 in the routing table.
  o IOS behavior is as Vista, addresses to interfaces and /128 in 
    routing table.

Details on Linux behavior: the /64 are on Ethernet (eth0) and the /128 
are on loopback (lo).

# ifconfig lo | egrep 'inet6|encap'
lo        Link encap:Local Loopback  
          inet6 addr: ::1/128 Scope:Host
# netstat -6rn | grep 128
::1/128                        ::       Un   0   1    17 lo
2001:db8:1:0:20c:29ff:fee3:bdf5/128 ::  Un   0   1    11 lo
fe80::20c:29ff:fee3:bdf5/128   ::       Un   0   1     3 lo
fe80::20c:29ff:fee3:bdff/128   ::       Un   0   1     0 lo

# ifconfig eth0 | egrep 'inet6|encap'
eth0      Link encap:Ethernet  HWaddr 00:0c:29:e3:bd:f5  
          inet6 addr: 2001:db8:1:0:20c:29ff:fee3:bdf5/64 Scope:Global
          inet6 addr: fe80::20c:29ff:fee3:bdf5/64 Scope:Link
# netstat -6rn | grep 64 
2001:db8:1::/64                ::       UAe  256 0    15 eth0
fe80::/64                      ::       U    256 0     0 eth0
fe80::/64                      ::       U    256 0     0 eth1

Conclusion: I was wrong with my statement. Linux behaves as I mentioned, 
other IPv6 stacks have different characteristics.

|> Routers may generate a /128 prefix-address, and advertize this in the
|> routing domain.
|
|A host-based route propagated and deleted throughout a domain?  I don't
|see the necessity of doing so.  Assuming the routers are mobile within
|25m ranges then they wouldn't need to change their addresses, thus no
|need to propagate host-based routes.

If the /128 is not propagated, there will be no multi-hop network. In a
MANET, I expect nodes to run a MANET Routing protocol and forward packets.
In ad hoc networks, one (you ?) would say nodes could be hosts or Mobile
Routers acting as hosts. 

|Do you agree we consider routers mobile only within 25m ranges?

Absolutely not. For me, 25km is a reasonable distance! Just 10^3 times the
distance and 10^6 times the power per bit (single hop) or 10^3 times the
power per bit if multi-hop is enabled (and 1000 intermediate nodes....).
Just physical laws here.

Teco.

|Alex
|
|> Some mechanisms should make sure the /128 routing prefix is unique, if
|> required. It is not required if the prefix is meant as anycast
|address,
|> routers may use "duplicate prefixes" if this is useful. I think
|anycast is
|> out-of-scope for [Autoconf], but we should be careful when specifying
|"MUST"
|> for prefix uniqueness. We should use "SHOULD" instead.
|>
|> Teco.
|>
|>
|>
|>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Feb 2009 18:44:52 +0100

[Thanks for the details Linux/Vista/IOS routing tables!  I didn't know
  all that, only for linux]

Teco Boot a écrit :
>>> Routers may generate a /128 prefix-address, and advertize this in
>>>  the routing domain.
> 
>> A host-based route propagated and deleted throughout a domain? I 
>> don't see the necessity of doing so. Assuming the routers are 
>> mobile within 25m ranges then they wouldn't need to change their 
>> addresses, thus no need to propagate host-based routes.
> 
> If the /128 is not propagated, there will be no multi-hop network.

Well I disagree.  In the multi-hop network below only /64 prefixes are 
present in Routers' routing tables, no /128 (host-based) routes:

   -----  wifi "adhoc1"  ------  wifi "adhoc2"  ------- "adhoc3"-----
  |Host1|---------------|Router|---------------|Router2|-------|Host2|
   ----- LL1    P1   LL2 ------ LL3   P2   LL4  -------LL5 P3  LL6---
         G1                                                    G4

           P1, P2, P3: /64 prefixes, such as:
                       2001:db8:1::/64
                       2001:db8:2::/64 and
                       2001:db8:3::/64

Would this kind of use of /64 prefixes alleviate the need to 
propagate/delete /128 prefixes throughout the network?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Feb 2009 18:47:25 +0100

Teco Boot wrote:
> In a MANET, I expect nodes to run a MANET Routing protocol and
> forward packets.

Well I agree with the last part: MANET nodes do forward packets.  But I 
don't agree with the first part: in a MANET I could configure static 
routes, not necessarily running a MANET routing protocol.

> In ad hoc networks, one (you ?) would say nodes could be hosts or
> Mobile Routers acting as hosts.

Yes.  If the future charter rules these kinds of MANET networks which 
are non-MANET-routing-protocol then I'll go away :-)

> Absolutely not. For me, 25km is a reasonable distance!

But is that MANET?  Or is it just a 25km subnet?

> Just 10^3 times the distance and 10^6 times the power per bit (single
> hop) or 10^3 times the power per bit if multi-hop is enabled (and
> 1000 intermediate nodes....). Just physical laws here.

Well I agree the physical laws are so.  But I disagree to have 25km 
MANETs in the Charter.  I agree with "25m IPv6 subnets", if they were 
explicitely stated so in the charter.

Alex

Proposed charter pasted below:
J. Arkko wrote earlier:
> model for ad hoc networks.
> 
> Once this sole work item is completed, the group can be rechartered
> to work on additional issues.
> 
> Goals and Milestones:
> 
> networks Sep 2009 Submit address configuration draft to IESG as
> Informational or close WG.
>

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 27 Feb 2009 18:49:40 +0100

Inline.

|-----Oorspronkelijk bericht-----
|Van: Alexandru Petrescu [mailto:[email-masked]]
|Verzonden: vrijdag 27 februari 2009 14:07
|Aan: Teco Boot
|CC: [email-masked]; [email-masked]
|Onderwerp: Re: Autoconf addressing model
|
|Whoa, that's text Teco :-)  Let me see where can I practically agree
|with you:
|
|Teco Boot a écrit :
|[...]
|> We could discuss and analyze the effect of adopting the /128 (or /32)
|prefix
|> lengths for MANET interfaces, but I prefer taking this option as last
|> resort.
|
|I fully agree with you.  I find /128 prefix lengths for subnets to be a
|departure from the typical less-than-64 prefix lengths for subnets.  It
|may even break networks.
|
|> I think there is a much more obvious option, using the RFC2464 model
|> for the MANET interface and /128 (or /32) for loopback interfaces.
|Both
|> would use high probability globally unique Interface IDs like EUI-64
|> (Extended Unique Identifier).
|
|I don't agree going that way.  I think loopback addresses are for self
|addressing not for talking to other nodes.

See other mail also, on Linux.
I think loopback addresses are often used for stable connections to routers,
where interfaces flap but due to redundancy there are alternative paths.
When addresses are used on physical interfaces, and the interface goes down,
connectivity might be broken. I think using router loopback interface
addresses for talking to other nodes is best current practice. It is a basic
principle in my network designs.

RFC3871:
   It is a common practice among operators to configure "loopback"
   pseudo-interfaces to use as the source and destination of
   management traffic.  These are preferred to physical interfaces
   because they provide a stable, routable address.  Services bound
   to the addresses of physical interface addresses might become
   unreachable if the associated hardware goes down, is removed, etc.

I think the same arguments are valid for non-management traffic in a MANET.

|[rfc4291 and 2464 citations]
|> It is not only because the RFC texts that I dislike the /128 in MANET
|> interfaces, it is also backward compatibility with current IP stacks
|(and
|> probably many applications).
|
|I agree.
|
|> I think using /128 for loopback interfaces fits the requirements for
|the
|> addressing model. If a loopback interface is used, MANET interfaces do
|not
|> require a globally unique address.
|
|I'm not sure I could agree with the MANET interface being the loopback
|interface.  It sounds as a significant departure.

The MANET interface is not a loopback interface! It is the interface to a
radio, e.g. 802.11 NIC in IBSS mode (your wifi adhoc).

|> RFC4291 once more (out of section, also
|> cited above):
|>  Unicast addresses with a
|>  scope greater than link-scope are not needed for interfaces that are
|>  not used as the origin or destination of any IPv6 packets to or from
|>  non-neighbors.
|> So "host functionality" can be provided using the globally (or MANET
|local)
|> unique address assigned to a loopback address, or another non-MANET
|> interface.
|
|An address assigned to an address?  I think it risks many
|misunderstandings.

Typo, I meant:
So "host functionality" can be provided using the globally (or MANET local)
unique address assigned to a loopback interface, or another non-MANET
interface. 

|> This results in the following addressing model, where all nodes are
|routers:
|>
|>     +-------+ wifi "adhoc1" +-------+ wifi "adhoc2" +-------+
|>     |Router1|>-------------<|Router2|>-------------<|Router3|
|>     +---L---+ LL1      LL21 +---L---+ LL22      LL3 +---L---+
|>         |M1                     |M2                     |M3
|>
|>     "adhoc1" and "adhoc2": 802.11 SSIDs in "IBSS" mode.
|>     Each IBSS is an IPv6 subnet.
|>
|>     L: Loopback interface.
|>
|>     >, <: MANET interface.
|
|The MANET interface is a loopback interface?  I disagree.  The loopback
|interface is needed for local inter-process communication, I don't want
|that to go on to the network.

There is some misunderstanding her, the MANET interface is NOT a loopback
interface. It is an interface that enables communication to other MANET
nodes.

|But, most importantly, why is there a need to add other special
|interfaces to the example pictured above?

I think this model solves some problems.
  o The assigned address can be used over whatever interface.
    This fulfills a requirement of "ad hoc", something works without
planning.
  o Connectivity is not broken if a path swap occurs (the RFC3781 loopback
BCP)
  o It provides some scalability, as only a single address is needed, 
    even if multiple interfaces are used.
  o Applications are not confused by "host prefixes" to a link, 
    where other nodes are reachable. I tested this with linux and IPv4 with
/32. 
    Problems started with ARP processing, and I swapped to another
addressing 
    model immediately.

|>     LL1, LL21, LL22, LL3: IPv6 link-local addresses.
|>        Self-formed according to rfc2464.
|>
|>     M1, M2, M3: IPv6 MANET local addresses, for example
|>        FD01:db8::1/128, FD01:db8::2/128 and FD01:db8::3/128.
|
|For my clarification, what's fd01? (2001:db8:: is a prefix for
|documentation rfc3849, ULA is fc00 rfc4193).

ULA prefix is FC00::/7. 8th but is L, set to 1 if locally assigned. So all
ULA would start with FD, the FC is for the future where a registration body
maintains the universal uniqueness.

0xFC + 0x01 = 0xFD.

|>        Manually assigned, or pre-configured (e.g. with SNMP)
|>        or formed according to a to be defined [Autoconf for MANETs]
|>        protocol, with a to-be-defined prefix (e.g. ULA, RFC4193).
|>
|> Although all nodes are marked as router, this does not imply all nodes
|> forward packets. All nodes run a MANET routing protocol for learning
|the
|> MANET topology.
|>
|>
|> In case one of the routers is connected to the Internet or private
|network,
|> this router can advertize a prefix in the MANET, and this information
|is
|> distributed in the MANET with an [Autoconf for MANETs] protocol.
|
|Why shouldn't it be distributed with DHCP and with OSPF, for example.

In a MANET, there are some problems with standard OSPF. OSPF-MANET is
perfectly fine to use in a MANET.

DHCP (with relay) can be used for "pull", but there is a problem finding the
best relay agent. I think there should be a mechanism that informs nodes of
available facilities, e.g. shortest path to a DHCP server. Updating ND RA
with some info for finding a DHCP server looks a good idea to me, and I
updated my Border Router Discovery Protocol (BRDP) [Autoconf] proposal for
DHCP support already.

However, there is a chicken - egg problem. In a wired network, the DHCP
client - DHCP relay agent relation is stable. This is certainly not the case
in a MANET. Therefore, I think a DHCP client should start with building
reliable communication to a DHCP server, and the MANET routing protocols can
provide such. But the MANET routing protocol needs a prefix that corresponds
to this MANET node. For this reason, I think it makes sense to start with
generating a prefix without DHCP, and we could use a prefix "push model"
here.
Anyway, ND /SLAAC works with the "push model" already, so nothing new here.

|>
|>                             Internet
|>                                 |
|>                                 |
|>                         +-------+-------+
|>                         | Access Router |
|>                         +-------+-------+
|>                                 |
|>                                 | | Prefix information
|>                                 | V
|>                                 |
|>     +-------+ wifi "adhoc1" +---+---+ wifi "adhoc2" +-------+
|>     |Router1|>-------------<|Router2|>-------------<|Router3|
|>     +---L---+ LL1      LL21 +---L---+ LL22      LL3 +---L---+
|>         |M1                     |M2                     |M3
|>         |G1                     |G2                     |G3
|>                    <-------           ------->
|>          Prefix information           Prefix information
|>
|>
|>     G1, G2, G3: IPv6 globally unique addresses, for example
|>        2001:db8:G:1/128, 2001:db8:G:2/128 and 2001:db8:G:3/128.
|>        Formed according to a to be defined [Autoconf for MANETs]
|>        protocol, with the prefix provided by (via) the Access Router.
|
|Above, and in the following figures, I don't understand "--->, Prefix
|Information".  Is that RA?  Or OSPF?  Or routing protocol?   Or DHCP
|Prefix Delegation?

This is under discussion, and the reason we have an [Autoconf] WG.
There are proposals that rely on a routing protocol, but the old charter
mentioned being independent of a routing protocol.
My BRDP used ND as a transport vehicle, and prefix information was carried
in "Border Router Information Option" which is a look-alike of the Prefix
Information Option. PIO is single-hop, BRIO is multi-hop. 

|> Multi-homing can easily be supported:
|
|maybe.

Just write some code and compile :-)

The problem is border router swapping. If session continuity is required, we
need something like MIP/NEMO, HIP, SHIM6 or NAT / NAT66 at the border. This
is not our focus, I think.

Teco.

|Alex
|
|>
|>      ---+-------Internet--------+---
|>         |                       |
|>         |                       |
|> +-------+-------+       +-------+-------+
|> |Access Router H|       |Access Router G|
|> +-------+-------+       +-------+-------+
|>         |                       |
|>         ||Prefix information H  | |Prefix information G
|>         |V                      | V
|>         |                       |
|>     +---+---+ wifi "adhoc1" +---+---+ wifi "adhoc2" +-------+
|>     |Router1|>-------------<|Router2|>-------------<|Router3|
|>     +---L---+ LL1      LL21 +---L---+ LL22      LL3 +---L---+
|>         |M1                     |M2                     |M3
|>         |G1                     |G2                     |G3
|>         |H1                     |H2                     |H3
|>                    <-------           ------->
|>        Prefix information G         Prefix information G, H
|>               --------->
|>               Prefix information H
|>
|>     H1, H2, H3: IPv6 globally unique addresses, for example
|>        2001:db8:H:1/128, 2001:db8:H:2/128 and 2001:db8:H:3/128.
|>        Formed according to a to be defined [Autoconf for MANETs]
|>        protocol, with the prefix provided by (via) Access Router H.
|>
|>
|> Note that the impact of the number of interfaces is minimal, the
|address
|> configuration of Router2 is very similar to Router1 and Router3. Also,
|the
|> status of the MANET interface has no impact on communication in case
|of
|> multi-homing and redundant paths. (OK, we might need MIP6 / HIP /
|SHIM6 or
|> application layer address swapping mechanisms).
|>
|> It doesn't matter how many ad hoc segments there are. In the following
|> scenario, the link to Access router G disappeared, Router 3
|disappeared and
|> a Router4 joined IBSS "adhoc1".
|>
|>
|>
|>      ---+-------Internet------
|>         |
|>         |
|> +-------+-------+
|> |Access Router H|
|> +-------+-------+
|>         |
|>         ||Prefix information H
|>         |V                     wifi "adhoc1"
|>         |                   <---------------------------v-------->
|>  <------|--v---------------------->                     |
|>         |<-|--------------------v-----------------------|--->
|>         |  |                    |                       |
|>     +---+--'+               +---'---+               +---'---+
|>     |Router1|>-------------<|Router2|>-------------<|Router4|
|>     +---L---+ LL1      LL21 +---L---+ LL22      LL4 +---L---+
|>         |M1                     |M2                     |M4
|>         |H1                     |H2                     |H4
|>
|>               --------->               --------->
|>               Prefix information H     Prefix information H
|>
|>
|> Now, Router2 acts as a relay for Router4, so Router4 can reach Router1
|and
|> the Internet. Router1 acts as Border Router for all nodes in the
|MANET.
|>
|>
|> I have some thoughts on IPv4 supports. Of course IPv4 misses lots of
|> flexibility that is used in above model. But there are ways to support
|it,
|> e.g. IPv4 link local (RFC3927) accompanied by some extended form of
|> duplicate address detection (passive checking routing tables). For
|globally
|> unique address assignment I think of DHCP-IPv4 over an IPv6 path,
|provided
|> as described above. (e.g. Router4 gets its /32 address for its
|loopback
|> interface from/via Access Router H, using M4 or H4 address and the
|IPv6
|> MANET protocol.
|>
|>
|> Any comments?
|> Teco.
|>
|>
|>
|> |-----Oorspronkelijk bericht-----
|> |Van: Carlos Jesús Bernardos Cano [mailto:[email-masked]]
|> |Verzonden: donderdag 26 februari 2009 21:41
|> |Aan: Alexandru Petrescu
|> |CC: Teco Boot; [email-masked]
|> |Onderwerp: Re: [Autoconf] new charter
|> |
|> |Hi Alex:
|> |
|> |	One question below.
|> |
|> |El jue, 26-02-2009 a las 20:44 +0100, Alexandru Petrescu escribió:
|> |> Sorry, I made an error indeed putting same prefix.  How about this
|> |> updated picture with the prefixes being distinct:
|> |>
|> |>
|> |>          -----  wifi "adhoc1"  ------  wifi "adhoc2"  -----
|> |>         |Host1|---------------|Router|---------------|Host2|
|> |>          ----- LL1         LL2 ------ LL3        LL4  -----
|> |>                G1                                G4
|> |>
|> |>
|> |>         "adhoc1" and "adhoc2": 802.11 ESSIDs in "ad-hoc" mode.
|> |>                                Each is an IPv6 subnet.
|> |>         LL1...4: IPv6 link-local addresses.
|> |>                  Self-formed according to rfc2464.
|> |>         G1, G4:  IPv6 global addresses, for example
|> |>                  2001:db8:1::1/64 and
|> |>                  2001:db8:2::4/64
|> |>                  Manually assigned, or pre-configured with SNMP
|> |>                  or formed according to stateless autoconf rfc4862;
|> |>                  the prefixes are advertised by Router in RAs.
|> |>
|> |
|> |Does this model only apply to Host-Router-Host scenarios? I mean,
|does
|> |this model apply for Router-Router-Router scenarios? I fully agree
|the
|> |model fits the first scenario, but I don't for the second, since
|> |routers' mobility within the ad-hoc network would force them to
|change
|> |prefixes often, I guess. For those scenarios it might be better to
|think
|> |of addressing models in which MANET routers are configured with /128
|> |(or /32 for IPv4) addresses, so they don't need to change their
|> |addresses as a result of link changes.
|> |
|> |Kind Regards,
|> |
|> |Carlos
|> |
|> |--
|> | Carlos Jesús Bernardos Cano     http://www.netcoms.net
|> | GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
|> |++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|> |  WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
|> |        Deployment Experiences on Vehicular networks
|> |                  http://www.weedev.org/
|> |++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|>
|>

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 27 Feb 2009 19:05:35 +0100

Inline.

|-----Oorspronkelijk bericht-----
|Van: Alexandru Petrescu [mailto:[email-masked]]
|Verzonden: vrijdag 27 februari 2009 18:45
|Aan: Teco Boot
|CC: [email-masked]
|Onderwerp: Re: practical addressing (was: [Autoconf] new charter)
|
|[Thanks for the details Linux/Vista/IOS routing tables!  I didn't know
|  all that, only for linux]
|
|Teco Boot a écrit :
|>>> Routers may generate a /128 prefix-address, and advertize this in
|>>>  the routing domain.
|>
|>> A host-based route propagated and deleted throughout a domain? I
|>> don't see the necessity of doing so. Assuming the routers are
|>> mobile within 25m ranges then they wouldn't need to change their
|>> addresses, thus no need to propagate host-based routes.
|>
|> If the /128 is not propagated, there will be no multi-hop network.
|
|Well I disagree.  In the multi-hop network below only /64 prefixes are
|present in Routers' routing tables, no /128 (host-based) routes:
|
|
|   -----  wifi "adhoc1"  ------  wifi "adhoc2"  ------- "adhoc3"-----
|  |Host1|---------------|Router|---------------|Router2|-------|Host2|
|   ----- LL1    P1   LL2 ------ LL3   P2   LL4  -------LL5 P3  LL6---
|         G1                                                    G4
|
|           P1, P2, P3: /64 prefixes, such as:
|                       2001:db8:1::/64
|                       2001:db8:2::/64 and
|                       2001:db8:3::/64
|
|Would this kind of use of /64 prefixes alleviate the need to
|propagate/delete /128 prefixes throughout the network?

Your routers need two wifi interfaces. Often, there is only one wifi
interface. The MANET Routing protocol provides connectivity between nodes
that are out of range from each other, via relay nodes that are in range.

Using many distinct SSIDs can introduce problems, e.g. Host-1 and Host-2 are
near each other, but on a different SSID:

  -------  wifi "adhoc1"  -----   ????   -----  "adhoc2" --------
 |Router1|---------------|Host1|--/  /--|Host2|---------|Router2|
  ------- LL2    P1     LL1 ---          ----LL6   P2  LL6------
                        G1                   G4

Router1 and Router2 are out of range. So R1 <--> H2 and H1 <--> R2.
Host1 MUST communicate to Host2, this is critical (live or dead).

Teco.

|Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Feb 2009 19:17:57 +0100

Teco Boot a écrit :
[...]
>>> I think there is a much more obvious option, using the RFC2464
>>> model for the MANET interface and /128 (or /32) for loopback
>>> interfaces. Both would use high probability globally unique
>>> Interface IDs like EUI-64 (Extended Unique Identifier).
>> 
>> I don't agree going that way.  I think loopback addresses are for
>> self addressing not for talking to other nodes.
> 
> See other mail also, on Linux. I think loopback addresses are often
> used for stable connections to routers, where interfaces flap but due
> to redundancy there are alternative paths.

I think you mean a virtual interface actually, not necessarily the
loopback interface (and yes, lo is a 'virtual' interface).

Not all virtual interfaces are loopback.

> RFC3871: It is a common practice among operators to configure
> "loopback" pseudo-interfaces to use as the source and destination of 
> management traffic.

Well that RFC is completely wrong please someone correct it.  The
loopback address is ::1 and it can't be used to communicate outside the
computer. Yes pseudo-interface (and maybe 'virtual') but no loopback.

And yes the interface in the routing table for the entry address/128 is
'lo' which is yes the loopback interface but no, never will that address
be in the src nor dst fields of any packet leaving the computer (other
than encapsulated maybe).

>>> It is not only because the RFC texts that I dislike the /128 in
>>> MANET interfaces, it is also backward compatibility with current
>>> IP stacks (and probably many applications).
>> 
>> I agree.
>> 
>>> I think using /128 for loopback interfaces fits the requirements
>>> for the addressing model. If a loopback interface is used, MANET
>>> interfaces do not require a globally unique address.
>> 
>> I'm not sure I could agree with the MANET interface being the
>> loopback interface.  It sounds as a significant departure.
> 
> The MANET interface is not a loopback interface! It is the interface
> to a radio, e.g. 802.11 NIC in IBSS mode (your wifi adhoc).

I agree with this.  But in the immediately above text you're saying
"using /128 for loopback interfaces fits" - I think you meant 'virtual'
interface, not 'loopback' interface, right?

>>> RFC4291 once more (out of section, also cited above): Unicast
>>> addresses with a scope greater than link-scope are not needed for
>>> interfaces that are not used as the origin or destination of any
>>> IPv6 packets to or from non-neighbors. So "host functionality"
>>> can be provided using the globally (or MANET local) unique
>>> address assigned to a loopback address, or another non-MANET 
>>> interface.
>> 
> Typo, I meant: So "host functionality" can be provided using the
> globally (or MANET local) unique address assigned to a loopback
> interface, or another non-MANET interface.

Ok.

> I think this model solves some problems. o The assigned address can
> be used over whatever interface. This fulfills a requirement of "ad
> hoc", something works without planning.

I thought the unplanned aspect could be treated by IPv6 stateless
autoconf and IPv6-over-Ethernet link-local addresses.

> o Connectivity is not broken if a path swap occurs (the RFC3781
> loopback BCP) o It provides some scalability, as only a single
> address is needed, even if multiple interfaces are used. o
> Applications are not confused by "host prefixes" to a link, where
> other nodes are reachable. I tested this with linux and IPv4 with 
> /32.

Before deciding on the solution (address assigned to a virtual
interface) I need to udnerstand how path swap occurs and why.

> addressing model immediately.

> ULA prefix is FC00::/7. 8th but is L, set to 1 if locally assigned.
> So all ULA would start with FD, the FC is for the future where a
> registration body maintains the universal uniqueness.
> 
> 0xFC + 0x01 = 0xFD.

Ah!  So a correct ULA address would be fd01::1/128?  In this sense, when
drawing pictures I have a choice between fd01::1/128 ULA and
2001:db8::1/128 global address, it's ambiguous.

>>> Manually assigned, or pre-configured (e.g. with SNMP) or formed
>>> according to a to be defined [Autoconf for MANETs] protocol, with
>>> a to-be-defined prefix (e.g. ULA, RFC4193).
>>> 
>>> Although all nodes are marked as router, this does not imply all
>>> nodes forward packets. All nodes run a MANET routing protocol for
>>> learning
>> the
>>> MANET topology.
>>> 
>>> 
>>> In case one of the routers is connected to the Internet or
>>> private
>> network,
>>> this router can advertize a prefix in the MANET, and this
>>> information
>> is

Ok.

> DHCP (with relay) can be used for "pull", but there is a problem
> finding the best relay agent. I think there should be a mechanism
> that informs nodes of available facilities, e.g. shortest path to a
> DHCP server. Updating ND RA with some info for finding a DHCP server
> looks a good idea to me, and I updated my Border Router Discovery
> Protocol (BRDP) [Autoconf] proposal for DHCP support already.

Sounds interesting.  But I think normal DHCP could run ok, provided the
Relays know the address of the Server.  In a first practical step would
be to manually configure the Server's address on each Relays.

> However, there is a chicken - egg problem. In a wired network, the
> DHCP client - DHCP relay agent relation is stable. This is certainly
> not the case in a MANET.

Well it is the case in a MANET made of 25meter IPv6 subnets.

> Therefore, I think a DHCP client should start with building reliable
> communication to a DHCP server, and the MANET routing protocols can 
> provide such. But the MANET routing protocol needs a prefix that
> corresponds to this MANET node. For this reason, I think it makes
> sense to start with generating a prefix without DHCP, and we could
> use a prefix "push model" here.

Well I think this is indeed a very chickeneggy problem: are addresses in
place before routing is, or vice-versa.  But what would we do in
practice?  Certainly we'd manually assign some addresses - let's see
these cases first.

>> Above, and in the following figures, I don't understand "--->,
>> Prefix Information".  Is that RA?  Or OSPF?  Or routing protocol?
>> Or DHCP Prefix Delegation?
> 
> There are proposals that rely on a routing protocol, but the old
> charter mentioned being independent of a routing protocol.

I think we should consider first the practical cases.

Alex

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Fri, 27 Feb 2009 13:20:47 -0500

Inline. 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
> Sent: Friday, February 27, 2009 12:47 PM
> To: Teco Boot
> Cc: [email-masked]
> > In a MANET, I expect nodes to run a MANET Routing protocol 
> and forward 
> > packets.
> 
> Well I agree with the last part: MANET nodes do forward 
> packets.  But I don't agree with the first part: in a MANET I 
> could configure static routes, not necessarily running a 
> MANET routing protocol.
> 
> Yes.  If the future charter rules these kinds of MANET 
> networks which are non-MANET-routing-protocol then I'll go away :-)
> 
> > hop) or 10^3 times the power per bit if multi-hop is 
> enabled (and 1000 
> > intermediate nodes....). Just physical laws here.
> 
> Well I agree the physical laws are so.  But I disagree to 
> have 25km MANETs in the Charter.  I agree with "25m IPv6 
> subnets", if they were explicitely stated so in the charter.
> 
> Alex
>

And I'll have to disagree with the "25m subnets". I regularly deal with
line-of-sight radio links that are in excess of 25km. We can't limit
ourselves to short-range technologies (e.g. Commercial 802.11,
Bluetooth, Zigbee, etc). I don't believe a distance should be explicitly
stated in the charter, rather, some verbiage that talks about "radio
neighbors in range" should be sufficient. 

Regards,
Stan

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Feb 2009 19:24:39 +0100

Teco Boot a écrit :
> Your routers need two wifi interfaces.

Yes.

> Often, there is only one wifi interface.

If the charter text said we only look at routers with one physical
interface then I'd go away.

And if it said we only look at routers with at least two physical
interfaces then my figures would be right.

> The MANET Routing protocol provides connectivity between nodes that
> are out of range from each other, via relay nodes that are in range.

Well that can be achieved with simple plain routing, not necessarily a
dynamic routing protocol.

> Using many distinct SSIDs can introduce problems, e.g. Host-1 and
> Host-2 are near each other, but on a different SSID:

Using a single SSID can introduce other problems, such as the now
documented hidden terminal problem.

We should make choices.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Feb 2009 19:31:14 +0100

Stan Ratliff (sratliff) a écrit :
>>  MANETs in the Charter.  I agree with "25m IPv6 subnets", if they 
>> were explicitely stated so in the charter.
>> 
>> Alex
>> 
> 
> And I'll have to disagree with the "25m subnets". I regularly deal 
> with line-of-sight radio links that are in excess of 25km. We can't 
> limit ourselves to short-range technologies (e.g. Commercial 802.11,
>  Bluetooth, Zigbee, etc). I don't believe a distance should be 
> explicitly stated in the charter, rather, some verbiage that talks 
> about "radio neighbors in range" should be sufficient.

I wouldn't disagree with a Charter mentioning we deal with 25m IPv6
subnets and with 30.000km IPv6 subnets, and here are the two practical
methods to put addresses on these nodes.

But I would disagree with a Charter saying we deal with all wireless
links ranging from personal area to sattellite and everything in between
  and the generic addressing model is the following...

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Feb 2009 19:37:19 +0100

To my understanding, mentioning radio neighbors in range implies we 
discover they're risking hidden-terminal and non-transitive problems.

Neighbors in fully transitive range with exposed terminals would be more 
precise.

Alex

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Fri, 27 Feb 2009 13:55:54 -0500

> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Friday, February 27, 2009 1:31 PM
> To: Stan Ratliff (sratliff)
> Cc: Alexandru Petrescu; Teco Boot; [email-masked]
> have 25km  
> I wouldn't disagree with a Charter mentioning we deal with 
> 25m IPv6 subnets and with 30.000km IPv6 subnets, and here are 
> the two practical methods to put addresses on these nodes.
> 
> But I would disagree with a Charter saying we deal with all 
> wireless links ranging from personal area to sattellite and 
> everything in between

Hmmm, that's a problem. Because I don't see a difference in a 3m subnet using Bluetooth, and a 35,000km "subnet" using a satellite with IP routing on board. I think the charter needs to solve the problem for both of those, because I believe the distance of the link shouldn't be a factor. 

Regards,
Stan

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Fri, 27 Feb 2009 13:57:45 -0500

OK, I can go with the "fully transitive" verbiage. I don't think the
hidden-terminal problem applies here, because that's going to happen
regardless of the transitivity of the radio link(s). 

Regards,
Stan 

> Sent: Friday, February 27, 2009 1:37 PM
> Cc: Teco Boot; [email-masked]
> Subject: radio neighbors in range
> 
> To my understanding, mentioning radio neighbors in range 
> implies we discover they're risking hidden-terminal and 
> non-transitive problems.
> 
> Neighbors in fully transitive range with exposed terminals 
> would be more precise.
> 
> Alex
> 
> 
>

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 27 Feb 2009 20:28:27 +0100

Inline.

|-----Oorspronkelijk bericht-----
|Van: Alexandru Petrescu [mailto:[email-masked]]
|Verzonden: vrijdag 27 februari 2009 19:18
|Aan: Teco Boot
|CC: [email-masked]
|Onderwerp: Re: Autoconf addressing model
|
|Teco Boot a écrit :
|[...]
|>>> I think there is a much more obvious option, using the RFC2464
|>>> model for the MANET interface and /128 (or /32) for loopback
|>>> interfaces. Both would use high probability globally unique
|>>> Interface IDs like EUI-64 (Extended Unique Identifier).
|>>
|>> I don't agree going that way.  I think loopback addresses are for
|>> self addressing not for talking to other nodes.
|>
|> See other mail also, on Linux. I think loopback addresses are often
|> used for stable connections to routers, where interfaces flap but due
|> to redundancy there are alternative paths.
|
|I think you mean a virtual interface actually, not necessarily the
|loopback interface (and yes, lo is a 'virtual' interface).
|
|Not all virtual interfaces are loopback.

Router folks use "loopback" for what is meant here. Virtual interfaces have
a much, much broader meaning. A tunnel interface or VLAN / FR / ATM
subinterface is a virtual interface but definitely not what I intent to use.
I prefer keep using the term loopback here.

|
|> RFC3871: It is a common practice among operators to configure
|> "loopback" pseudo-interfaces to use as the source and destination of
|> management traffic.
|
|Well that RFC is completely wrong please someone correct it.  The
|loopback address is ::1 and it can't be used to communicate outside the
|computer. Yes pseudo-interface (and maybe 'virtual') but no loopback.

I think you mix up "host loopback" and "router loopback". These are very,
very different!

|And yes the interface in the routing table for the entry address/128 is
|'lo' which is yes the loopback interface but no, never will that address
|be in the src nor dst fields of any packet leaving the computer (other
|than encapsulated maybe).

I checked this on the Linux host. I assigned another address on the lo
interface. And the Linux host is reachable on this address, as long as other
nodes has a path to this /128 prefix.

Sorry, you are wrong.

Detailed info:

debian-fs1:/proc/sys/net/ipv6/neigh/eth0# ifconfig lo  
lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: 2001:db8:1::3333/128 Scope:Global
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:185 errors:0 dropped:0 overruns:0 frame:0
          TX packets:185 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:13568 (13.2 KiB)  TX bytes:13568 (13.2 KiB)

Tested from IOS router:
nbs3725#ping 2001:db8:1::3333
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2001:DB8:1::3333, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 0/0/4 ms
nbs3725#

I added reachability manually:
nbs3725#show ipv6 route
IPv6 Routing Table - 4 entries
Codes: C - Connected, L - Local, S - Static, R - RIP, B - BGP
       U - Per-user Static route, M - MIPv6
       I1 - ISIS L1, I2 - ISIS L2, IA - ISIS interarea, IS - ISIS summary
       O - OSPF intra, OI - OSPF inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
       ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2
       D - EIGRP, EX - EIGRP external
C   2001:DB8:1::/64 [0/0]
     via ::, FastEthernet0/0.22
L   2001:DB8:1::1/128 [0/0]
     via ::, FastEthernet0/0.22
S   2001:DB8:1::3333/128 [1/0]
     via FE80::20C:29FF:FEE3:BDF5, FastEthernet0/0.22
L   FF00::/8 [0/0]
     via ::, Null0
nbs3725#

Debug info, showing that you are wrong, the IP address in interface lo is
reachable:
Feb 27 19:08:08.018: IPv6: SAS picked source 2001:DB8:1::1 for
2001:DB8:1::3333 (FastEthernet0/0.22)
Feb 27 19:08:08.018: IPv6: nexthop FE80::20C:29FF:FEE3:BDF5,
Feb 27 19:08:08.018: IPV6: source 2001:DB8:1::1 (local)
Feb 27 19:08:08.018:       dest 2001:DB8:1::3333 (FastEthernet0/0.22)
Feb 27 19:08:08.018:       traffic class 0, flow 0x0, len 100+0, prot 58,
hops 64, originating
Feb 27 19:08:08.018: IPv6: Sending on FastEthernet0/0.22

Feb 27 19:08:08.022: IPV6: source 2001:DB8:1::3333 (FastEthernet0/0.22)
Feb 27 19:08:08.022:       dest 2001:DB8:1::1
Feb 27 19:08:08.022:       traffic class 0, flow 0x0, len 100+14, prot 58,
hops 64, forward to ulp

SSH works well also. NTP used the address automatically:
debian-fs1:~# netstat -anp | grep 3333
tcp6       0     52 2001:db8:1::3333:22     2001:db8:1::1:61026
ESTABLISHED 4756/5          
udp6       0      0 2001:db8:1::3333:123    :::*
2308/ntpd     

|>> [rfc4291 and 2464 citations]
|>>> It is not only because the RFC texts that I dislike the /128 in
|>>> MANET interfaces, it is also backward compatibility with current
|>>> IP stacks (and probably many applications).
|>>
|>> I agree.
|>>
|>>> I think using /128 for loopback interfaces fits the requirements
|>>> for the addressing model. If a loopback interface is used, MANET
|>>> interfaces do not require a globally unique address.
|>>
|>> I'm not sure I could agree with the MANET interface being the
|>> loopback interface.  It sounds as a significant departure.
|>
|> The MANET interface is not a loopback interface! It is the interface
|> to a radio, e.g. 802.11 NIC in IBSS mode (your wifi adhoc).
|
|I agree with this.  But in the immediately above text you're saying
|"using /128 for loopback interfaces fits" - I think you meant 'virtual'
|interface, not 'loopback' interface, right?

No, absolutely not.
I provided the evidence that the loopback is perfectly usable already.

|>>> RFC4291 once more (out of section, also cited above): Unicast
|>>> addresses with a scope greater than link-scope are not needed for
|>>> interfaces that are not used as the origin or destination of any
|>>> IPv6 packets to or from non-neighbors. So "host functionality"
|>>> can be provided using the globally (or MANET local) unique
|>>> address assigned to a loopback address, or another non-MANET
|>>> interface.
|>>
|>> An address assigned to an address?  I think it risks many
|>> misunderstandings.
|>
|> Typo, I meant: So "host functionality" can be provided using the
|> globally (or MANET local) unique address assigned to a loopback
|> interface, or another non-MANET interface.
|
|Ok.
|
|
|> I think this model solves some problems. o The assigned address can
|> be used over whatever interface. This fulfills a requirement of "ad
|> hoc", something works without planning.
|
|I thought the unplanned aspect could be treated by IPv6 stateless
|autoconf and IPv6-over-Ethernet link-local addresses.

Yes and no. I like SLAAC, but with SLAAC, thewre is an address per
interface. In this model, the node is reachable via the loopback address via
whatever interface.

|> o Connectivity is not broken if a path swap occurs (the RFC3781
|> loopback BCP) o It provides some scalability, as only a single
|> address is needed, even if multiple interfaces are used. o
|> Applications are not confused by "host prefixes" to a link, where
|> other nodes are reachable. I tested this with linux and IPv4 with
|> /32.
|
|Before deciding on the solution (address assigned to a virtual
|interface) I need to udnerstand how path swap occurs and why.

Because movement. A MANET Router may have multiple interfaces, some of them
could be MANET, others wireless infrastructure mode and others MANET. When a
fire truck leaves the brigade, it looses its wired / wifi ESS connection,
but can still communicate with other vehicles nearby using MANET links.

|> Problems started with ARP processing, and I swapped to another
|> addressing model immediately.
|
|>> For my clarification, what's fd01? (2001:db8:: is a prefix for
|>> documentation rfc3849, ULA is fc00 rfc4193).
|>
|> ULA prefix is FC00::/7. 8th but is L, set to 1 if locally assigned.
|> So all ULA would start with FD, the FC is for the future where a
|> registration body maintains the universal uniqueness.
|>
|> 0xFC + 0x01 = 0xFD.
|
|Ah!  So a correct ULA address would be fd01::1/128?  In this sense, when
|drawing pictures I have a choice between fd01::1/128 ULA and
|2001:db8::1/128 global address, it's ambiguous.
|
|>>> Manually assigned, or pre-configured (e.g. with SNMP) or formed
|>>> according to a to be defined [Autoconf for MANETs] protocol, with
|>>> a to-be-defined prefix (e.g. ULA, RFC4193).
|>>>
|>>> Although all nodes are marked as router, this does not imply all
|>>> nodes forward packets. All nodes run a MANET routing protocol for
|>>> learning
|>> the
|>>> MANET topology.
|>>>
|>>>
|>>> In case one of the routers is connected to the Internet or
|>>> private
|>> network,
|>>> this router can advertize a prefix in the MANET, and this
|>>> information
|>> is
|>>> distributed in the MANET with an [Autoconf for MANETs] protocol.
|>>
|>> Why shouldn't it be distributed with DHCP and with OSPF, for
|>> example.
|>
|> In a MANET, there are some problems with standard OSPF. OSPF-MANET is
|>  perfectly fine to use in a MANET.
|
|Ok.
|
|> DHCP (with relay) can be used for "pull", but there is a problem
|> finding the best relay agent. I think there should be a mechanism
|> that informs nodes of available facilities, e.g. shortest path to a
|> DHCP server. Updating ND RA with some info for finding a DHCP server
|> looks a good idea to me, and I updated my Border Router Discovery
|> Protocol (BRDP) [Autoconf] proposal for DHCP support already.
|
|Sounds interesting.  But I think normal DHCP could run ok, provided the
|Relays know the address of the Server.  In a first practical step would
|be to manually configure the Server's address on each Relays.

When many DHCP Relay Agenst are nearby, who to select? If multicast is used,
all of them will relay and this ends in a DHCP Relay storm (collisions,
loss, retry .....)

|> However, there is a chicken - egg problem. In a wired network, the
|> DHCP client - DHCP relay agent relation is stable. This is certainly
|> not the case in a MANET.
|
|Well it is the case in a MANET made of 25meter IPv6 subnets.

Voice over IP over WLAN for 25meter? Just shout!!
My requirements are over 25meter. 25km is no joke. Wifi is not usable here.

|> Therefore, I think a DHCP client should start with building reliable
|> communication to a DHCP server, and the MANET routing protocols can
|> provide such. But the MANET routing protocol needs a prefix that
|> corresponds to this MANET node. For this reason, I think it makes
|> sense to start with generating a prefix without DHCP, and we could
|> use a prefix "push model" here.
|
|Well I think this is indeed a very chickeneggy problem: are addresses in
|place before routing is, or vice-versa.  But what would we do in
|practice?  Certainly we'd manually assign some addresses - let's see
|these cases first.

No.
MANETs are often used in workgroups, whit lack of knowledge of configuring
something. The network must be plug&play / zero-config.

|>> Above, and in the following figures, I don't understand "--->,
|>> Prefix Information".  Is that RA?  Or OSPF?  Or routing protocol?
|>> Or DHCP Prefix Delegation?
|>
|> This is under discussion, and the reason we have an [Autoconf] WG.
|> There are proposals that rely on a routing protocol, but the old
|> charter mentioned being independent of a routing protocol.
|
|I think we should consider first the practical cases.

No. I think we have a clear picture of why MANETs are being used. 
We need an [Autoconf] solution. Let's take the next steps defining an
addressing model, write down the requirements and then look for solutions.

Teco.

|Alex

---

From: Rex Buddenberg <[email-masked]>
Date: Fri, 27 Feb 2009 11:44:05 -0800

Stan,

The difference is not geo footprint (you got that right).  Rather the 
difference is between LAN (at fringe of network) and WAN (in the 
interior).  A WAN will always be at least one router away from end 
systems. 

While we're at it, references to SSIDs is not proper -- that's 
802.11-specific. 

Stan Ratliff (sratliff) wrote:
>>>> MANETs in the Charter.  I agree with "25m IPv6 subnets", 
>>>>         
>> if they were 
>>     
>>> limit ourselves to short-range technologies (e.g. 
>>>       
>> Commercial 802.11,  
>>     

-- 
Rex Buddenberg
Senior Lecturer
Naval Postgraduate School
Monterey, Ca 93943
831/656-3576

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 27 Feb 2009 20:46:13 +0100

Inline.

|-----Oorspronkelijk bericht-----
|Van: Alexandru Petrescu [mailto:[email-masked]]
|Verzonden: vrijdag 27 februari 2009 19:25
|Aan: Teco Boot
|CC: [email-masked]
|Onderwerp: Re: practical addressing
|
|Teco Boot a écrit :
|> Inline.
|>
|> |-----Oorspronkelijk bericht-----
|> |Van: Alexandru Petrescu [mailto:[email-masked]]
|> |Verzonden: vrijdag 27 februari 2009 18:45
|> |Aan: Teco Boot
|> |CC: [email-masked]
|> |Onderwerp: Re: practical addressing (was: [Autoconf] new charter)
|> |
|> |[Thanks for the details Linux/Vista/IOS routing tables!  I didn't
|know
|> |  all that, only for linux]
|> |
|> |Teco Boot a écrit :
|> |>>> Routers may generate a /128 prefix-address, and advertize this in
|> |>>>  the routing domain.
|> |>
|> |>> A host-based route propagated and deleted throughout a domain? I
|> |>> don't see the necessity of doing so. Assuming the routers are
|> |>> mobile within 25m ranges then they wouldn't need to change their
|> |>> addresses, thus no need to propagate host-based routes.
|> |>
|> |> If the /128 is not propagated, there will be no multi-hop network.
|> |
|> |Well I disagree.  In the multi-hop network below only /64 prefixes
|are
|> |present in Routers' routing tables, no /128 (host-based) routes:
|> |
|> |
|> |   -----  wifi "adhoc1"  ------  wifi "adhoc2"  ------- "adhoc3"-----
|> |  |Host1|---------------|Router|---------------|Router2|-------
||Host2|
|> |   ----- LL1    P1   LL2 ------ LL3   P2   LL4  -------LL5 P3  LL6---
|> |         G1                                                    G4
|> |
|> |           P1, P2, P3: /64 prefixes, such as:
|> |                       2001:db8:1::/64
|> |                       2001:db8:2::/64 and
|> |                       2001:db8:3::/64
|> |
|> |Would this kind of use of /64 prefixes alleviate the need to
|> |propagate/delete /128 prefixes throughout the network?
|>
|> Your routers need two wifi interfaces.
|
|Yes.
|
|> Often, there is only one wifi interface.
|
|If the charter text said we only look at routers with one physical
|interface then I'd go away.
|
|And if it said we only look at routers with at least two physical
|interfaces then my figures would be right.

MANET Routers have one MANET Interface at a minimum. Two interfaces is OK. 
No one said your figures were "wrong". But there are cases that need other
topologies, like the two nearby hosts.

|> The MANET Routing protocol provides connectivity between nodes that
|> are out of range from each other, via relay nodes that are in range.
|
|Well that can be achieved with simple plain routing, not necessarily a
|dynamic routing protocol.

No. 
One of the goals is providing connectivity in a dynamic topology. Static
routing cannot provide this.

|> Using many distinct SSIDs can introduce problems, e.g. Host-1 and
|> Host-2 are near each other, but on a different SSID:
|
|Using a single SSID can introduce other problems, such as the now
|documented hidden terminal problem.

The hidden terminal problem MAY introduce somewhat reduced performance. In
802.11, we have collision avoidance for unicast using RTS - CTS and
automatic retransmit using ACK. Other MANET radios may use other mechanisms.
By the way, 802.11 tests have shown that the carrier sense range is larger
than Tx-Rx range and hidden terminal problem does not occur.
(http://info.iet.unipi.it/~anastasi/papers/book_ch03.pdf).

And keep in mind the hidden terminal problem applies to infrastructure mode
as well!

On the multiple SSID solution, this is not acceptable in many cases, as my
life or dead example (2 hosts in range, connected to different SSISs).

Teco.

|We should make choices.
|
|Alex

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 27 Feb 2009 20:49:46 +0100

|-----Oorspronkelijk bericht-----
|Van: Alexandru Petrescu [mailto:[email-masked]]
|Verzonden: vrijdag 27 februari 2009 19:31
|Aan: Stan Ratliff (sratliff)
|CC: Alexandru Petrescu; Teco Boot; [email-masked]
|Onderwerp: Re: [Autoconf] new charter
|
|Stan Ratliff (sratliff) a écrit :
|>>
|>> Well I agree the physical laws are so.  But I disagree to have 25km
|>>  MANETs in the Charter.  I agree with "25m IPv6 subnets", if they
|>> were explicitely stated so in the charter.
|>>
|>> Alex
|>>
|>
|> And I'll have to disagree with the "25m subnets". I regularly deal
|> with line-of-sight radio links that are in excess of 25km. We can't
|> limit ourselves to short-range technologies (e.g. Commercial 802.11,
|>  Bluetooth, Zigbee, etc). I don't believe a distance should be
|> explicitly stated in the charter, rather, some verbiage that talks
|> about "radio neighbors in range" should be sufficient.
|
|I wouldn't disagree with a Charter mentioning we deal with 25m IPv6
|subnets and with 30.000km IPv6 subnets, and here are the two practical
|methods to put addresses on these nodes.
|
|But I would disagree with a Charter saying we deal with all wireless
|links ranging from personal area to sattellite and everything in between
|  and the generic addressing model is the following...

Why? I did not see a WG charter or RFC before, mentioning such. Check for
example RFC2464. It does not specify the length of a Cat5 cable, nor
10Base5, 10Base2 etc.

Teco.

|
|Alex

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 27 Feb 2009 20:53:31 +0100

Alex,

Any idea how to enforce such a restriction to the MANET users?
Use 100m Cat5 cables, folded by four?

And what if the teapot suddenly passes by?

Teco.

|-----Oorspronkelijk bericht-----
|Van: Alexandru Petrescu [mailto:[email-masked]]
|Verzonden: vrijdag 27 februari 2009 19:37
|Aan: Stan Ratliff (sratliff)
|CC: Teco Boot; [email-masked]
|Onderwerp: radio neighbors in range
|
|To my understanding, mentioning radio neighbors in range implies we
|discover they're risking hidden-terminal and non-transitive problems.
|
|Neighbors in fully transitive range with exposed terminals would be more
|precise.
|
|Alex

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 27 Feb 2009 21:00:34 +0100

|-----Oorspronkelijk bericht-----
|Van: [email-masked] [mailto:[email-masked]] Namens
|Rex Buddenberg
|Verzonden: vrijdag 27 februari 2009 20:44
|Aan: Stan Ratliff (sratliff)
|CC: [email-masked]
|Onderwerp: Re: [Autoconf] new charter
|
|Stan,
|
|The difference is not geo footprint (you got that right).  Rather the
|difference is between LAN (at fringe of network) and WAN (in the
|interior).  A WAN will always be at least one router away from end
|systems.

I am not sure on this. 
In the disconnected multi-hop MANET, the WAN is NOT available.

I agree in having a layered approach, e.g. edge network (or LAN) and
backbone (or WAN).

|While we're at it, references to SSIDs is not proper -- that's
|802.11-specific.

Yes. But 802.11 IBSS is often used as a reference for MANETs (cheap
equipment?).

Teco.

|Stan Ratliff (sratliff) wrote:
|>
|>
|>
|>> -----Original Message-----
|>> From: Alexandru Petrescu [mailto:[email-masked]]
|>> Sent: Friday, February 27, 2009 1:31 PM
|>> To: Stan Ratliff (sratliff)
|>> Cc: Alexandru Petrescu; Teco Boot; [email-masked]
|>> Subject: Re: [Autoconf] new charter
|>>
|>> Stan Ratliff (sratliff) a écrit :
|>>
|>>>> Well I agree the physical laws are so.  But I disagree to
|>>>>
|>> have 25km
|>>
|>>>> MANETs in the Charter.  I agree with "25m IPv6 subnets",
|>>>>
|>> if they were
|>>
|>>>> explicitely stated so in the charter.
|>>>>
|>>>> Alex
|>>>>
|>>>>
|>>> And I'll have to disagree with the "25m subnets". I regularly deal
|>>> with line-of-sight radio links that are in excess of 25km. We can't
|>>> limit ourselves to short-range technologies (e.g.
|>>>
|>> Commercial 802.11,
|>>
|>>> Bluetooth, Zigbee, etc). I don't believe a distance should be
|>>> explicitly stated in the charter, rather, some verbiage that talks
|>>> about "radio neighbors in range" should be sufficient.
|>>>
|>> I wouldn't disagree with a Charter mentioning we deal with
|>> 25m IPv6 subnets and with 30.000km IPv6 subnets, and here are
|>> the two practical methods to put addresses on these nodes.
|>>
|>> But I would disagree with a Charter saying we deal with all
|>> wireless links ranging from personal area to sattellite and
|>> everything in between
|>>   and the generic addressing model is the following...
|>>
|>> Alex
|>>
|>>
|>
|>
|> Hmmm, that's a problem. Because I don't see a difference in a 3m
|subnet using Bluetooth, and a 35,000km "subnet" using a satellite with
|IP routing on board. I think the charter needs to solve the problem for
|both of those, because I believe the distance of the link shouldn't be a
|factor.
|>
|> Regards,
|> Stan
|>
|>
|>
|>>
|> _______________________________________________
|> Autoconf mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/autoconf
|>
|>
|
|--
|Rex Buddenberg
|Senior Lecturer
|Naval Postgraduate School
|Monterey, Ca 93943
|831/656-3576
|
|_______________________________________________
|Autoconf mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/autoconf

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Feb 2009 21:03:42 +0100

> |Not all virtual interfaces are loopback.

Again, do you think all virtual interfaces are 'loopback'?

> Router folks use "loopback" for what is meant here. Virtual
> interfaces have a much, much broader meaning. A tunnel interface or
> VLAN / FR / ATM subinterface is a virtual interface but definitely
> not what I intent to use. I prefer keep using the term loopback here.

I strongly disagree using the term loopback interface, at least because
it can be easily interpreted as the interface on which there's a
'loopback address'.  And you don't seem to intend to use the loopback
address.

The loopback interface is the only interface on which there's a loopback
address assigned.

> |> RFC3871: It is a common practice among operators to configure |>
> |> management traffic. | |Well that RFC is completely wrong please
> someone correct it.  The |loopback address is ::1 and it can't be
> used to communicate outside the |computer. Yes pseudo-interface (and
> maybe 'virtual') but no loopback.
> 
> I think you mix up "host loopback" and "router loopback". These are
> very, very different!

I think there's no difference between host and router loopback.

> |And yes the interface in the routing table for the entry address/128
> is |'lo' which is yes the loopback interface but no, never will that
> address |be in the src nor dst fields of any packet leaving the
> computer (other |than encapsulated maybe).
> 
> I checked this on the Linux host. I assigned another address on the
> lo interface. And the Linux host is reachable on this address, as
> long as other nodes has a path to this /128 prefix.

WEll yes, it is possible to manually assign any 128bit address routable
or non-routable, on the loopback interface, as it is possible to assign
any address on any interface be it virtual or physical.

> Sorry, you are wrong.
> 
> Detailed info:
> 
> debian-fs1:/proc/sys/net/ipv6/neigh/eth0# ifconfig lo lo        Link
> encap:Local Loopback inet addr:127.0.0.1  Mask:255.0.0.0 inet6 addr:
> 2001:db8:1::3333/128 Scope:Global inet6 addr: ::1/128 Scope:Host UP
> LOOPBACK RUNNING  MTU:16436  Metric:1 RX packets:185 errors:0
> dropped:0 overruns:0 frame:0 TX packets:185 errors:0 dropped:0
> overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:13568 (13.2
> KiB)  TX bytes:13568 (13.2 KiB)
> 
> Tested from IOS router: nbs3725#ping 2001:db8:1::3333 Type escape
> sequence to abort. Sending 5, 100-byte ICMP Echos to
> 2001:DB8:1::3333, timeout is 2 seconds: !!!!! Success rate is 100
> percent (5/5), round-trip min/avg/max = 0/0/4 ms

Well yes, that's ok, I don't see anything wrong with nbs3725 pinging
debian-fs1's loopback interface's routable address.

But the loopback interface is not used for its intended loopback
meaning.  That loopback interface doesn't use the loopback address - 
it's a virtual interface on which the loopback address is assigned.

> Debug info, showing that you are wrong, the IP address in interface
> lo is reachable:

Well yes, because having a non-loopback IPv6 address on the loopback 
interface.

> No, absolutely not. I provided the evidence that the loopback is
> perfectly usable already.

Why the loopback interface and not another virtual interface?  Why
mixing loopback semantics with a routable address semantics?

> interface. In this model, the node is reachable via the loopback
> address via whatever interface.

I think this creates more headaches than it solves.

In a first step, do we agree that the node has typically more than one
interface?  We didn't seem to.  If not, then why should we need to have
the node reachable via whatever interface, since there's only one.

If there are at least two interfaces, then why can't we use a different 
address on each of the interfaces?  What's wrong with that?  The fact 
that the node moves?  Well, you seemed to accept host-based /128 routes 
- in this case instead of 1 there'll be 2 host-based /128 routes. 
What's wrong with that again?

> |> o Connectivity is not broken if a path swap occurs (the RFC3781 |>
> loopback BCP) o It provides some scalability, as only a single |>
> address is needed, even if multiple interfaces are used. o |>
> Applications are not confused by "host prefixes" to a link, where |>
> other nodes are reachable. I tested this with linux and IPv4 with |>
> /32. | |Before deciding on the solution (address assigned to a
> virtual |interface) I need to udnerstand how path swap occurs and
> why.
> 
> Because movement. A MANET Router may have multiple interfaces, some
> of them could be MANET, others wireless infrastructure mode and
> others MANET.

Sorry, I can't go along these lines.  Movement described just like that, 
without any boundary, no pattern, just movement...

I think I will simply summarize the topologies we discussed and leave it
there.

I also agree it's difficult to describe movement on paper (maybe easier 
on ppt) but we could at least try.

[...]
> |Sounds interesting.  But I think normal DHCP could run ok, provided
> the |Relays know the address of the Server.  In a first practical
> step would |be to manually configure the Server's address on each
> Relays.
> 
> When many DHCP Relay Agenst are nearby, who to select? If multicast
> is used, all of them will relay and this ends in a DHCP Relay storm
> (collisions, loss, retry .....)

That issue is simple.  Before the node can even have the choice to talk
to a Relay, it will have to connect to the wifi "adhoc".  The moment it
connected to it it will only have one choice: the Relay present on that
"adhoc" essid.

>  |> DHCP client - DHCP relay agent relation is stable. This is
> certainly |> not the case in a MANET. | |Well it is the case in a
> MANET made of 25meter IPv6 subnets.
> 

:-) :-) I agree.

But the IP in VoIP over a 25m IPv6 subnet allows me to talk to another
IP much further who wouldn't hear my shout otherwise.

> My requirements are over 25meter. 25km is no joke. Wifi is not usable

Well then.  I think the mechanisms are completely different.  A 25km
radio link would use an addressing mechanism completely different.

> |> Therefore, I think a DHCP client should start with building
> reliable |> communication to a DHCP server, and the MANET routing
> protocols can |> provide such. But the MANET routing protocol needs a
> prefix that |> corresponds to this MANET node. For this reason, I
> think it makes |> sense to start with generating a prefix without
> DHCP, and we could |> use a prefix "push model" here. | |Well I think
> this is indeed a very chickeneggy problem: are addresses in |place
> before routing is, or vice-versa.  But what would we do in |practice?
> Certainly we'd manually assign some addresses - let's see |these
> cases first.
> 
> No. MANETs are often used in workgroups, whit lack of knowledge of
> configuring something. The network must be plug&play / zero-config.
> 
> 
> 
>  |>> Or DHCP Prefix Delegation? |> |> This is under discussion, and
> the reason we have an [Autoconf] WG. |> There are proposals that rely
> on a routing protocol, but the old |> charter mentioned being
> independent of a routing protocol. | |I think we should consider
> first the practical cases.
> 
> No. I think we have a clear picture of why MANETs are being used. We
> need an [Autoconf] solution. Let's take the next steps defining an 

Sorry, it seems the Autoconf solution will come to live only if the
first practical addressing solution can get agreement on.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Feb 2009 21:12:02 +0100

> Any idea how to enforce such a restriction to the MANET users?

By writing user manuals with specific tags: 25m no more.  Within that 
range terminals are exposed and range is transitive.

(the same for any 25m, 30.000m, etc).

Alex

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Fri, 27 Feb 2009 15:13:18 -0500

> From: Rex Buddenberg [mailto:[email-masked]] 
> Sent: Friday, February 27, 2009 2:44 PM
> Cc: Alexandru Petrescu; [email-masked]
> The difference is not geo footprint (you got that right).  
> Rather the difference is between LAN (at fringe of network) 
> and WAN (in the interior).  A WAN will always be at least one 
> router away from end systems. 

Rex, 

Absolutely agree with you. I understood the issue to be the former instead of the latter. 

Regards,
Stan 

> 
> While we're at it, references to SSIDs is not proper -- 
> that's 802.11-specific. 
> 
> 25m IPv6 
> >> subnets and with 30.000km IPv6 subnets, and here are the two 
> >> practical methods to put addresses on these nodes.
> >>
> > Hmmm, that's a problem. Because I don't see a difference in 
> a 3m subnet using Bluetooth, and a 35,000km "subnet" using a 
> satellite with IP routing on board. I think the charter needs 
> to solve the problem for both of those, because I believe the 
> distance of the link shouldn't be a factor. 
> >
> > Regards,
> > Stan
> >
> >
> >   
> >>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 27 Feb 2009 21:54:50 +0100

Rex Buddenberg a écrit :
> interior).  A WAN will always be at least one router away from end systems.

802.11-specific because that's what many people actually mean.  "Ad-hoc" 
type of SSID is there for same reason.  Many MANET experiments happened 
with 802.11 links.  Wireless LANs, WaveLAN, all are in scope and deserve 
mentioning.  They're the building blocks out of which MANETs can come up.

For LOS satcom communications: if I knew the precise names then I could 
find the manner in which they (or their admins) configure their IPv6 
addresses.

I'm specifically keeping out of MANET 802.15.4 (akin to WPAN) because 
there seems to be an IPv6 ND draft for this link which already has its 
own address autoconfiguration quirks.

For WMAN: I'm aware of 802.16 and it has its own already IETF specified 
means of forming IPv6 addresses.

In this landscape, I'm not sure how could Autoconf practical way of 
forming addresses not mention WiFi.

Alex

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Fri, 27 Feb 2009 16:13:03 -0500

> Sent: Friday, February 27, 2009 3:55 PM
> To: Rex Buddenberg
> Cc: Stan Ratliff (sratliff); Alexandru Petrescu; [email-masked]
> Rather the 
> type of SSID is there for same reason.  Many MANET 
> experiments happened with 802.11 links.  Wireless LANs, 
> WaveLAN, all are in scope and deserve mentioning.  They're 
> the building blocks out of which MANETs can come up.
> 
> For LOS satcom communications: if I knew the precise names 
> then I could find the manner in which they (or their admins) 
> configure their IPv6 addresses.
> 
> I'm specifically keeping out of MANET 802.15.4 (akin to WPAN) 
> because there seems to be an IPv6 ND draft for this link 
> which already has its own address autoconfiguration quirks.
> 
> For WMAN: I'm aware of 802.16 and it has its own already IETF 
> specified means of forming IPv6 addresses.
> 
> In this landscape, I'm not sure how could Autoconf practical 
> way of forming addresses not mention WiFi.
> 
> Alex
> 

Alex, 

None of the MANET networks I deploy are based on WiFi. I think that turning the discussion into one that is 802.11-centric is not a good idea -- it's analogous to our earlier discussion on distance of the radio link. Why should the Layer 2 protocol in use effect the selection of Layer 3 addresses? 

Regards,
Stan

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 27 Feb 2009 22:15:52 +0100

|-----Oorspronkelijk bericht-----
|Van: Alexandru Petrescu [mailto:[email-masked]]
|Verzonden: vrijdag 27 februari 2009 21:04
|Aan: Teco Boot
|CC: [email-masked]
|Onderwerp: [SPAM] Re: Autoconf addressing model
|Urgentie: Laag
|
|Teco Boot a écrit :
|> |Not all virtual interfaces are loopback.
|
|Again, do you think all virtual interfaces are 'loopback'?

Not at all.

And "loopback" on its own is meaningless.

|> Router folks use "loopback" for what is meant here. Virtual
|> interfaces have a much, much broader meaning. A tunnel interface or
|> VLAN / FR / ATM subinterface is a virtual interface but definitely
|> not what I intent to use. I prefer keep using the term loopback here.
|
|I strongly disagree using the term loopback interface, at least because
|it can be easily interpreted as the interface on which there's a
|'loopback address'.  

Check for example ISP BCP, rfc5375

I agree on that there can be confusion on loopback address (node local) and
loopback interface.

|And you don't seem to intend to use the loopback
|address.

No, I don't.

|The loopback interface is the only interface on which there's a loopback
|address assigned.

This is NOT a node requirement.

RFC4291:
2.5.3.  The Loopback Address

   The unicast address 0:0:0:0:0:0:0:1 is called the loopback address.
   It may be used by a node to send an IPv6 packet to itself.  It must
   not be assigned to any physical interface.  It is treated as having
   Link-Local scope, and may be thought of as the Link-Local unicast
   address of a virtual interface (typically called the "loopback
   interface") to an imaginary link that goes nowhere.

Note the wording "may be".

The other way around is definitely false:
RFC3484 (default address selection):
      Implementations that wish to support the use
      of global source addresses assigned to a loopback interface should
      behave as if the loopback interface originates and forwards the
      packet.

Assigning non-"loopback addresses" on the loopback interfaces is permitted.

|> |> RFC3871: It is a common practice among operators to configure |>
|> "loopback" pseudo-interfaces to use as the source and destination of
|> |> management traffic. | |Well that RFC is completely wrong please
|> someone correct it.  The |loopback address is ::1 and it can't be
|> used to communicate outside the |computer. Yes pseudo-interface (and
|> maybe 'virtual') but no loopback.
|>
|> I think you mix up "host loopback" and "router loopback". These are
|> very, very different!
|
|I think there's no difference between host and router loopback.

Yes. 
On a host (strong end system model, RFC1122), traffic sent out the host MUST
have the source address of the outgoing interface. On a router, this is not
the case. Therefore assignment of addresses on loopback interfaces on
routers is different than on (strong ES) hosts.

|> |And yes the interface in the routing table for the entry address/128
|> is |'lo' which is yes the loopback interface but no, never will that
|> address |be in the src nor dst fields of any packet leaving the
|> computer (other |than encapsulated maybe).
|>
|> I checked this on the Linux host. I assigned another address on the
|> lo interface. And the Linux host is reachable on this address, as
|> long as other nodes has a path to this /128 prefix.
|
|WEll yes, it is possible to manually assign any 128bit address routable
|or non-routable, on the loopback interface, as it is possible to assign
|any address on any interface be it virtual or physical.
|
|> Sorry, you are wrong.
|>
|> Detailed info:
|>
|> debian-fs1:/proc/sys/net/ipv6/neigh/eth0# ifconfig lo lo        Link
|> encap:Local Loopback inet addr:127.0.0.1  Mask:255.0.0.0 inet6 addr:
|> 2001:db8:1::3333/128 Scope:Global inet6 addr: ::1/128 Scope:Host UP
|> LOOPBACK RUNNING  MTU:16436  Metric:1 RX packets:185 errors:0
|> dropped:0 overruns:0 frame:0 TX packets:185 errors:0 dropped:0
|> overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:13568 (13.2
|> KiB)  TX bytes:13568 (13.2 KiB)
|>
|> Tested from IOS router: nbs3725#ping 2001:db8:1::3333 Type escape
|> sequence to abort. Sending 5, 100-byte ICMP Echos to
|> 2001:DB8:1::3333, timeout is 2 seconds: !!!!! Success rate is 100
|> percent (5/5), round-trip min/avg/max = 0/0/4 ms
|
|Well yes, that's ok, I don't see anything wrong with nbs3725 pinging
|debian-fs1's loopback interface's routable address.
|
|But the loopback interface is not used for its intended loopback
|meaning.  That loopback interface doesn't use the loopback address -
|it's a virtual interface on which the loopback address is assigned.

Yes, the "lo" interface is used for loopback address and for other purposes.

|> Debug info, showing that you are wrong, the IP address in interface
|> lo is reachable:
|
|Well yes, because having a non-loopback IPv6 address on the loopback
|interface.
|
|> No, absolutely not. I provided the evidence that the loopback is
|> perfectly usable already.
|
|Why the loopback interface and not another virtual interface?  Why
|mixing loopback semantics with a routable address semantics?
|
|> |I thought the unplanned aspect could be treated by IPv6 stateless
|> |autoconf and IPv6-over-Ethernet link-local addresses.
|>
|> Yes and no. I like SLAAC, but with SLAAC, thewre is an address per
|> interface. In this model, the node is reachable via the loopback
|> address via whatever interface.
|
|I think this creates more headaches than it solves.
|
|In a first step, do we agree that the node has typically more than one
|interface?  We didn't seem to.  If not, then why should we need to have
|the node reachable via whatever interface, since there's only one.

If there is only one (external) interface, there is no redundancy and the
advantages do not apply.

|If there are at least two interfaces, then why can't we use a different
|address on each of the interfaces?  What's wrong with that?  The fact
|that the node moves?  Well, you seemed to accept host-based /128 routes
|- in this case instead of 1 there'll be 2 host-based /128 routes.
|What's wrong with that again?

At least 2 advantages:
 o 1 address: lower overhead
 o no address swap needed when session swaps from one interface to the other
(and if interfaces go down!).

|> |> o Connectivity is not broken if a path swap occurs (the RFC3781 |>
|> loopback BCP) o It provides some scalability, as only a single |>
|> address is needed, even if multiple interfaces are used. o |>
|> Applications are not confused by "host prefixes" to a link, where |>
|> other nodes are reachable. I tested this with linux and IPv4 with |>
|> /32. | |Before deciding on the solution (address assigned to a
|> virtual |interface) I need to udnerstand how path swap occurs and
|> why.
|>
|> Because movement. A MANET Router may have multiple interfaces, some
|> of them could be MANET, others wireless infrastructure mode and
|> others MANET.
|
|Sorry, I can't go along these lines.  Movement described just like that,
|without any boundary, no pattern, just movement...
|
|I think I will simply summarize the topologies we discussed and leave it
|there.
|
|I also agree it's difficult to describe movement on paper (maybe easier
|on ppt) but we could at least try.
|
|[...]
|> |Sounds interesting.  But I think normal DHCP could run ok, provided
|> the |Relays know the address of the Server.  In a first practical
|> step would |be to manually configure the Server's address on each
|> Relays.
|>
|> When many DHCP Relay Agenst are nearby, who to select? If multicast
|> is used, all of them will relay and this ends in a DHCP Relay storm
|> (collisions, loss, retry .....)
|
|That issue is simple.  Before the node can even have the choice to talk
|to a Relay, it will have to connect to the wifi "adhoc".  The moment it
|connected to it it will only have one choice: the Relay present on that
|"adhoc" essid.

Your assumption is single hop communication and no MANET routing protocol. I
am interested in the more complex topologies.

There is no "essid" in ad hoc mode. It is the "ssid" of the IBSS. Only ESS
has essid.
Let's try to be accurate.

|> |> However, there is a chicken - egg problem. In a wired network, the
|>  |> DHCP client - DHCP relay agent relation is stable. This is
|> certainly |> not the case in a MANET. | |Well it is the case in a
|> MANET made of 25meter IPv6 subnets.
|>
|> Voice over IP over WLAN for 25meter? Just shout!!
|
|:-) :-) I agree.
|
|But the IP in VoIP over a 25m IPv6 subnet allows me to talk to another
|IP much further who wouldn't hear my shout otherwise.

Yes. a MANET topology could be a short-range / high data rate radio link to
another MANET Router, with low data rate / long range to a remote peer, and
another hop via short-range / high data radio link. In a mobile ad hoc
environment, nodes are free to move and the network should provide the best
connectivity to the users that is technical feasible. 

Not only the nodes may move, obstacles may also move (teapot, truck).

|> My requirements are over 25meter. 25km is no joke. Wifi is not usable
|> here.
|
|Well then.  I think the mechanisms are completely different.  A 25km
|radio link would use an addressing mechanism completely different.

Not sure on this. 
The to-be-defined [Autoconf] MANET addressing mechanism MUST support the
basics also!

|> |> Therefore, I think a DHCP client should start with building
|> reliable |> communication to a DHCP server, and the MANET routing
|> protocols can |> provide such. But the MANET routing protocol needs a
|> prefix that |> corresponds to this MANET node. For this reason, I
|> think it makes |> sense to start with generating a prefix without
|> DHCP, and we could |> use a prefix "push model" here. | |Well I think
|> this is indeed a very chickeneggy problem: are addresses in |place
|> before routing is, or vice-versa.  But what would we do in |practice?
|> Certainly we'd manually assign some addresses - let's see |these
|> cases first.
|>
|> No. MANETs are often used in workgroups, whit lack of knowledge of
|> configuring something. The network must be plug&play / zero-config.
|>
|>
|>
|> |>> Above, and in the following figures, I don't understand "--->,
|> |>> Prefix Information".  Is that RA?  Or OSPF?  Or routing protocol?
|>  |>> Or DHCP Prefix Delegation? |> |> This is under discussion, and
|> the reason we have an [Autoconf] WG. |> There are proposals that rely
|> on a routing protocol, but the old |> charter mentioned being
|> independent of a routing protocol. | |I think we should consider
|> first the practical cases.
|>
|> No. I think we have a clear picture of why MANETs are being used. We
|> need an [Autoconf] solution. Let's take the next steps defining an
|> addressing model, write down the requirements and then look for
|> solutions.
|
|Sorry, it seems the Autoconf solution will come to live only if the
|first practical addressing solution can get agreement on.

The we may come up with some guidelines using current technologies.
We already know this is broken if we want to support the more complex
topologies.

What about this scenario: here, the obstacle is moving:

(802.11 term: STA is station)

          +------------------------+   +------------------------+
          |                        |   |                        |
          |           ____STA-B    |   |           ____STA-B    |
          |       ___/      |      |   |       ___/             |
          |  STA-A          |      |   |  STA-A      OBSTACLE   |
          |      '--_       |      |   |      '--_              |
          |          '----STA-C    |   |          '----STA-C    |
          |  OBSTACLE              |   |                        |
          +------------------------+   +------------------------+
               1-1: No hindrance            1-2: B-C blocked

          +------------------------+   +------------------------+
          |                        |   |          O             |
          |           ____STA-B    |   |          B    STA-B    |
          |       ___/      |      |   |          S      |      |
          |  STA-A      OB  |      |   |  STA-A   T      |      |
          |            ST   |      |   |          A      |      |
          |           AC  STA-C    |   |          C    STA-C    |
          |         LE             |   |          LE            |
          +------------------------+   +------------------------+
               1-3: A-C blocked         1-4: A-B & A-C blocked

                MANET Scenarios with blocking obstacle

Compare with this one:

(802.11 term: AP is access point)

          +------------------------+   +------------------------+
          |                        |   |                        |
          |           ____STA-B    |   |           ____STA-B    |
          |       ___/             |   |       ___/             |
          |   AP-A                 |   |   AP-A      OBSTACLE   |
          |      '--_              |   |      '--_              |
          |          '----STA-C    |   |          '----STA-C    |
          |  OBSTACLE              |   |                        |
          +------------------------+   +------------------------+
               4-1: No hindrance            4-2: No hindrance

          +------------------------+   +------------------------+
          |                        |   |          O             |
          |           ____STA-B    |   |          B    STA-B    |
          |       ___/             |   |          S             |
          |   AP-A      OB         |   |   AP-A   T             |
          |            ST          |   |          A             |
          |           AC  STA-C    |   |          C    STA-C    |
          |         LE             |   |          LE            |
          +------------------------+   +------------------------+
           4-3: A-C & B-C blocked         4-4: All blocked

             802.11 BSS L2 topology with blocking obstacle

In these scenario's, the MANET model provides better connectivity. I won't
say more bandwidth, lower loss or other link quality metrics, but for high
availability the MANET model definitely wins. 

Teco.

|Alex

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sat, 28 Feb 2009 14:24:26 +0100

Hi Alex,

	Sorry for the late reply, trying to catch up now...

> directions).  What do you think about this practical limit?

Well, this is tipically the range for 802.11bg (.11a can even less, .11p
is more). It's a matter of the scenario we consider to asusume that this
range is enough for a router (i.e. it will not move further). Anyway,
due to the characteristics of the wireless and unmanaged nature of
MANETs, it might be the case that even without movement routers need to
change addresses (think of your pictur above in which Router2 is turned
off).

> Or is it not what you mean?

Yes, more ore less, but I think I agree with Teco in which I'd assign
those /128 addresses to loopback (not physical) interfaces.

> assigned to routers then they don't need to change them as a result of 

This is because in my understanding a /128 address cannot be formed
according ti rfc4862 (only /64 can). If the router gets a /128 address
by any other means, the MANET routing protocol would take care of
ensuring this address isreachable despite the movement of the router. 

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sat, 28 Feb 2009 14:43:39 +0100

Hi Teco,

> (Extended Unique Identifier).

Agree, this is also my understanding.

> forward packets. All nodes run a MANET routing protocol for learning the
I think I'm also agree here.
> distributed in the MANET with an [Autoconf for MANETs] protocol.

While I think this is also much in linee with my thinking, I think it's
better to focus on the simplest cases before.

Thanks,

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sat, 28 Feb 2009 14:43:42 +0100

Hi Teco,

>     this is a bit weird, as two interfaces has the same address configured.

	You mean the /64 for the link local addresses? this is not weird, they
have scope of a link, so there can perfectly be the same address on
different interfaces.

> fe80::/64                      ::       U    256 0     0 eth1

Just a suggestion (OT to this mailing list): it's better to use the
'ip' (iproute) command (ifconfig, route and netstat are deprecated, as
far as I know since 2.4 kernels). Besides, 'ipi command is far easier to
use: 'ip -6 addr', 'ip -6 ro'

Thanks,

Carlos

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sat, 28 Feb 2009 14:43:44 +0100

Hi,

> I prefer keep using the term loopback here.

Agree, I prefer that term as well.

> I think you mix up "host loopback" and "router loopback". These are very,

Agree, don't know if the semantic difference is documented somewhere,
but I share the same understanding.

Regards,

Carlos

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 28 Feb 2009 14:51:04 +0100

Stan Ratliff (sratliff) a écrit :
> 
> 
>> -----Original Message----- From: Alexandru Petrescu 
>> [mailto:[email-masked]] Sent: Friday, February 27, 
>> 2009 3:55 PM To: Rex Buddenberg Cc: Stan Ratliff (sratliff); 
>> Alexandru Petrescu; [email-masked] Subject: Re: [Autoconf] new 
>> charter
>> 
>> Rex Buddenberg a écrit :
>>> Stan,
>>> 
>> 802.11-specific because that's what many people actually mean. 
>> "Ad-hoc" type of SSID is there for same reason.  Many MANET 
>> experiments happened with 802.11 links.  Wireless LANs, WaveLAN, 
>> all are in scope and deserve mentioning.  They're the building 
>> blocks out of which MANETs can come up.
>> 
>> For LOS satcom communications: if I knew the precise names then I 
>> could find the manner in which they (or their admins) configure 
>> their IPv6 addresses.
>> 
>> because there seems to be an IPv6 ND draft for this link which 
>> already has its own address autoconfiguration quirks.
>> 
> None of the MANET networks I deploy are based on WiFi. I think that 
> turning the discussion into one that is 802.11-centric is not a good 
> idea -- it's analogous to our earlier discussion on distance of the 
> radio link. Why should the Layer 2 protocol in use effect the 
> selection of Layer 3 addresses?

If not 802.11 then what link layer name?

I agree it's a good direction to stay independent on the link-layer name
- IP should run over them all.  At the same time I'm afraid once we
spell out the link layer name we implicitely name the way in which the
initial assignment of an IPv6 address to the nodes attached to that link
layer, is spelled out.  And we should at least reuse that.

Thank you for the oppinion, and I think many people think along the
lines you suggest.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 28 Feb 2009 15:06:55 +0100

> And "loopback" on its own is meaningless.

No, I think loopback address and loopback interface are meaningful.

> Check for example ISP BCP, rfc5375

Checked.  The fact that Cisco uses 'loopback interface' to be something 
completely different than the interface holding the loopback address 
doesn't mean I should too.  I disagree with Cisco on this particular point.

I agree.

> Note the wording "may be".

Note the status of that rfc compared to the two rfcs you cited 
previously calling the loopback interface a virtual interface.

> Assigning non-"loopback addresses" on the loopback interfaces is permitted.

YEs, it is permitted, I agree.

But why should one do it?

> routers is different than on (strong ES) hosts.

YEs, I agree permitted, and implemented.

But why should a MANET do that - it could do it with virtual interfaces, 
not loopback.

> If there is only one (external) interface, there is no redundancy and the

Let's decide whether we deal with nodes having two-or-more physical 
interfaces or with single-physical-interface nodes.

>  o 1 address: lower overhead

??  overhead of what?

> (and if interfaces go down!).

Swapping sessions from one physical interface to another can happen by 
using virtual interfaces.  IT can happen too without any virtual 
interface.  Some Mobile IPv6 implementation does it.

> am interested in the more complex topologies.

The pictures I drawn are multihop.  And indeed I don't assume a MANET 
routing protocol.  Neither does the charter.  And that's ok.

> Let's try to be accurate.

iwconfig essid "adhoc1" mode ad-hoc
is also accurate.

> Not only the nodes may move, obstacles may also move (teapot, truck).

Ah!  Thank  you for the pictures below.  Later I will collect all the 
pictures posted recently.  I will list them in a email for future record.

[...]

> (802.11 term: STA is station)

This is absolutely wonderful.  I set it aside.

> (802.11 term: AP is access point)

I set this aside too.

HAving them pictured, may I ask you: do you think anything will ever be 
able to communicate through Obstacles?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 28 Feb 2009 15:09:13 +0100

> better to focus on the simplest cases before.

What are the simplest cases?

Alex

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sat, 28 Feb 2009 17:38:37 +0100

Hi Alex,

	I mean, let's try to agree on the basics (addressing model) and then
let's try to understand what happens with multihoming and more complex
scenarios.

	Thanks,

	Carlos

---

From: HyungJin Lim <[email-masked]>
Date: Sun, 1 Mar 2009 12:06:02 +0900

inline..

2009/2/28, Alexandru Petrescu <[email-masked]>:
>>>        |                            |           +-------+-------+
>>>  |Access Router H|       +-------+-------+                |
>>>              ||Prefix information H          |V                     wifi
>>> "adhoc1"

   I think we can divided into two category in MANET scenario as follows.

        Category 1
            Scenario 1: "MANET to Internet", in case, depths of nested
routers(NEMO)  is under three levels.
                           This is practical case in real world (i.e.,
most scenarios in real world)
         Scenario 2: "MANET to Internet", depths of nested routers is more
than three levels.
                             (i.e., perhaps disaster situation, etc.. )

       Category 2 (scenario 3)
                           : "Only MANET", in case, the network does not has
a connectivity to Internet.
                             (i.e., peer-to-peer network, etc..)

     Requirement of address model we need is different according with
considered scenario I think.
     Then some scenarios included in category 2 not needs topological
meaningful address.

      Which area is AUTOCONF want to pinpoint ?

      I think AUTOCONF should satisfy requirements between pure MANET, NEMO
and MANEMO
      that can compose of mesh network, although we discussed about the
difference between MANET, NEMO and MANEMO

      Moreover, these networks can has some impacts due to mobility pattern,
wireless coverage and any other situations. AUTOCONF
Addressing model can make a important role to efficient and secure aspects.

     What do you think about my comments ?

   Hyung-Jin, Lim