Subject: Re: [Autoconf] Autoconf addressing model

From: "Teco Boot" <[email-masked]>
Date: Mon, 2 Mar 2009 10:11:29 +0100

Hi Carlos,

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

You placed this comment just below a figure with just one Internet access
and three MANET Routers.
I think this is the simple case.

Maybe you intended to say "focus on single-homing and leave multi-homing for
future enhancements".
If so, I do not agree. In my use case (tactical networks), multi-homing is
an important requirement. I think it applies also for public safety /
disaster relief networks. More important, if we leave multi-homing
out-of-scope, we may easily make wrong decisions and block support for
multi-homing or it may not be optimal.

It is not that difficult to support multi-homing. Fred Templin VET solution
uses map&encap approach, as my NEMO4MANET idea (both IRTF RRG strategy A).
BRDP based routing use "source address based routing" to the border router
(IRTF RRG strategy B).  

I think the routing aspect of multi-homing is more a [MANET WG] topic, and
[Autoconf WG] could ask [MANET WG] to work on solutions for it, based on a
defined addressing model.

Regards, Teco

|-----Oorspronkelijk bericht-----
|Van: Carlos Jesús Bernardos Cano [mailto:[email-masked]]
|Verzonden: zaterdag 28 februari 2009 14:44
|Aan: Teco Boot
|CC: [email-masked]; 'Alexandru Petrescu'
|Onderwerp: Re: Autoconf addressing model
|
|Hi Teco,
|
|El vie, 27-02-2009 a las 10:41 +0100, Teco Boot escribió:
|> 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).
|
|Agree, this is also my understanding.
|
|>
|> 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.
|>
|I think I'm also agree here.
|>
|> 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.
|>
|
|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
|
|>
|> 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/
|> |++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
|>
|--
| 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: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 02 Mar 2009 11:57:37 +0100

Hi Teco,

> Maybe you intended to say "focus on single-homing and leave multi-homing for

I meant something similar: "focus on single-homing first, to agree on
the basics of the addressing model arquitecture, and leave the rest for
a little bit later (not for future enhancements).

> multi-homing or it may not be optimal.

I didn't mean out-of-the-scope. I just meant that there are very basic
things we haven't agreed yet. Better to solve that first..., IMHO.

> defined addressing model.

Fully agree.

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: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Mon, 02 Mar 2009 12:01:13 +0100

Hi,

	I think we should address both the MANET connected and MANET
disconnected scenarios. Whether there are NEMOs involved or not (MANEMO
issues) is probably a topic that can be addressed later, once we have a
clear picture of the simplest cases, IMHO (I agree MANEMO is an
interesting topic).

	Regards,

	Carlos

El dom, 01-03-2009 a las 12:06 +0900, HyungJin Lim escribió:
> inline..
> 
> 2009/2/28, Alexandru Petrescu <[email-masked]>: 
>         Carlos Jesús Bernardos Cano a écrit :
>         [...]
>                         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.
>                         
>                 
>                 While I think this is also much in linee with my
>                 thinking, I think it's
>                 better to focus on the simplest cases before.
>         
>         What are the simplest cases? 
>  
>    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
>  
>         Alex
>         
>         _______________________________________________
>         Autoconf mailing list
>         [email-masked]
>         https://www.ietf.org/mailman/listinfo/autoconf
>         
>

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 2 Mar 2009 12:46:48 +0100

Hi Alex,

More on "loopback interface".
And more on non-blocking obstacles.

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

RFC5373 is not a "Cisco document". It is a IETF product, produced by v6ops.
V6ops produces informational or BCP RFCs only.
Many router vendors support loopback interfaces.
Do you disagree with the v6ops document, best practices of most (all?) ISPs
and most router vendors?

ID.autoconf-manetarch-07 section 5.1 also suggests using the loopback
interface for binding a globally unique address. 
My suggestion is using the loopback interface for the /128 (or /32)
address(es), not the MANET Interface(s) as suggested in 5.2.

|>    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".
|
|Note the status of that rfc compared to the two rfcs you cited
|previously calling the loopback interface a virtual interface.

Yes. A loopback interface is a virtual interface. A virtual interface is NOT
a loopback interface. Another example of non-transitivity.

|> Assigning non-"loopback addresses" on the loopback interfaces is
|permitted.
|
|YEs, it is permitted, I agree.
|
|But why should one do it?

I came up with a handful advantages already:  
 o Lower overhead. If each MANET interface would use a [MANET local]
   and optionally a set of globally unique addresses, more addresses
   are used and load on the MANET (and other) protocols is higher.
 o No address swap needed when session swaps from one interface to the
   other. Protocols like MIP6, HIP and SHIM6 could repair the issue in
   some cases, in other cases they cannot. How to reach a MIP6 HA in
   a disconnected MANET?)
 o If a MANET interfaces goes up and down (e.g. single neighbor flapping), 
   the application may get affected. Using a virtual interface (typically
   the loopback interface), application layer recovery is circumvented.

|> Your assumption is single hop communication and no MANET routing
|protocol. I
|> 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.

Sorry, I missed this. Do you mean that host - router is multi-hop? Who is
forwarding?
Let's use figure 1-2 below. Is there connectivity between B and C, via A?

|> 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.
|
|iwconfig essid "adhoc1" mode ad-hoc
|is also accurate.

Please use terms as standardized.
ESSID stands for the name of an extended service set (ESS). An ESS is a set
of basic service sets, connected over a distribution service. ESS is far
from IBSS (more or less the opposite). I can't help the Linux iwconfig
syntax uses essid for what should be the well defined 802.11 SSID.

|> 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
|
|This is absolutely wonderful.  I set it aside.
|
|> 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.
|
|I set this aside too.
|
|HAving them pictured, may I ask you: do you think anything will ever be
|able to communicate through Obstacles?

Yes, of course.

          +------------------------+   +------------------------+
          |                        |   |                        |
          |           ____STA-B    |   |           ____STA-B    |
          |       ___/ 1    |      |   |       ___/ 1    .      |
          |  STA-A          | 1    |   |  STA-A    obstacle 5   |
          |      '--_ 1     |      |   |      '--_ 1     .      |
          |          '----STA-C    |   |          '----STA-C    |
          |  obstacle              |   |                        |
          +------------------------+   +------------------------+
               2-1: No hindrance            2-2: B-C degraded

          +------------------------+   +------------------------+
          |                        |   |          o             |
          |           ____STA-B    |   |       5  b ...STA-B    |
          |       ___/ 1    |      |   |       ...s.     |      |
          |  STA-A      ob  | 1    |   |  STA-A  t       | 1    |
          |       ...  st   |      |   |       ...a.     |      |
          |       5  .ac..STA-C    |   |       5  c ...STA-C    |
          |         le             |   |          le            |
          +------------------------+   +------------------------+
               2-3: A-C degraded        2-4: A-B & A-C degraded

                Scenarios with degrading obstacle

I depicted the metrics: 1 is good, 5 is degraded.

Here the routing tables, with metrics:

      ROUTER   DEST   NEXTHOP METRIC    ROUTER   DEST   NEXTHOP METRIC
     +-------+-------+-------+------+  +-------+-------+-------+------+
     |   A   |   B   |   B   |    1 |  |   A   |   B   |   B   |    1 |
     |       |   C   |   C   |    1 |  |       |   C   |   C   |    1 |
     +-------+-------+-------+------+  +-------+-------+-------+------+
     |   B   |   A   |   A   |    1 |  |   B   |   A   |   A   |    1 |
     |       |   C   |   C   |    1 |  |       |   C   |   C   |    5 |
     +-------+-------+-------+------+  +-------+-------+-------+------+
     |   C   |   A   |   A   |    1 |  |   C   |   A   |   A   |    1 |
     |       |   B   |   B   |    1 |  |       |   B   |   B   |    5 |
     +-------+-------+-------+------+  +-------+-------+-------+------+
          11-1: No hindrance                11-2: B-C is degraded

     +-------+-------+-------+------+  +-------+-------+-------+------+
     |   A   |   B   |   B   |    1 |  |   A   |   B   |   B   |    5 |
     |       |   C   |   C   |    5 |  |       |   C   |   C   |    5 |
     +-------+-------+-------+------+  +-------+-------+-------+------+
     |   B   |   A   |   A   |    1 |  |   B   |   A   |   A   |    5 |
     |       |   C   |   C   |    1 |  |       |   C   |   C   |    1 |
     +-------+-------+-------+------+  +-------+-------+-------+------+
     |   C   |   A   |   A   |    5 |  |   C   |   A   |   A   |    5 |
     |       |   B   |   B   |    1 |  |       |   B   |   B   |    1 |
     +-------+-------+-------+------+  +-------+-------+-------+------+
           11-3: A-C degraded               11-4: A-B & A-C degraded

This is for the MANET scenario. I can provide this for infrastructure mode
also, if you want me to.

Teco.

|Alex

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 2 Mar 2009 13:01:25 +0100

Hi,

I think nested-NEMO is handled by MEXT. As soon as the NEMO-RO requirement
documents are finalized we could check how MANET protocols fit and if there
is a need for an optimized MANET protocol for NEMO (e.g. MANEMO).

For the nested-NEMO addressing model, I am not aware of problems. 
Problems are introduced when the Mobile Network is a MANET, where nodes come
and go and prefix information is sent to (multiple) home agents dynamically.
The MANET Routing protocol may run over the MRHA tunnel, but this could
introduce high overhead, especially if metrics are introduced and metrics
dampening & hysteresis is not implemented. 
There could be some issues with MANET + NEMO + multi-homing.

Regards, Teco

===============
Van: HyungJin Lim [mailto:[email-masked]] 
Verzonden: zondag 1 maart 2009 4:06
Aan: Alexandru Petrescu
CC: [email-masked]; [email-masked]; [email-masked]
Onderwerp: Re: [Autoconf] Autoconf addressing model

inline..
2009/2/28, Alexandru Petrescu <[email-masked]>: 
Carlos Jesús Bernardos Cano a écrit :
[...]
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.

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

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

 
      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.

   Hyung-Jin, Lim
 
Alex

---

From: HyungJin Lim <[email-masked]>
Date: Mon, 2 Mar 2009 21:25:25 +0900

Hi
See inline
2009/3/2 Teco Boot <[email-masked]>

> is a need for an optimized MANET protocol for NEMO (e.g. MANEMO).

I see !! I will expect the phase you address, in MEXT.

> and go and prefix information is sent to (multiple) home agents

   Right !

> dampening & hysteresis is not implemented.

  From this point you are describing, there are some issues in relation to
address strategy, packet forwarding/routing, and etc. Then MANET routing
protocol can make a proper role in those situation I think.

> There could be some issues with MANET + NEMO + multi-homing.

I agree.  Your this comment is the one of major issues we should resolve.
I think address configuration strategy will affect on these situations.

At that time, if I need, I will participate to this discussion.

Thanks for your comment.

> pattern,

---

From: HyungJin Lim <[email-masked]>
Date: Mon, 2 Mar 2009 21:44:33 +0900

Hi,

...inline..

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

> disconnected scenarios.

  Okey !!
  If need, I also will participate on this discussion for MANET and MANEMO.

> Whether there are NEMOs involved or not (MANEMO

Thanks,
Hyung-Jin, Lim

       Regards,

       Carlos

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 2 Mar 2009 14:52:52 -0000

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

Agreed. There has to be a good reason to limit consideration of
what bearers to use, and the default without such a good reason
(which I am not aware of) is anything that works. Which means
that actually it doesn't even have to be a radio bearer. If in
an ad hoc network some links are wired, it may still be convenient
to treat them as ad hoc links. (And that also is not just keeping
options open for the sake of doing so.)

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 2 Mar 2009 15:15:43 -0000

Alexander Petrescu
> 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 think the onus is on you to provide a good technical reason why this
wouldn't work. (I stress technical, as motivationally, Stan Ratliff and
others have the motivation, so there is a good reason to do it if we
can.)

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 02 Mar 2009 17:04:18 +0100

Dearlove, Christopher (UK) a écrit :
> Alexander Petrescu
>> 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 think the onus is on you to provide a good technical reason why 
> this wouldn't work. (I stress technical, as motivationally, Stan 
> Ratliff and others have the motivation, so there is a good reason to 
> do it if we can.)

Not sure which argumentation is expected from me.

In general, wireless links differ largely in the way they form their
IPv6 link-local addresses, depending on whether they're ptp or shared.

An IPv6 addressing scheme designed for WiFi wouldn't work for WMAN
802.16 for example.

Also, some wireless links use some address autoconf mechanisms which
aren't provided by others (e.g. IPv6-over-802154 has a fancy means to
assign an IPv6 address with RR/RC (Router Reg/Router Conf'n)).

Alex

---

From: "Joe Macker" <[email-masked]>
Date: Mon, 2 Mar 2009 11:20:59 -0500

I would agree with these comments.

- Range seems artificially limiting. Wireless neighbor should suffice.
- Domain may extend into some wired links.

-Joe
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dearlove, Christopher (UK)
> Sent: Monday, March 02, 2009 9:53 AM
> To: Stan Ratliff (sratliff); Alexandru Petrescu; Teco Boot
> Cc: [email-masked]
> Subject: Re: [Autoconf] new charter
> 
> 
> Stan Ratliff

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 2 Mar 2009 16:39:58 -0000

Alexander Petrescu
> 802.11-specific because that's what many people actually mean.

No one, with the apparent exception of yourself in some postings,
intends the work in MANET and Autoconf to be limited to 802.11. Of
course many ad hoc networks use 802.11 for reasons of cost,
convenience, availability and so on, any general solution must be
able to be used with 802.11, and 802.11 often provides good examples
(but not all examples). But that's a long way from 802.11 specific,
and should stay that way.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 3 Mar 2009 10:10:03 -0000

Alexandru Petrescu
> Teco Boot
>> 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.

Complete non-starter as a solution.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Mar 2009 16:32:29 +0100

Hello Hyung-Jin,

HyungJin Lim a écrit :
> 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..)
> 
> considered scenario I think. Then some scenarios included in category
>  2 not needs topological meaningful address.
> 
>  and MANEMO that can compose of mesh network, although we discussed 
> about the difference between MANET, NEMO and MANEMO
> 

I think I can understand the classification you made above:
     -only-MANET
     -MANET-to-Internet and
     -MANET-to-MANET-to-Internet (three or more levels)

Alex

> 
> Hyung-Jin, Lim
> 
> 
> Alex
> 
> _______________________________________________ Autoconf mailing list
>  [email-masked] <mailto:[email-masked]>

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 3 Mar 2009 10:36:07 -0500

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
> Sent: Tuesday, March 03, 2009 10:32 AM
> To: HyungJin Lim
> Cc: [email-masked]
> Subject: Re: [Autoconf] Autoconf addressing model
> 
> Hello Hyung-Jin,
> 
> HyungJin Lim a écrit :
> Addressing model 
> > can make a important role to efficient and secure aspects.
> > 

How about a fourth classification? 
      
       MANET-to-Internet-to-MANET

It is useful in some scenarios. 

Regards,
Stan

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Mar 2009 16:49:24 +0100

> Do you disagree with the v6ops document, best practices of most (all?) ISPs

rfc5373 is not a BCP.  Besides, it is a Request for Comments, so my 
comment is that a loopback interface is not good for what we plan to do 
here.

> interface for binding a globally unique address.

My comment to this suggestion is the following: the usage of host-based 
routes effectively limits the size of the domain where that is 
manageable; depending on the link-layer type, it could be less than 
25meters large.  That may exclude connecting to the wider Internet.

> address(es), not the MANET Interface(s) as suggested in 5.2.

I disagree using /128 host-based routes on the surronding neighbors 
provided we don't have good reason to do so.  And provided /64 routes 
could work as well.

>    are used and load on the MANET (and other) protocols is higher.

I don't understand why you think load on protocols is higher if there 
are several global addresses assigned to a router having several interfaces.

>    some cases, in other cases they cannot. How to reach a MIP6 HA in

If a Router has two interfaces, and two global addresses (one for each 
interface), and if host-based routes surround this router, then there's 
not a need for address swap either.  Thus I don't understand why is 
there a need to have a single address for a Router having two interfaces.

>    the loopback interface), application layer recovery is circumvented.

If a Router has a single real interface then no amount of virtual 
interfaces can make it more reliable.

If a Router has two real interfaces then any additional amount of 
virtual interfaces will not contribute anything to reliability.

If a Router has a single Real interface, and the implementation of the 
particular routing protocol breaks when that interface is WiFi and its 
driver puts it down when disassociating, then yes, it's better to have 
that implementation of that routing protocol to run over a virtual 
interface, and maybe the loopback interface.  But better upgrade to a 
better implementation of either the wifi driver or of the routing protocol.

> |> protocol. I

The picture I posted initially had Host-Router-Host with two different 
subnets and Router with a routing table and forwarding process.

Yes, there is.  If STA-A is WiFi then link layer ensures repeating the 
packets.  If STA-A is WiMax then it will forward packets (router).

> |> ESS

What's the Cisco equivalent for iwconfig?

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 3 Mar 2009 21:11:09 +0100

Hi Alex,

As far as I know, you are the first person that came up with problems using
a loopback interface for globally unique addresses / host prefixes (/128,
/32) for routers. Please provide good argumentation, otherwise we follow the
already accepted practice in the routing community, also documented in
RFC5375 (and others, e.g. RFC3484).

Maybe you should post this in v6ops, not in Autoconf.

Teco.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 03 Mar 2009 12:19:37 -0800

Hello Teco,

How was it already decided to use loopback addresses?

I hope not, really...

In various implementations of AODV with gateways and
in other situations, even running Mobile IP to infrastructure
home agents, we never used loopback.

What would happen if the "autoconf addressing model"
was the same as the "Internet addressing model"?
Would that really be so bad?  We could have nice
things like "multicast", "anycast", unicast, subnets
and the typical addressing fundamentals that people
already understand.

Don't we just have to make sure that routing updates
inside the MANET network don't pester routers in
the external networks (e.g., Internet)?  I don';t see
why making that assurance should imply that we have
to re-architect the whole Internet addressing model.

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Mar 2009 21:47:28 +0100

Teco, the problem is simple: host-based routes are not preferrable.

Host-based routes in routers surrounding router X (this is what a /128
address on a virtual interface on router X implies, be that loopback
interface or not loopback interface) for a dynamically changing topology
may lead to too many routes coming up and down, too many specific
entries in the routing tables, too much dedicated routing messaging, and
more.

That only for the network itself.

Connecting it to the Internet, with host-based routes propagated up and
down throughout, may risk influencing the routes in the Internet proper.
  A new host-based route inserted in the routing table of the gateway
connecting this network to the Internet may propagate throughout the
entire fixed access system.

If you told me which part of the above were unclear I could explain
further.  But I think there's large agreement on it.

About the feasibility of _one_ /128 address on 'lo' while using _one_
host-based route: as you pointed out with the ios-linux example, I fully
agree a /128 address assigned on the 'lo' interface of one computer, and
a host-based route in the other computer towards that /128 address -
will work.  But just one.

About posting to v6ops: which part do you think I should post there?

About singling me out being the first and only mentioning some problem:
I can only be happy about it and stop posting :-)  But this host-based
route stuff is not new, I'm myself surprised I'm singled out about it.

Alex

Teco Boot a écrit :
> Hi Alex,
> 
> As far as I know, you are the first person that came up with problems
>  using a loopback interface for globally unique addresses / host 
> prefixes (/128, /32) for routers. Please provide good argumentation,
>  otherwise we follow the already accepted practice in the routing 
> community, also documented in RFC5375 (and others, e.g. RFC3484).
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 03 Mar 2009 12:53:40 -0800

Hello Alex,

> Teco, the problem is simple: host-based routes are not preferrable.

Why is that?

> entries in the routing tables, too much dedicated routing messaging, and

This magically "forgets" the last 10 years of development
for ad hoc networking protocols.  Do you think this work
was somehow invalid?  Solving the problems you mentioned
was, after all, the entire point of the work.

> entire fixed access system.

That would be the result of somebody making very poor
design and configuration choices on the gateway.

Presumably we can make a specification that would
avoid such bad design choices.  I say this, because I
have myself been involved with design efforts where we
already did it at least two or three times.

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Mar 2009 22:18:32 +0100

Charles - overall:
-I don't find it advantageous to specify an addressing architecture
  talking about virtual interfaces, be they loopback interfaces; rather
  I'd describe real interfaces.
-I find it more advantageous to describe stable subnets, with prefixes
  (between /48 and /64) exchanged around, rather than /128s.
-I would avoid the assumption that an ad-hoc router maintains a
  stable IP address while moving around.

For details, see below.

Alex

The churning aspect of host-based routes was just one argument against
/128s and finally against loopback/virtual interfaces.

Of course, host-based routes could work in some networks, mainly
depending on their size and way of moving.

>> Teco, the problem is simple: host-based routes are not preferrable.

BEcause we simply don't know the size of the network in which they could
work.  And that apparently it is avoided to put any limit on size of any
kind.

Even approximative evaluations of the size of the network in which these
host-based routes would work aren't preferred by many.

>> Host-based routes in routers surrounding router X (this is what a 
>> /128 address on a virtual interface on router X implies, be that 
>> loopback interface or not loopback interface) for a dynamically 
>> changing topology may lead to too many routes coming up and down, 
>> too many specific entries in the routing tables, too much dedicated
>>  routing messaging, and more.
> 
> This magically "forgets" the last 10 years of development for ad hoc 
> networking protocols.  Do you think this work was somehow invalid? 
> Solving the problems you mentioned was, after all, the entire point 
> of the work.

Sorry for having sounded neglecting the results of ad-hoc networking
protocols.  It was not the intention.  I believe some protocols could be
used to propagate prefixes - instead of /128s - and may be more
efficient, grow the network larger.

>> Connecting it to the Internet, with host-based routes propagated up
>>  and down throughout, may risk influencing the routes in the 
>> Internet proper. A new host-based route inserted in the routing 
>> table of the gateway connecting this network to the Internet may 
>> propagate throughout the entire fixed access system.
> 
> That would be the result of somebody making very poor design and 
> configuration choices on the gateway.
> 
> Presumably we can make a specification that would avoid such bad 
> design choices.  I say this, because I have myself been involved with
>  design efforts where we already did it at least two or three times.

Well yes, that's a good point, worth mentioning raw like that.

There is an additional way achieving it: using ULAs, they wouldn't
propagate, because their own nature.  They wouldn't be reachable either.

These aspects could be mentioned.

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 03 Mar 2009 13:30:35 -0800

Hello Alex,

>  (between /48 and /64) exchanged around, rather than /128s.

That's fine, as long as the destination is addressable within
a subnet.  If the destination does not live on a subnet, why
not use a host route (i.e., /128 address)?

>  stable IP address while moving around.

Then you will have trouble.  There is no free lunch.
Either:
(a) the IP address stays the same, and the routes change, or
(b) the IP address changes, and there is a resolver to
      associate the IP address with some other identifier.

Since the design of the resolver in (b) is an unknown and
arguably much more difficult, I'll take (a) with a great
sigh of relief.

> /128s and finally against loopback/virtual interfaces.

Are the other arguments easily summarized in a few words?

> depending on their size and way of moving.

This is true.  I don't see what's wrong with it.

> work.  And that apparently it is avoided to put any limit on size of any

Who said we had to avoid size limits?

> host-based routes would work aren't preferred by many.

I must have missed that, sorry.  Those "many" didn't often assert
their preferences in the [manet] working group.

> efficient, grow the network larger.

Well, to me it did sound very negative.  Moreover, I think it is just
fine to pass around subnet prefixes, if you have subnets.

Regards,
Charlie P.

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 3 Mar 2009 22:37:18 +0100

Hi Alex,

I included wrong routing table info in the "obstacles" scenarios.
Here a full set of diagrams with routing table info.

I removed "STA-", now the model applies to non-802.11 topologies as well.

Teco.

1.  MANET topology with moving and blocking obstacle

          +------------------------+   +------------------------+
          |                        |   |                        |
          |           ______B      |   |           ______B      |
          |       ___/      |      |   |       ___/             |
          |      A          |      |   |      A       OBSTACLE  |
          |      '--_       |      |   |      '--_              |
          |          '------C      |   |          '------C      |
          |  OBSTACLE              |   |                        |
          +------------------------+   +------------------------+
              1-1: Full connected          1-2: B-C via A

          +------------------------+   +------------------------+
          |                        |   |          O             |
          |           ______B      |   |          B      B      |
          |       ___/      |      |   |          S      |      |
          |      A      OB  |      |   |      A   T      |      |
          |            ST   |      |   |          A      |      |
          |           AC    C      |   |          C      C      |
          |         LE             |   |          L             |
          |                        |   |          E             |
          +------------------------+   +------------------------+
               1-3: A-C via B          1-4: A-B and A-C blocked

   The routing tables for the MANET Routers look as follows:

        ROUTER   DEST   NEXTHOP COST    ROUTER   DEST   NEXTHOP COST
       +-------+-------+-------+----+  +-------+-------+-------+----+
       |   A   |   B   |   B   |  1 |  |   A   |   B   |   B   |  1 |
       |       |   C   |   C   |  1 |  |       |   C   |   C   |  1 |
       +-------+-------+-------+----+  +-------+-------+-------+----+
       |   B   |   A   |   A   |  1 |  |   B   |   A   |   A   |  1 |
       |       |   C   |   C   |  1 |  |       |   C   |   A   |  2 |
       +-------+-------+-------+----+  +-------+-------+-------+----+
       |   C   |   A   |   A   |  1 |  |   C   |   A   |   A   |  1 |
       |       |   B   |   B   |  1 |  |       |   B   |   B   |  2 |
       +-------+-------+-------+----+  +-------+-------+-------+----+
             1-1: All single hop             1-2: B-C degraded

       +-------+-------+-------+----+  +-------+-------+-------+----+
       |   A   |   B   |   B   |  1 |  |   A   |       |       |    |
       |       |   C   |   B   |  2 |  |       |       |       |    |
       +-------+-------+-------+----+  +-------+-------+-------+----+
       |   B   |   A   |   A   |  1 |  |   B   |       |       |    |
       |       |   C   |   C   |  1 |  |       |   C   |   C   |  1 |
       +-------+-------+-------+----+  +-------+-------+-------+----+
       |   C   |   A   |   B   |  2 |  |   C   |       |       |    |
       |       |   B   |   B   |  1 |  |       |   B   |   B   |  1 |
       +-------+-------+-------+----+  +-------+-------+-------+----+
              1-3: A-C degraded           1-4: A-B and A-C blocked

2.  MANET topology with moving and degrading obstacle

    In these scenarios, link metrics are introduced.

          +------------------------+   +------------------------+
          |                        |   |                        |
          |          _______B      |   |           ______B      |
          |       __/ 1     |      |   |       __/ 1     .      |
          |      A          | 1    |   |      A        obstacle |
          |      '--_ 1     |      |   |      '--_ 1     . 5    |
          |          '------C      |   |          '------C      |
          |  obstacle              |   |                        |
          +------------------------+   +------------------------+
               2-1: No hindrance            2-2: B-C degraded

          +------------------------+   +------------------------+
          |                        |   |          o             |
          |           ______B      |   |       5  b .....B      |
          |       ___/ 1    |      |   |       ...s.     |      |
          |      A      ob  | 1    |   |      A   t      | 1    |
          |       ...  st   |      |   |       ...a.     |      |
          |       5  .ac.... C     |   |       5  c .....C      |
          |         le             |   |          l             |
          |                        |   |          e             |
          +------------------------+   +------------------------+
             2-3: A-C degraded          2-4: A-B and A-C degraded

   The routing tables:

        ROUTER   DEST   NEXTHOP COST    ROUTER   DEST   NEXTHOP COST
       +-------+-------+-------+----+  +-------+-------+-------+----+
       |   A   |   B   |   B   |  1 |  |   A   |   B   |   B   |  1 |
       |       |   C   |   C   |  1 |  |       |   C   |   C   |  1 |
       +-------+-------+-------+----+  +-------+-------+-------+----+
       |   B   |   A   |   A   |  1 |  |   B   |   A   |   A   |  1 |
       |       |   C   |   C   |  1 |  |       |   C   |   A   |  2 |
       +-------+-------+-------+----+  +-------+-------+-------+----+
       |   C   |   A   |   A   |  1 |  |   C   |   A   |   A   |  1 |
       |       |   B   |   B   |  1 |  |       |   B   |   A   |  2 |
       +-------+-------+-------+----+  +-------+-------+-------+----+
              2-1: No hindrance               2-2: B-C degraded

       +-------+-------+-------+----+  +-------+-------+-------+----+
       |   A   |   B   |   B   |  1 |  |   A   |   B   |   B   |  5 |
       |       |   C   |   B   |  2 |  |       |   C   |   C   |  5 |
       +-------+-------+-------+----+  +-------+-------+-------+----+
       |   B   |   A   |   A   |  1 |  |   B   |   A   |   A   |  5 |
       |       |   C   |   C   |  1 |  |       |   C   |   C   |  1 |
       +-------+-------+-------+----+  +-------+-------+-------+----+
       |   C   |   A   |   B   |  2 |  |   C   |   A   |   A   |  5 |
       |       |   B   |   B   |  1 |  |       |   B   |   B   |  1 |
       +-------+-------+-------+----+  +-------+-------+-------+----+
             2-3: A-C degraded          2-4: A-B and A-C degraded

   In this scenario, the most optimal paths are used, a 2-hop path with 
   metric 2 is used instead of a single hop path with metric 5.

3.  MANET topology with degrading obstacle and noise

    In this scenario, C can hear A through an obstacle as scenario 2-3,
    but A reception of B and C is affected by high level "NOISE" (3.1) 
    or low level "noise" (3-2). With high level noise, A cannot hear C and 
    the link is "uni-directional".

    Term "asymmetric" is used to indicate unbalanced metrics for the
direction
    of traffic between two nodes. In other documents, "asymmetric" is used
for
    what is called "uni-directional" here.

          +------------------------+   +------------------------+
          |                        |   |                        |
          |           ____1_B      |   |           ____1_B      |
          |       3__/      |      |   |       2__/      |      |
          |      A       ob | 1    |   |      A      ob  | 1    |
          | NOISE      st   |      |   | noise ...  st   |      |
          |         x.ac.>..C      |   |      10  .ac....C      |
          |         le             |   |         le     5       |
          +------------------------+   +------------------------+
           3-1: A-C uni-directional     3-2: A-C & B-C asymmetric
                A-B asymmetric  

      ROUTER   DEST   NEXTHOP METRIC    ROUTER   DEST   NEXTHOP METRIC
     +-------+-------+-------+------+  +-------+-------+-------+------+
     |   A   |   B   |   B   |    3 |  |   A   |   B   |   B   |    2 |
     |       |   C   |   B   |    4 |  |       |   C   |   B   |    3 |
     +-------+-------+-------+------+  +-------+-------+-------+------+
     |   B   |   A   |   A   |    1 |  |   B   |   A   |   A   |    1 |
     |       |   C   |   C   |    1 |  |       |   C   |   C   |    1 |
     +-------+-------+-------+------+  +-------+-------+-------+------+
     |   C   |   A   |   B   |    2 |  |   C   |   A   |   B   |    2 |
     |       |   B   |   B   |    1 |  |       |   B   |   B   |    1 |
     +-------+-------+-------+------+  +-------+-------+-------+------+
           3-1: A-C uni-directional     3-2: A-C & B-C asymmetric
                A-B asymmetric  

   When the noise level near station A is intermitting between high and low 
   levels, this does not influence the routing topology, as the MANET
protocol 
   has selected path A-B-C between the routers A and C, because better
metrics
   and bidirectional validation.
   The MANET Routing Protocol checks directionality of links before using
these.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Mar 2009 23:30:20 +0100

Charles E. Perkins a écrit :
>> -I find it more advantageous to describe stable subnets, with
>> prefixes (between /48 and /64) exchanged around, rather than /128s.
>> 
> 
> That's fine, as long as the destination is addressable within a
> subnet.  If the destination does not live on a subnet, why not use a
> host route (i.e., /128 address)?

Because it wouldn't allow the AUTOCONF network to grow larger and more
dynamic.

> Then you will have trouble.  There is no free lunch. Either: (a) the
> IP address stays the same, and the routes change, or (b) the IP
> address changes, and there is a resolver to associate the IP address
> with some other identifier.
> 
> Since the design of the resolver in (b) is an unknown and arguably
> much more difficult, I'll take (a) with a great sigh of relief.

Resolvers such as (m)DNS or some DHCP features could work I believe.  I
don't understand why it's claimed much more difficult.

>> The churning aspect of host-based routes was just one argument
>> against /128s and finally against loopback/virtual interfaces.
> 

No :-) sorry

>> BEcause we simply don't know the size of the network in which they
>> could work.  And that apparently it is avoided to put any limit on
>> size of any kind.
> 

Well we don't have size limits in the charter proposal, we don't have
agreement on '25m IPv6 subnets', we don't have limits on the types of
the link layers involved.

However, your question seems to imply you think there may be a limit:
AUTOCONF network is small enough to accommodate host-based routes.  Is
it this?

>> Even approximative evaluations of the size of the network in which
>> these host-based routes would work aren't preferred by many.
> 

Ok, it was my own interpretation.

>>> This magically "forgets" the last 10 years of development for ad
>>> hoc networking protocols.  Do you think this work was somehow
>>> invalid? Solving the problems you mentioned was, after all, the
>>> entire point of the work.
>> 
>> Sorry for having sounded neglecting the results of ad-hoc
>> networking protocols.  It was not the intention.  I believe some
>> protocols could be used to propagate prefixes - instead of /128s -
>> and may be more efficient, grow the network larger.
> 

Charles, yes - the subnets are there first, before IP.  Once the link is
up the subnet is the set of nodes on it.  In this sense I agree it is
just fine to pass subnet prefixes around.

Thanks for the message,

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Tue, 3 Mar 2009 23:31:38 +0100

Hi Charlie,

I never suggested using loopback interfaces are mandatory. I suggest MAY or
SHOULD, or BCP.
For some systems, the overhead or complexity or whatever could be
unacceptable and we should not enforce this (no MUST).

As long as I designed and maintained network infrastructures, I worked with
"/32 management addresses" on loopback interfaces. Still, I have annoying
experiences with routers that select the outgoing interface address as
default source address. Shutting down an interface could have unintended bad
impact on your terminal session. Same for link flapping due to other causes.

For this reason, many routers on the Internet use the loopback interface for
"management". "Management" is the host application on routers. There are
lots of design guidelines for this. My proposal is using the "Internet
lessons learned" in the MANET. Nothing wrong with this, agreed?

As said before, I have also bad experience with applications that bind to
the MANET interface address directly. I am sure I am not the only one.

With MobileIP, we are discussing a host (could be NEMO Router, but then it
acts as host on the visiting link). The MobileIP stack is interested in the
status of the visiting link, but does it propagate this to the applications?
Or use the applications some kind of virtual interface (e.g. a loopback
interface)? Or spoof ifup for interface to home link?

On MANET topology changes reflected in the Internet, I would say: it
depends. With NEMO technology, MR would present its status to the HA. We
could run MANET Routing over an MRHA tunnel, so HA learns prefixes of other
MANET Routers connected to the MR. With redundant HA, things are getting
more and more complex. I would say: reachability shall be reflected in The
Internet, intra-MANET link updates should not. Running BGP in the MRHA
tunnel? Or use the nested NEMO model? See what MEXT will do here, and check
if we can help (e.g. a MANET for NEMO). Or come up with some kind of prefix
delegation for MANETs, where summaries belong to the Border Router and MANET
topology is hidden form the Internet. This is what BRDP provides.

Regards, Teco

|-----Oorspronkelijk bericht-----
|Van: Charles E. Perkins [mailto:[email-masked]]
|Verzonden: dinsdag 3 maart 2009 21:20
|Aan: Teco Boot
|CC: [email-masked]
|Onderwerp: Re: [Autoconf] Autoconf addressing model
|
|
|Hello Teco,
|
|How was it already decided to use loopback addresses?
|
|I hope not, really...
|
|In various implementations of AODV with gateways and
|in other situations, even running Mobile IP to infrastructure
|home agents, we never used loopback.
|
|What would happen if the "autoconf addressing model"
|was the same as the "Internet addressing model"?
|Would that really be so bad?  We could have nice
|things like "multicast", "anycast", unicast, subnets
|and the typical addressing fundamentals that people
|already understand.
|
|Don't we just have to make sure that routing updates
|inside the MANET network don't pester routers in
|the external networks (e.g., Internet)?  I don';t see
|why making that assurance should imply that we have
|to re-architect the whole Internet addressing model.
|
|Regards,
|Charlie P.
|
|
|
|
|Teco Boot wrote:
|> Hi Alex,
|>
|> As far as I know, you are the first person that came up with problems
|using
|> a loopback interface for globally unique addresses / host prefixes
|(/128,
|> /32) for routers. Please provide good argumentation, otherwise we
|follow the
|> already accepted practice in the routing community, also documented in
|> RFC5375 (and others, e.g. RFC3484).
|>
|> Maybe you should post this in v6ops, not in Autoconf.
|>
|> Teco.
|>
|>
|>
|> _______________________________________________
|> Autoconf mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/autoconf
|>
|>
|>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Mar 2009 23:40:12 +0100

Teco, I'm happy you updated the obstacles scenario.  That's important 
insight on what movement may actually be.

I'd go further include default routes in the tables, and specific 
addresses like 10.1.1.1/32 instead of A, and subnet prefixes 10.1.1.0/24 
for example.

Sorry just asking about this: the Cost in the routing tables.  The 
kernel routing tables don't have variable Cost, they're all metric 1 I 
believe (all next-hops are 1-hop away).  The routing protocols' tables 
may have Cost and other variables.

Did you assume a routing protocol?

My preference is to not assume any routing protocol.

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 03 Mar 2009 15:15:07 -0800

Hello Alex,

> Because it wouldn't allow the AUTOCONF network to grow larger and more

Just saying "subnet" doesn't do that either, though.  In fact, the
signaling to support subnets could (conceivably) be even more
complicated than the signaling to support host routes.

> don't understand why it's claimed much more difficult.

I assure you it is not trivial to implement DNS or DHCP inside an
ad hoc network.  Most of the proposals I have seen for this have
located the function _outside_ the ad hoc network, for convenient
and straightforward access when connectivity is actually
available.

Watching your DNS server [(m) or not!] move from place to place
in an ad hoc network, sometimes finding itself partitioned from your
favorite node, could be an exciting and enlightening adventure.

>> Are the other arguments easily summarized in a few words?

Well, then I reserve the right to be very skeptical about their validity.

> the link layers involved.

If you are talking about an ad hoc network with 25,000,000
subnets, then I am basically not on the same page.  And not
in the same decade.

> AUTOCONF network is small enough to accommodate host-based routes.  Is

I think the network has to accomodate the routes needed
for connectivity to destinations within the network.

Again, just saying "subnet" doesn't buy even one gram
of additional scalability.  You need more.

You need a procedure for enabling aggregation.
Such a procedure is not always available.

> just fine to pass subnet prefixes around.

This is wrong*2.   First, there is IP, which fixes the address
format and address modes.  Then there are subnets.
Some people here probably remember when the word
"subnet" starting coming into more active use.

Second, just because nodes are reachable over the
air as neighbors, does not imply they are on the
same IP subnet.  Trying to maintain otherwise leads
to madness.

Surely you will agree.  A subnet is an abstraction to
support more efficient routing.  It is not a wire or a
piece of plastic or a contiguous region of space.

Regards,
Charlie P.

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 4 Mar 2009 00:25:10 +0100

Hi Alex,

We shall distinguish two subjects here:
 - Prefix assigned to MANET Interface or Loopback Interface
 - Usage of host prefix (/128 or /32 for IPv4).

I'll respond on host prefixes only.

I fully agree on minimizing overhead. All proposals I have done try to
realize this target. 
One of the mechanisms would be assigning a summary to a "mobile object",
e.g. a /60 summary for 16 /64 subnets. The router(s) in this "mobile object"
would only need to advertize the /60 prefix, nothing more. Some routers
support such a feature for a subset of the routing protocols, but most will
advertize all prefixes assigned to all (up) interfaces. 
I think for a MANET Routing Protocol, this summarization attribute is almost
mandatory (a SHOULD). I'll post this again on MANET when we discuss NHDP /
OLSR. A loopback interface could have a /128 out of this address block.
Using a /64 is OK also, but against guidelines for this.

Before a MANET Router has assigned such a summary prefix, it could act as a
router with LL addresses only and start exchanging routing messages. Now,
the router learns topology. It could be a requirement for the routing
protocol to use a unique identifier, e.g. an IPv4 address like what is being
used in OSPF (including OSPF-MANET). Maybe we need in MANET a 64-bit or
128-bit router-ID for randomly generated and unique IDs. So one of our
topics: what is (are) the unique IDs for the router, used by the MANET
Routing Protocol?

Also, if the router is MR (NEMO), it requires a globally unique address to
reach HA. This address is the only address that is required to distribute in
the MANET. Other prefix lengths are allowed, but of no help. So it doesn't
help scalability.

I still do not understand your concerns on using /128.

Teco.

PS.
I think the /128 is mainly to be used for bootstrapping, for reaching a DHCP
server. Then, the router allocates a summary prefix. The summaries should be
optimized for MANET efficiency, e.g. address compression by RFC5444. Using a
self generated /64 (or shorter) ULA prefix is another option, but here we
might need more advanced duplicate detection mechanisms.

|-----Oorspronkelijk bericht-----
|Van: Alexandru Petrescu [mailto:[email-masked]]
|Verzonden: dinsdag 3 maart 2009 21:47
|Aan: Teco Boot
|CC: [email-masked]
|Onderwerp: Re: Autoconf addressing model
|
|Teco, the problem is simple: host-based routes are not preferrable.
|
|Host-based routes in routers surrounding router X (this is what a /128
|address on a virtual interface on router X implies, be that loopback
|interface or not loopback interface) for a dynamically changing topology
|may lead to too many routes coming up and down, too many specific
|entries in the routing tables, too much dedicated routing messaging, and
|more.
|
|That only for the network itself.
|
|Connecting it to the Internet, with host-based routes propagated up and
|down throughout, may risk influencing the routes in the Internet proper.
|  A new host-based route inserted in the routing table of the gateway
|connecting this network to the Internet may propagate throughout the
|entire fixed access system.
|
|If you told me which part of the above were unclear I could explain
|further.  But I think there's large agreement on it.
|
|About the feasibility of _one_ /128 address on 'lo' while using _one_
|host-based route: as you pointed out with the ios-linux example, I fully
|agree a /128 address assigned on the 'lo' interface of one computer, and
|a host-based route in the other computer towards that /128 address -
|will work.  But just one.
|
|About posting to v6ops: which part do you think I should post there?
|
|About singling me out being the first and only mentioning some problem:
|I can only be happy about it and stop posting :-)  But this host-based
|route stuff is not new, I'm myself surprised I'm singled out about it.
|
|Alex
|
|Teco Boot a écrit :
|> Hi Alex,
|>
|> As far as I know, you are the first person that came up with problems
|>  using a loopback interface for globally unique addresses / host
|> prefixes (/128, /32) for routers. Please provide good argumentation,
|>  otherwise we follow the already accepted practice in the routing
|> community, also documented in RFC5375 (and others, e.g. RFC3484).
|>
|> Maybe you should post this in v6ops, not in Autoconf.
|>
|> Teco.
|>
|>
|>
|>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 03 Mar 2009 15:27:20 -0800

Hello Teco,

You raise interesting questions, but I think mostly
not definitive for the questions at hand.  I don't know
if I have any good answers, but here are some comments.

> impact on your terminal session. Same for link flapping due to other causes.

I guess this is relevant for packet forwarders with more than one
network interface.  For our little wireless nodes that have a single
interface, I don't imagine we'd see that kind of interface aggravation.

> lessons learned" in the MANET. Nothing wrong with this, agreed?

I know only a small bit about this.  Do you have a favorite
document that I could read to learn more?

> interface)? Or spoof ifup for interface to home link?

Whether or not applications have access to link information is
something not closely related to Mobile IP.  Whether or not
the care-of address is available to applications is a surprisingly
complicated question, which in my opinion opens the door to
many interesting questions and indicates the insufficiency of
today's typical application socket interface.

I've had a lot of ideas about how to fix this, but never been
able to initiate a project to supply a finished proposal.

Regards,
Charlie P.

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 4 Mar 2009 00:57:05 +0100

I'll think more on Internet access. The diagrams were meant for MANET intra
topology. I would not use private addresses for this. For IPv4, all link
addresses could be LL also (169.254.0.0/16). 

On names in the tables: assume (m)DNS, with A, B and C resolved by it. OK?

On metrics / costs, pick the term you like. I am assuming nothing, I use the
term metric where others use cost (or mixed usage, as below in the diagrams
/ text). Sample below uses metric where I would use hopcount. 

I just play a bit with some protocols on some platforms. Here a (part off a)
routing table snapshot from one of the toys (OLSRv1 adjusted with ETX and
Link Costs):

               OLSR Routes in Kernel
Destination		Gateway	 Metric	Cost		Interface
10.128.12.0/24	169.254.1.12	1	725.000	ath0
10.128.13.0/24	169.254.1.13	1	630.303	ath0
10.128.14.0/24	169.254.1.14	1	622.727	ath0
10.128.15.0/24	169.254.1.15	1	671.429	ath0
10.128.16.0/24	169.254.1.16	1	973.594	ath0
10.128.17.0/24	169.254.1.17	1	749.285	ath0
10.128.18.0/24	169.254.1.18	1	766.667	ath0
10.128.19.0/24	169.254.1.19	1	663.244	ath0
10.128.20.0/24	169.254.1.20	1	958.831	ath0
10.128.21.0/24	169.254.1.16	2	1853.594	ath0
10.128.22.0/24	169.254.1.16	2	1754.594	ath0
10.128.23.0/24	169.254.1.16	2	1836.594	ath0
10.128.24.0/24	169.254.1.16	2	1662.594	ath0
10.128.25.0/24	169.254.1.16	2	1939.594	ath0
10.128.26.0/24	169.254.1.26	1	637.633	ath0
10.128.27.0/24	169.254.1.27	1	629.622	ath0
10.128.28.0/24	169.254.1.28	1	710.918	ath0
10.128.29.0/24	169.254.1.29	1	737.511	ath0
10.128.30.0/24	169.254.1.30	1	817.725	ath0

Metrics and cost do not have a need to be "published" in the kernel RT.

On this toy, LL are multihop reachable (bad behavior !!):

169.254.1.21	169.254.1.16	2	1853.594	ath0
169.254.1.22	169.254.1.16	2	1754.594	ath0

Teco.

|-----Oorspronkelijk bericht-----
|Van: Alexandru Petrescu [mailto:[email-masked]]
|Verzonden: dinsdag 3 maart 2009 23:40
|Aan: Teco Boot
|CC: [email-masked]
|Onderwerp: Re: Autoconf addressing model
|
|Teco, I'm happy you updated the obstacles scenario.  That's important
|insight on what movement may actually be.
|
|I'd go further include default routes in the tables, and specific
|addresses like 10.1.1.1/32 instead of A, and subnet prefixes 10.1.1.0/24
|for example.
|
|Sorry just asking about this: the Cost in the routing tables.  The
|kernel routing tables don't have variable Cost, they're all metric 1 I
|believe (all next-hops are 1-hop away).  The routing protocols' tables
|may have Cost and other variables.
|
|Did you assume a routing protocol?
|
|My preference is to not assume any routing protocol.
|
|Alex
|
|Teco Boot a écrit :
|> Hi Alex,
|>
|> I included wrong routing table info in the "obstacles" scenarios.
|> Here a full set of diagrams with routing table info.
|>
|> I removed "STA-", now the model applies to non-802.11 topologies as
|well.
|>
|> Teco.
|>
|>
|>
|>
|> 1.  MANET topology with moving and blocking obstacle
|>
|>           +------------------------+   +------------------------+
|>           |                        |   |                        |
|>           |           ______B      |   |           ______B      |
|>           |       ___/      |      |   |       ___/             |
|>           |      A          |      |   |      A       OBSTACLE  |
|>           |      '--_       |      |   |      '--_              |
|>           |          '------C      |   |          '------C      |
|>           |  OBSTACLE              |   |                        |
|>           +------------------------+   +------------------------+
|>               1-1: Full connected          1-2: B-C via A
|>
|>           +------------------------+   +------------------------+
|>           |                        |   |          O             |
|>           |           ______B      |   |          B      B      |
|>           |       ___/      |      |   |          S      |      |
|>           |      A      OB  |      |   |      A   T      |      |
|>           |            ST   |      |   |          A      |      |
|>           |           AC    C      |   |          C      C      |
|>           |         LE             |   |          L             |
|>           |                        |   |          E             |
|>           +------------------------+   +------------------------+
|>                1-3: A-C via B          1-4: A-B and A-C blocked
|>
|>
|>    The routing tables for the MANET Routers look as follows:
|>
|>         ROUTER   DEST   NEXTHOP COST    ROUTER   DEST   NEXTHOP COST
|>        +-------+-------+-------+----+  +-------+-------+-------+----+
|>        |   A   |   B   |   B   |  1 |  |   A   |   B   |   B   |  1 |
|>        |       |   C   |   C   |  1 |  |       |   C   |   C   |  1 |
|>        +-------+-------+-------+----+  +-------+-------+-------+----+
|>        |   B   |   A   |   A   |  1 |  |   B   |   A   |   A   |  1 |
|>        |       |   C   |   C   |  1 |  |       |   C   |   A   |  2 |
|>        +-------+-------+-------+----+  +-------+-------+-------+----+
|>        |   C   |   A   |   A   |  1 |  |   C   |   A   |   A   |  1 |
|>        |       |   B   |   B   |  1 |  |       |   B   |   B   |  2 |
|>        +-------+-------+-------+----+  +-------+-------+-------+----+
|>              1-1: All single hop             1-2: B-C degraded
|>
|>        +-------+-------+-------+----+  +-------+-------+-------+----+
|>        |   A   |   B   |   B   |  1 |  |   A   |       |       |    |
|>        |       |   C   |   B   |  2 |  |       |       |       |    |
|>        +-------+-------+-------+----+  +-------+-------+-------+----+
|>        |   B   |   A   |   A   |  1 |  |   B   |       |       |    |
|>        |       |   C   |   C   |  1 |  |       |   C   |   C   |  1 |
|>        +-------+-------+-------+----+  +-------+-------+-------+----+
|>        |   C   |   A   |   B   |  2 |  |   C   |       |       |    |
|>        |       |   B   |   B   |  1 |  |       |   B   |   B   |  1 |
|>        +-------+-------+-------+----+  +-------+-------+-------+----+
|>               1-3: A-C degraded           1-4: A-B and A-C blocked
|>
|>
|>
|> 2.  MANET topology with moving and degrading obstacle
|>
|>     In these scenarios, link metrics are introduced.
|>
|>           +------------------------+   +------------------------+
|>           |                        |   |                        |
|>           |          _______B      |   |           ______B      |
|>           |       __/ 1     |      |   |       __/ 1     .      |
|>           |      A          | 1    |   |      A        obstacle |
|>           |      '--_ 1     |      |   |      '--_ 1     . 5    |
|>           |          '------C      |   |          '------C      |
|>           |  obstacle              |   |                        |
|>           +------------------------+   +------------------------+
|>                2-1: No hindrance            2-2: B-C degraded
|>
|>           +------------------------+   +------------------------+
|>           |                        |   |          o             |
|>           |           ______B      |   |       5  b .....B      |
|>           |       ___/ 1    |      |   |       ...s.     |      |
|>           |      A      ob  | 1    |   |      A   t      | 1    |
|>           |       ...  st   |      |   |       ...a.     |      |
|>           |       5  .ac.... C     |   |       5  c .....C      |
|>           |         le             |   |          l             |
|>           |                        |   |          e             |
|>           +------------------------+   +------------------------+
|>              2-3: A-C degraded          2-4: A-B and A-C degraded
|>
|>
|>    The routing tables:
|>
|>         ROUTER   DEST   NEXTHOP COST    ROUTER   DEST   NEXTHOP COST
|>        +-------+-------+-------+----+  +-------+-------+-------+----+
|>        |   A   |   B   |   B   |  1 |  |   A   |   B   |   B   |  1 |
|>        |       |   C   |   C   |  1 |  |       |   C   |   C   |  1 |
|>        +-------+-------+-------+----+  +-------+-------+-------+----+
|>        |   B   |   A   |   A   |  1 |  |   B   |   A   |   A   |  1 |
|>        |       |   C   |   C   |  1 |  |       |   C   |   A   |  2 |
|>        +-------+-------+-------+----+  +-------+-------+-------+----+
|>        |   C   |   A   |   A   |  1 |  |   C   |   A   |   A   |  1 |
|>        |       |   B   |   B   |  1 |  |       |   B   |   A   |  2 |
|>        +-------+-------+-------+----+  +-------+-------+-------+----+
|>               2-1: No hindrance               2-2: B-C degraded
|>
|>        +-------+-------+-------+----+  +-------+-------+-------+----+
|>        |   A   |   B   |   B   |  1 |  |   A   |   B   |   B   |  5 |
|>        |       |   C   |   B   |  2 |  |       |   C   |   C   |  5 |
|>        +-------+-------+-------+----+  +-------+-------+-------+----+
|>        |   B   |   A   |   A   |  1 |  |   B   |   A   |   A   |  5 |
|>        |       |   C   |   C   |  1 |  |       |   C   |   C   |  1 |
|>        +-------+-------+-------+----+  +-------+-------+-------+----+
|>        |   C   |   A   |   B   |  2 |  |   C   |   A   |   A   |  5 |
|>        |       |   B   |   B   |  1 |  |       |   B   |   B   |  1 |
|>        +-------+-------+-------+----+  +-------+-------+-------+----+
|>              2-3: A-C degraded          2-4: A-B and A-C degraded
|>
|>    In this scenario, the most optimal paths are used, a 2-hop path
|with
|>    metric 2 is used instead of a single hop path with metric 5.
|>
|>
|>
|> 3.  MANET topology with degrading obstacle and noise
|>
|>     In this scenario, C can hear A through an obstacle as scenario 2-
|3,
|>     but A reception of B and C is affected by high level "NOISE" (3.1)
|>     or low level "noise" (3-2). With high level noise, A cannot hear C
|and
|>     the link is "uni-directional".
|>
|>     Term "asymmetric" is used to indicate unbalanced metrics for the
|> direction
|>     of traffic between two nodes. In other documents, "asymmetric" is
|used
|> for
|>     what is called "uni-directional" here.
|>
|>
|>           +------------------------+   +------------------------+
|>           |                        |   |                        |
|>           |           ____1_B      |   |           ____1_B      |
|>           |       3__/      |      |   |       2__/      |      |
|>           |      A       ob | 1    |   |      A      ob  | 1    |
|>           | NOISE      st   |      |   | noise ...  st   |      |
|>           |         x.ac.>..C      |   |      10  .ac....C      |
|>           |         le             |   |         le     5       |
|>           +------------------------+   +------------------------+
|>            3-1: A-C uni-directional     3-2: A-C & B-C asymmetric
|>                 A-B asymmetric
|>
|>
|>       ROUTER   DEST   NEXTHOP METRIC    ROUTER   DEST   NEXTHOP METRIC
|>      +-------+-------+-------+------+  +-------+-------+-------+------
|+
|>      |   A   |   B   |   B   |    3 |  |   A   |   B   |   B   |    2
||
|>      |       |   C   |   B   |    4 |  |       |   C   |   B   |    3
||
|>      +-------+-------+-------+------+  +-------+-------+-------+------
|+
|>      |   B   |   A   |   A   |    1 |  |   B   |   A   |   A   |    1
||
|>      |       |   C   |   C   |    1 |  |       |   C   |   C   |    1
||
|>      +-------+-------+-------+------+  +-------+-------+-------+------
|+
|>      |   C   |   A   |   B   |    2 |  |   C   |   A   |   B   |    2
||
|>      |       |   B   |   B   |    1 |  |       |   B   |   B   |    1
||
|>      +-------+-------+-------+------+  +-------+-------+-------+------
|+
|>            3-1: A-C uni-directional     3-2: A-C & B-C asymmetric
|>                 A-B asymmetric
|>
|>    When the noise level near station A is intermitting between high
|and low
|>    levels, this does not influence the routing topology, as the MANET
|> protocol
|>    has selected path A-B-C between the routers A and C, because better
|> metrics
|>    and bidirectional validation.
|>    The MANET Routing Protocol checks directionality of links before
|using
|> these.
|>
|>
|>
|>
|>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 04 Mar 2009 09:22:18 +0100

Charles E. Perkins a écrit :
>>> subnet.  If the destination does not live on a subnet, why not 
>>> use a host route (i.e., /128 address)?
>> 
>> Because it wouldn't allow the AUTOCONF network to grow larger and 
>> more dynamic.
> 

I agree link-layer signalling within each subnet, for the purpose of
maintaining that subnet coherent, may contain numerous messages.

>>> Then you will have trouble.  There is no free lunch. Either: (a) 
>>> the IP address stays the same, and the routes change, or (b) the 
>>> IP address changes, and there is a resolver to associate the IP 
>>> address with some other identifier.
>>> 
>>> arguably much more difficult, I'll take (a) with a great sigh of 
>>> relief.
>> 
>> Resolvers such as (m)DNS or some DHCP features could work I 
>> believe.  I don't understand why it's claimed much more difficult.
> 
> I assure you it is not trivial to implement DNS or DHCP inside an ad 
> hoc network.  Most of the proposals I have seen for this have located
>  the function _outside_ the ad hoc network, for convenient and 
> straightforward access when connectivity is actually available.

Well if the subnet structure is coherent and things don't move around
too much then putting a DNS Server or a DHCP Server in the ad-hoc
network should be easy.

By not moving too much I mean each node not moving out of its 25meter
radius.

> Watching your DNS server [(m) or not!] move from place to place in an
>  ad hoc network, sometimes finding itself partitioned from your 

I agree we could find very dynamic ways of Routers and Hosts of an
ad-hoc network moving in and out such that subnet structure is not
maintained, and thus servers not being reachable.  But unless we
describe these movements we can't deal with them.

>> Well we don't have size limits in the charter proposal, we don't 
>> have agreement on '25m IPv6 subnets', we don't have limits on the 
>> types of the link layers involved.
> 
> If you are talking about an ad hoc network with 25,000,000 subnets, 
> then I am basically not on the same page.  And not in the same 
> decade.

Sorry I meant 25meters not millions.  A '25m IPv6 subnet' would be a
wireless coverage area of radius 25meter, without obstacles, and within
which there are only exposed terminals, fully transitive and symmetric
communications.

Would you agree such a subnet makes sense?  Does not make sense?

>> However, your question seems to imply you think there may be a 
>> limit: AUTOCONF network is small enough to accommodate host-based 
>> routes.  Is it this?
> 
> I think the network has to accomodate the routes needed for 
> connectivity to destinations within the network.
> 
> Again, just saying "subnet" doesn't buy even one gram of additional 
> scalability.  You need more.
> 
> You need a procedure for enabling aggregation. Such a procedure is 
> not always available.

If by aggregation is meant addressing aggregation (as Teco also
proposes a /60 prefix assigned to several Routers themselves assigning
/64 prefixes to their links) then I think we should not strive to
respect aggregation.  Address aggregation wouldn't make sense if we talk
host-based routes either.

>>> Well, to me it did sound very negative.  Moreover, I think it is 
>>> just fine to pass around subnet prefixes, if you have subnets.
>> 
>> Charles, yes - the subnets are there first, before IP.  Once the 
>> link is up the subnet is the set of nodes on it.  In this sense I 
>> agree it is just fine to pass subnet prefixes around.
> 
> This is wrong*2.   First, there is IP, which fixes the address format
>  and address modes.  Then there are subnets. Some people here
> probably remember when the word "subnet" starting coming into more
> active use.
> 
> 
> Second, just because nodes are reachable over the air as neighbors, 
> does not imply they are on the same IP subnet.  Trying to maintain 
> otherwise leads to madness.
> 
> Surely you will agree.  A subnet is an abstraction to support more 
> efficient routing.  It is not a wire or a piece of plastic or a 
> contiguous region of space.

I can live with that.

However, I think the simplest cases we have to deal with have very
simple subnet structure that we should take advantage of.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 04 Mar 2009 11:13:14 +0100

Teco Boot a écrit :
> I'll think more on Internet access.

Teco, when I mentioned default routes I didn't think Internet access.  I 
think default routes are good for networks disconnected from the 
Internet too.

> The diagrams were meant for MANET intra topology. I would not use
> private addresses for this. For IPv4, all link addresses could be LL
> also (169.254.0.0/16).

YEs, I think for IPv4 the LL addresses could be 169.254.

> On names in the tables: assume (m)DNS, with A, B and C resolved by it. OK?

Ok if you wish so, with the caveat that DNS does not hold their prefix 
lengths whereas the routing tables do and the prefix lengths are 
important in the hits.

> routing table snapshot from one of the toys (OLSRv1 adjusted with ETX and

Is this the kernel routing table?  Or OLSR's routing table?  I believe 
it's OLSR, not vanilla kernel, because there are two fields 'Metric' and 
'Cost' whereas the vanilla kernel only has 'Metric'.

> 10.128.30.0/24	169.254.1.30	1	817.725	ath0

For my clarification: this table doesn't contain host-based routes, we 
agree.

Also: are all the addresses 169.254.1.12-30 neighbors of the ath0 
interface?  What is/are the addresses assigned on ath0 of this node?

What is the subnet address of the subnet on which ath0 is connected?

If we have that then I could picture the topoology you're using, and 
draw subnet addresses and routing tables.

> 169.254.1.22	169.254.1.16	2	1754.594	ath0

Right! (LL addresses should be neighbors, not Metric 2.)

Thanks for the routing table dump.

Alex

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 4 Mar 2009 09:40:40 -0500

Inline.

> Sent: Wednesday, March 04, 2009 3:22 AM
> To: Charles E. Perkins
> Cc: [email-masked]
> I agree link-layer signalling within each subnet, for the 
> purpose of maintaining that subnet coherent, may contain 
> numerous messages.
> 
> Either: (a) the 
> arguably 
> >> Resolvers such as (m)DNS or some DHCP features could work 
> I believe.  
> >> I don't understand why it's claimed much more difficult.
> > 
> Well if the subnet structure is coherent and things don't 
> move around too much then putting a DNS Server or a DHCP 
> Server in the ad-hoc network should be easy.
> 
> By not moving too much I mean each node not moving out of its 
> 25meter radius.
> 

We've already been over the 25m subnet thing. It's a non-starter. Limiting movement, or mandating that a DHCP or DNS server is always on and available is also a non-starter. 25m subnets with "always on" DNS/DHCP servers sounds to me like a few guys gathering together to play "Doom" at their local coffee shop. I deploy MANET networks for governmental applications. Think disaster recovery, like after Hurricane Katrina, or the last round of wildfires in California. Do you think it appropriate to tell the firefighters "you can't let the trucks get more than 25m apart, or your network breaks"? Or, "if your DNS server should fail, just forget what you're doing and go home"?

So, once again, no -- 25m subnets don't make sense and won't work in the environments where I'm deploying networks. Placing this type of limitation on AUTOCONF will, IMO, make the work output useless.

Stan

> I agree we could find very dynamic ways of Routers and Hosts 
> of an ad-hoc network moving in and out such that subnet 
> structure is not maintained, and thus servers not being 
> reachable.  But unless we describe these movements we can't 
> deal with them.
> 
> > then I am basically not on the same page.  And not in the 
> same decade.
> 
> Sorry I meant 25meters not millions.  A '25m IPv6 subnet' 
> would be a wireless coverage area of radius 25meter, without 
> obstacles, and within which there are only exposed terminals, 
> fully transitive and symmetric communications.
> 
> > You need a procedure for enabling aggregation. Such a 
> procedure is not 
> > always available.
> 
> If by aggregation is meant addressing aggregation (as Teco 
> also proposes a /60 prefix assigned to several Routers 
> themselves assigning
> /64 prefixes to their links) then I think we should not 
> strive to respect aggregation.  Address aggregation wouldn't 
> make sense if we talk host-based routes either.
> 
> >> Charles, yes - the subnets are there first, before IP.  
> Once the link 
> >> is up the subnet is the set of nodes on it.  In this sense 
> I agree it 
> >> is just fine to pass subnet prefixes around.
> > 
> >  and address modes.  Then there are subnets. Some people 
> here probably 
> > remember when the word "subnet" starting coming into more 
> active use.
> > 
> > 
> However, I think the simplest cases we have to deal with have 
> very simple subnet structure that we should take advantage of.
> 
> Alex
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 04 Mar 2009 16:03:03 +0100

Stan Ratliff (sratliff) a écrit :
[...]
> We've already been over the 25m subnet thing. It's a non-starter. 
> Limiting movement, or mandating that a DHCP or DNS server is always 
> on and available is also a non-starter. 25m subnets with "always on" 
> DNS/DHCP servers sounds to me like a few guys gathering together to 
> play "Doom" at their local coffee shop. I deploy MANET networks for 
> governmental applications. Think disaster recovery, like after 
> Hurricane Katrina, or the last round of wildfires in California. Do 
> you think it appropriate to tell the firefighters "you can't let the 
> trucks get more than 25m apart, or your network breaks"? Or, "if your
>  DNS server should fail, just forget what you're doing and go home"?

No, I don't think it appropriate.

But I didn't mean to imply AUTOCONF networks span only 25meter range - 
they could be made of several such single subnets.

> So, once again, no -- 25m subnets don't make sense and won't work in 
> the environments where I'm deploying networks. Placing this type of 
> limitation on AUTOCONF will, IMO, make the work output useless.

How about a unit being a 25m subnet containing exposed terminals; and a
network growing as a chain of such units, linked by routers.  Would this
make more sense?

The disaster relief scenarios you describe also have certain limits of 
movements.  For example:
-firefighter never gets very far away from truck.
-among all intervening trucks only some are designated as special, for
  example command and control.
-etc.

Expressing this inherent structure in terms of subnet structure can be 
very useful.

Alex

>>> subnets, then I am basically not on the same page.  And not in 
>>> the
>> same decade.
>> 
>> Sorry I meant 25meters not millions.  A '25m IPv6 subnet' would be 
>> a wireless coverage area of radius 25meter, without obstacles, and 
>> within which there are only exposed terminals, fully transitive and
>>  symmetric communications.
>> 
>>>>  limit: AUTOCONF network is small enough to accommodate 
>>>> host-based routes.  Is it this?
>>> Again, just saying "subnet" doesn't buy even one gram of 
>>> additional scalability.  You need more.
>>> 
>> proposes a /60 prefix assigned to several Routers themselves 
>> assigning /64 prefixes to their links) then I think we should not 
>> strive to respect aggregation.  Address aggregation wouldn't make 
>> sense if we talk host-based routes either.
>> 
>>>>> Well, to me it did sound very negative.  Moreover, I think it
>>>>>  is just fine to pass around subnet prefixes, if you have 
>>>>> subnets.
>>> Second, just because nodes are reachable over the air as 
>>> neighbors, does not imply they are on the same IP subnet.  Trying
>>>  to maintain otherwise leads to madness.
>>> 
>>> Surely you will agree.  A subnet is an abstraction to support 
>>> more efficient routing.  It is not a wire or a piece of plastic 
>>> or a contiguous region of space.
>> I can live with that.
>> 
>> _______________________________________________ Autoconf mailing 
>> list [email-masked]

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 4 Mar 2009 10:30:49 -0500

Inline. 

> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Wednesday, March 04, 2009 10:03 AM
> To: Stan Ratliff (sratliff)
> Cc: Charles E. Perkins; [email-masked]
> > Limiting movement, or mandating that a DHCP or DNS server 
> is always on 
> > and available is also a non-starter. 25m subnets with "always on"
> But I didn't mean to imply AUTOCONF networks span only 
> 25meter range - they could be made of several such single subnets.
> 
> How about a unit being a 25m subnet containing exposed 
> terminals; and a network growing as a chain of such units, 
> linked by routers.  Would this make more sense?
> 

First off, you *can't* arbitrarily limit subnets to 25m. 25m from what? The center? And, how do you designate the center? Do you constantly re-calculate the center based on movement? Also, from a radio perspective, how do you tell how far apart you are in the first place? Do you suppose that all radios have GPS? That's a non-starter, because GPS signals aren't always available. And what about the wired MANET case brought up by Christopher Dearlove? Should we limit the cable runs? I could understand (but wouldn't really like) the notion of limiting the discussion to links that are transitive; but placing some arbitrary distance limit that's based on 802.11 just doesn't cut it for me. 

Regards,
Stan

> The disaster relief scenarios you describe also have certain 
> limits of movements.  For example:

- Not really. Firefighters regularly deploy at "some distance" from the truck. They go where they're needed, regardless of distance from the truck. Especially true in the case of people fighting wildfires in a forest.  

>   example command and control.

- If you designate some trucks as "special", then you limit the possible network deployments, and/or create single points of failure. The overall network isn't as resilient as it needs to be -- for instance, if you designate a truck as "special", and a burning tree falls on it, what now?

Stan

> -etc.
> 
> Expressing this inherent structure in terms of subnet 
> structure can be very useful.
> 
> Alex
> 
> > 
> > Stan
> > 
> > 
> would be a 
> >> wireless coverage area of radius 25meter, without obstacles, and 
> neighbors, 
> support more 
> >> [email-masked] https://www.ietf.org/mailman/listinfo/autoconf
> >> 
> > 
> 
> 
>

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 4 Mar 2009 17:53:56 +0100

Alex,

It happen to be I am working on the customer side, not the equipment vendor
/ supplier side.
I can say your limitations for 25meter and a requirement for relay nodes
with multiple interfaces are far, far from acceptable. I go for what Stan
says.
Sorry, I cannot go into details on what the specs are. I am not in the
position to say you, this is not the medium to publish and moreover, there
is no need for these details. We in IETF never went in this before (e.g.
there is no range limitation for ICMP messages).

Thanks, Teco

|-----Oorspronkelijk bericht-----
|Van: [email-masked] [mailto:[email-masked]] Namens
|Alexandru Petrescu
|Verzonden: woensdag 4 maart 2009 16:03
|Aan: Stan Ratliff (sratliff)
|CC: [email-masked]
|Onderwerp: Re: [Autoconf] Autoconf addressing model
|
|Stan Ratliff (sratliff) a écrit :
|[...]
|> We've already been over the 25m subnet thing. It's a non-starter.
|> Limiting movement, or mandating that a DHCP or DNS server is always
|> on and available is also a non-starter. 25m subnets with "always on"
|> DNS/DHCP servers sounds to me like a few guys gathering together to
|> play "Doom" at their local coffee shop. I deploy MANET networks for
|> governmental applications. Think disaster recovery, like after
|> Hurricane Katrina, or the last round of wildfires in California. Do
|> you think it appropriate to tell the firefighters "you can't let the
|> trucks get more than 25m apart, or your network breaks"? Or, "if your
|>  DNS server should fail, just forget what you're doing and go home"?
|
|No, I don't think it appropriate.
|
|But I didn't mean to imply AUTOCONF networks span only 25meter range -
|they could be made of several such single subnets.
|
|> So, once again, no -- 25m subnets don't make sense and won't work in
|> the environments where I'm deploying networks. Placing this type of
|> limitation on AUTOCONF will, IMO, make the work output useless.
|
|How about a unit being a 25m subnet containing exposed terminals; and a
|network growing as a chain of such units, linked by routers.  Would this
|make more sense?
|
|The disaster relief scenarios you describe also have certain limits of
|movements.  For example:
|-firefighter never gets very far away from truck.
|-among all intervening trucks only some are designated as special, for
|  example command and control.
|-etc.
|
|Expressing this inherent structure in terms of subnet structure can be
|very useful.
|
|Alex
|
|>
|> Stan
|>
|>
|>>> Watching your DNS server [(m) or not!] move from place to
|>> place in an
|>>> ad hoc network, sometimes finding itself partitioned from your
|>>> favorite node, could be an exciting and enlightening adventure.
|>> I agree we could find very dynamic ways of Routers and Hosts of an
|>> ad-hoc network moving in and out such that subnet structure is not
|>> maintained, and thus servers not being reachable.  But unless we
|>> describe these movements we can't deal with them.
|>>
|>>>>> Who said we had to avoid size limits?
|>>>> Well we don't have size limits in the charter proposal, we
|>> don't have
|>>>> agreement on '25m IPv6 subnets', we don't have limits on
|>> the types of
|>>>> the link layers involved.
|>>> If you are talking about an ad hoc network with 25,000,000
|>>> subnets, then I am basically not on the same page.  And not in
|>>> the
|>> same decade.
|>>
|>> Sorry I meant 25meters not millions.  A '25m IPv6 subnet' would be
|>> a wireless coverage area of radius 25meter, without obstacles, and
|>> within which there are only exposed terminals, fully transitive and
|>>  symmetric communications.
|>>
|>> Would you agree such a subnet makes sense?  Does not make sense?
|>>
|>>>> However, your question seems to imply you think there may be a
|>>>>  limit: AUTOCONF network is small enough to accommodate
|>>>> host-based routes.  Is it this?
|>>> I think the network has to accomodate the routes needed for
|>>> connectivity to destinations within the network.
|>>>
|>>> Again, just saying "subnet" doesn't buy even one gram of
|>>> additional scalability.  You need more.
|>>>
|>>> You need a procedure for enabling aggregation. Such a
|>> procedure is not
|>>> always available.
|>> If by aggregation is meant addressing aggregation (as Teco also
|>> proposes a /60 prefix assigned to several Routers themselves
|>> assigning /64 prefixes to their links) then I think we should not
|>> strive to respect aggregation.  Address aggregation wouldn't make
|>> sense if we talk host-based routes either.
|>>
|>>>>> Well, to me it did sound very negative.  Moreover, I think it
|>>>>>  is just fine to pass around subnet prefixes, if you have
|>>>>> subnets.
|>>>> Charles, yes - the subnets are there first, before IP.
|>> Once the link
|>>>> is up the subnet is the set of nodes on it.  In this sense
|>> I agree it
|>>>> is just fine to pass subnet prefixes around.
|>>> This is wrong*2.   First, there is IP, which fixes the
|>> address format
|>>> and address modes.  Then there are subnets. Some people
|>> here probably
|>>> remember when the word "subnet" starting coming into more
|>> active use.
|>>>
|>>> Second, just because nodes are reachable over the air as
|>>> neighbors, does not imply they are on the same IP subnet.  Trying
|>>>  to maintain otherwise leads to madness.
|>>>
|>>> Surely you will agree.  A subnet is an abstraction to support
|>>> more efficient routing.  It is not a wire or a piece of plastic
|>>> or a contiguous region of space.
|>> I can live with that.
|>>
|>> However, I think the simplest cases we have to deal with have very
|>> simple subnet structure that we should take advantage of.
|>>
|>> Alex
|>>
|>> _______________________________________________ Autoconf mailing
|>> list [email-masked]
|>> https://www.ietf.org/mailman/listinfo/autoconf
|>>
|>
|
|
|_______________________________________________
|Autoconf mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/autoconf

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 04 Mar 2009 18:20:06 +0100

Teco Boot a écrit :
> Alex,
> 
> It happen to be I am working on the customer side, not the equipment
> vendor / supplier side. I can say your limitations for 25meter and a
> requirement for relay nodes with multiple interfaces are far, far
> from acceptable. I go for what Stan says. Sorry, I cannot go into
> details on what the specs are. I am not in the position to say you,
> this is not the medium to publish and moreover, there is no need for
> these details. We in IETF never went in this before (e.g. there is no
> range limitation for ICMP messages).

I meant to say to explicitely consider the characteristics of the
link-layers you consider for AUTOCONF ad-hoc networks.  These all have
specifications about their physical lengths (for wired), for dbm
powerlevels and range in meters (wireless).

I can't build a network without knowing these specifications
in detail; its IP addressing architecture is impossible to agree on.

Alex

> 
> Thanks, Teco
> 
> |-----Oorspronkelijk bericht----- |Van: [email-masked]
> [mailto:[email-masked]] Namens |Alexandru Petrescu 
> |Verzonden: woensdag 4 maart 2009 16:03 |Aan: Stan Ratliff (sratliff)
>  |CC: [email-masked] |Onderwerp: Re: [Autoconf] Autoconf
> addressing model | |Stan Ratliff (sratliff) a écrit : |[...] |> We've
> already been over the 25m subnet thing. It's a non-starter. |>
> |> on and available is also a non-starter. 25m subnets with "always
> on" |> DNS/DHCP servers sounds to me like a few guys gathering
> together to |> play "Doom" at their local coffee shop. I deploy MANET
> networks for |> governmental applications. Think disaster recovery,
> like after |> Hurricane Katrina, or the last round of wildfires in
> California. Do |> you think it appropriate to tell the firefighters
> "you can't let the |> trucks get more than 25m apart, or your network
> breaks"? Or, "if your |>  DNS server should fail, just forget what
> you're doing and go home"? | |No, I don't think it appropriate. | 
> |But I didn't mean to imply AUTOCONF networks span only 25meter range
> - |they could be made of several such single subnets. | |> So, once
> again, no -- 25m subnets don't make sense and won't work in |> the
> environments where I'm deploying networks. Placing this type of |>
> limitation on AUTOCONF will, IMO, make the work output useless. | 
> |How about a unit being a 25m subnet containing exposed terminals;
> and a |network growing as a chain of such units, linked by routers.
> Would this |make more sense? | |The disaster relief scenarios you
> describe also have certain limits of |movements.  For example: 
> |-firefighter never gets very far away from truck. |-among all
> intervening trucks only some are designated as special, for |
> example command and control. |-etc. | |Expressing this inherent
> structure in terms of subnet structure can be |very useful. | |Alex |
>  |> |> Stan |> |> |>>> Watching your DNS server [(m) or not!] move
> from place to |>> place in an |>>> ad hoc network, sometimes finding
> itself partitioned from your |>>> favorite node, could be an exciting
> and enlightening adventure. |>> I agree we could find very dynamic
> ways of Routers and Hosts of an |>> ad-hoc network moving in and out
> such that subnet structure is not |>> maintained, and thus servers
> not being reachable.  But unless we |>> describe these movements we
> can't deal with them. |>> |>>>>> Who said we had to avoid size
> limits? |>>>> Well we don't have size limits in the charter proposal,
> we |>> don't have |>>>> agreement on '25m IPv6 subnets', we don't
> have limits on |>> the types of |>>>> the link layers involved. |>>>
> If you are talking about an ad hoc network with 25,000,000 |>>>
> subnets, then I am basically not on the same page.  And not in |>>>
> the |>> same decade. |>> |>> Sorry I meant 25meters not millions.  A
> '25m IPv6 subnet' would be |>> a wireless coverage area of radius
> 25meter, without obstacles, and |>> within which there are only
> exposed terminals, fully transitive and |>>  symmetric
> communications. |>> |>> Would you agree such a subnet makes sense?
> Does not make sense? |>> |>>>> However, your question seems to imply
> you think there may be a |>>>>  limit: AUTOCONF network is small
> enough to accommodate |>>>> host-based routes.  Is it this? |>>> I
> think the network has to accomodate the routes needed for |>>>
> connectivity to destinations within the network. |>>> |>>> Again,
> just saying "subnet" doesn't buy even one gram of |>>> additional
> scalability.  You need more. |>>> |>>> You need a procedure for
> enabling aggregation. Such a |>> procedure is not |>>> always
> available. |>> If by aggregation is meant addressing aggregation (as
> Teco also |>> proposes a /60 prefix assigned to several Routers
> themselves |>> assigning /64 prefixes to their links) then I think we
> should not |>> strive to respect aggregation.  Address aggregation
> wouldn't make |>> sense if we talk host-based routes either. |>> 
> |>>>>> subnets. |>>>> Charles, yes - the subnets are there first,
> before IP. |>> Once the link |>>>> is up the subnet is the set of
> nodes on it.  In this sense |>> I agree it |>>>> is just fine to pass
> subnet prefixes around. |>>> This is wrong*2.   First, there is IP,
> which fixes the |>> address format |>>> and address modes.  Then
> there are subnets. Some people |>> here probably |>>> remember when
> the word "subnet" starting coming into more |>> active use. |>>> |>>>
> Second, just because nodes are reachable over the air as |>>>
> |>>>  to maintain otherwise leads to madness. |>>> |>>> Surely you
> will agree.  A subnet is an abstraction to support |>>> more
> efficient routing.  It is not a wire or a piece of plastic |>>> or a
> contiguous region of space. |>> I can live with that. |>> |>>
> |>> simple subnet structure that we should take advantage of. |>> |>>
> Alex |>> |>> _______________________________________________ Autoconf
> mailing |>> list [email-masked] |>>
> https://www.ietf.org/mailman/listinfo/autoconf |>> |> | | 
> |_______________________________________________ |Autoconf mailing
> list [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 04 Mar 2009 18:29:17 +0100

Stan Ratliff (sratliff) a écrit :
> First off, you *can't* arbitrarily limit subnets to 25m. 25m from 
> what? The center?

Yes, an area of 25meters with a wifi access point in the center.

> And, how do you designate the center? Do you constantly re-calculate
>  the center based on movement?

No, not constantly re-computed.  But have a fixed view at a point in
time.  Saying everything varies isn't helpful either.

> Also, from a radio perspective, how do you tell how far apart you are
>  in the first place? Do you suppose that all radios have GPS? That's
> a non-starter, because GPS signals aren't always available.

No I didn't suppose GPS is available on each device, it wouldn't work
well under foliage.  Just a rough evaluation of a specific link-layer
radio range, correspondign to widely used networks.

> And what about the wired MANET case brought up by Christopher
> Dearlove? Should we limit the cable runs?

YEs, certainly.  All cabled link-layers have specific limitations on 
their lengths: 2m USB, 50m Ethernet Category6 (IIRC) and so on.

> I could understand (but
> wouldn't really like) the notion of limiting the discussion to links
> that are transitive; but placing some arbitrary distance limit that's
> based on 802.11 just doesn't cut it for me.

802.11 is being used widely, no reason to ignore.

I'd happily accept to add another specific limitation, from the 
link-layer of your choice.  And be speecifically addressing these two 
link layers.  And maybe three.  No more than three.

I find addressing them all to be difficult for me.

(about single point of failure being destroyed by a falling tree:
  problem could be addressed at its layer: don't move the command center
  under trees risking falling); or maybe have two command centers, but
  specificllay two, not an arbitrary large unknown number.

Alex

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 04 Mar 2009 09:35:13 -0800

Hello Alex,

> By not moving too much I mean each node not moving out of its 25meter

This 25m radius is not legislated nor approved by the working group.
I don't see anyone else supporting your contention here, and I think the
sooner we resolve that there is no such limitation, the better.

Which then almost immediately invalidates your observation about DNS
and DHCP servers.

> describe these movements we can't deal with them.

I maintain that it is not necessary, not always possible, and thus
not relevant to the discussion.

>
> .  A '25m IPv6 subnet' would be a

By now I hope it is clear that I don't agree with equating subnets
with physical extents.

> host-based routes either.

If you don't have aggregation, you don't have any reason
to define subnets.  Of course if you don't have aggregation,
you can just as easily live with host routes.  Which is my
point all along.

> simple subnet structure that we should take advantage of.

Surely, if we have economically realizable subnets, we should
take advantage of them.  That is not at all the same as insisting
that we _must_ have subnets, or even worse distorting physical
reality to lend credence to some fictional subnet boundaries.

Regards,
Charlie P.

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 4 Mar 2009 20:35:39 +0100

Inline.

|-----Oorspronkelijk bericht-----
|Van: Alexandru Petrescu [mailto:[email-masked]]
|Verzonden: woensdag 4 maart 2009 18:20
|Aan: Teco Boot
|CC: 'Alexandru Petrescu'; 'Stan Ratliff (sratliff)'; [email-masked]
|Onderwerp: Re: [Autoconf] Autoconf addressing model
|
|Teco Boot a écrit :
|> Alex,
|>
|> It happen to be I am working on the customer side, not the equipment
|> vendor / supplier side. I can say your limitations for 25meter and a
|> requirement for relay nodes with multiple interfaces are far, far
|> from acceptable. I go for what Stan says. Sorry, I cannot go into
|> details on what the specs are. I am not in the position to say you,
|> this is not the medium to publish and moreover, there is no need for
|> these details. We in IETF never went in this before (e.g. there is no
|> range limitation for ICMP messages).
|
|I meant to say to explicitely consider the characteristics of the
|link-layers you consider for AUTOCONF ad-hoc networks.  These all have
|specifications about their physical lengths (for wired), for dbm
|powerlevels and range in meters (wireless).

The problem with this is that it is of almost no use for an ad hoc network.
Ad hoc means "to this", "for this purpose". It refers to dealing with
special situations as they occur rather than functions that are repeated on
a regular basis. (http://www.answers.com/topic/ad-hoc). Or "created on the
spur of the moment, impromptu" (http://en.wiktionary.org/wiki/ad_hoc).

|I can't build a network without knowing these specifications
|in detail; its IP addressing architecture is impossible to agree on.

Why do you think you were asked to build a network?
All we ask is a little cooperation in our common goal defining an Autoconf
mechanisms for MANETs.

Teco.

|Alex
|
|>
|> Thanks, Teco
|>
|> |-----Oorspronkelijk bericht----- |Van: [email-masked]
|> [mailto:[email-masked]] Namens |Alexandru Petrescu
|> |Verzonden: woensdag 4 maart 2009 16:03 |Aan: Stan Ratliff (sratliff)
|>  |CC: [email-masked] |Onderwerp: Re: [Autoconf] Autoconf
|> addressing model | |Stan Ratliff (sratliff) a écrit : |[...] |> We've
|> already been over the 25m subnet thing. It's a non-starter. |>
|> Limiting movement, or mandating that a DHCP or DNS server is always
|> |> on and available is also a non-starter. 25m subnets with "always
|> on" |> DNS/DHCP servers sounds to me like a few guys gathering
|> together to |> play "Doom" at their local coffee shop. I deploy MANET
|> networks for |> governmental applications. Think disaster recovery,
|> like after |> Hurricane Katrina, or the last round of wildfires in
|> California. Do |> you think it appropriate to tell the firefighters
|> "you can't let the |> trucks get more than 25m apart, or your network
|> breaks"? Or, "if your |>  DNS server should fail, just forget what
|> you're doing and go home"? | |No, I don't think it appropriate. |
|> |But I didn't mean to imply AUTOCONF networks span only 25meter range
|> - |they could be made of several such single subnets. | |> So, once
|> again, no -- 25m subnets don't make sense and won't work in |> the
|> environments where I'm deploying networks. Placing this type of |>
|> limitation on AUTOCONF will, IMO, make the work output useless. |
|> |How about a unit being a 25m subnet containing exposed terminals;
|> and a |network growing as a chain of such units, linked by routers.
|> Would this |make more sense? | |The disaster relief scenarios you
|> describe also have certain limits of |movements.  For example:
|> |-firefighter never gets very far away from truck. |-among all
|> intervening trucks only some are designated as special, for |
|> example command and control. |-etc. | |Expressing this inherent
|> structure in terms of subnet structure can be |very useful. | |Alex |
|>  |> |> Stan |> |> |>>> Watching your DNS server [(m) or not!] move
|> from place to |>> place in an |>>> ad hoc network, sometimes finding
|> itself partitioned from your |>>> favorite node, could be an exciting
|> and enlightening adventure. |>> I agree we could find very dynamic
|> ways of Routers and Hosts of an |>> ad-hoc network moving in and out
|> such that subnet structure is not |>> maintained, and thus servers
|> not being reachable.  But unless we |>> describe these movements we
|> can't deal with them. |>> |>>>>> Who said we had to avoid size
|> limits? |>>>> Well we don't have size limits in the charter proposal,
|> we |>> don't have |>>>> agreement on '25m IPv6 subnets', we don't
|> have limits on |>> the types of |>>>> the link layers involved. |>>>
|> If you are talking about an ad hoc network with 25,000,000 |>>>
|> subnets, then I am basically not on the same page.  And not in |>>>
|> the |>> same decade. |>> |>> Sorry I meant 25meters not millions.  A
|> '25m IPv6 subnet' would be |>> a wireless coverage area of radius
|> 25meter, without obstacles, and |>> within which there are only
|> exposed terminals, fully transitive and |>>  symmetric
|> communications. |>> |>> Would you agree such a subnet makes sense?
|> Does not make sense? |>> |>>>> However, your question seems to imply
|> you think there may be a |>>>>  limit: AUTOCONF network is small
|> enough to accommodate |>>>> host-based routes.  Is it this? |>>> I
|> think the network has to accomodate the routes needed for |>>>
|> connectivity to destinations within the network. |>>> |>>> Again,
|> just saying "subnet" doesn't buy even one gram of |>>> additional
|> scalability.  You need more. |>>> |>>> You need a procedure for
|> enabling aggregation. Such a |>> procedure is not |>>> always
|> available. |>> If by aggregation is meant addressing aggregation (as
|> Teco also |>> proposes a /60 prefix assigned to several Routers
|> themselves |>> assigning /64 prefixes to their links) then I think we
|> should not |>> strive to respect aggregation.  Address aggregation
|> wouldn't make |>> sense if we talk host-based routes either. |>>
|> |>>>>> Well, to me it did sound very negative.  Moreover, I think it
|> |>>>>>  is just fine to pass around subnet prefixes, if you have
|> |>>>>> subnets. |>>>> Charles, yes - the subnets are there first,
|> before IP. |>> Once the link |>>>> is up the subnet is the set of
|> nodes on it.  In this sense |>> I agree it |>>>> is just fine to pass
|> subnet prefixes around. |>>> This is wrong*2.   First, there is IP,
|> which fixes the |>> address format |>>> and address modes.  Then
|> there are subnets. Some people |>> here probably |>>> remember when
|> the word "subnet" starting coming into more |>> active use. |>>> |>>>
|> Second, just because nodes are reachable over the air as |>>>
|> neighbors, does not imply they are on the same IP subnet.  Trying
|> |>>>  to maintain otherwise leads to madness. |>>> |>>> Surely you
|> will agree.  A subnet is an abstraction to support |>>> more
|> efficient routing.  It is not a wire or a piece of plastic |>>> or a
|> contiguous region of space. |>> I can live with that. |>> |>>
|> However, I think the simplest cases we have to deal with have very
|> |>> simple subnet structure that we should take advantage of. |>> |>>
|> Alex |>> |>> _______________________________________________ Autoconf
|> mailing |>> list [email-masked] |>>
|> https://www.ietf.org/mailman/listinfo/autoconf |>> |> | |
|> |_______________________________________________ |Autoconf mailing
|> list [email-masked]
|> |https://www.ietf.org/mailman/listinfo/autoconf
|>
|>

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 4 Mar 2009 16:35:22 -0500

> Sent: Wednesday, March 04, 2009 12:29 PM

*By definition*, what you describe is not a MANET. As you state, that's just a WiFi access point. That's already solved -- 802.11 clients can roam from access point to access point. But again, this should not be an 802.11-centric discussion. 

> No, not constantly re-computed.  But have a fixed view at a 
> point in time.  Saying everything varies isn't helpful either.
> 

It may not be helpful, but it's reality. You can't rely on a fixed view of a dynamic network; again, by definition, there's movement in a MANET. Links come and go, and link quality varies from moment to moment.

> > in the first place? Do you suppose that all radios have 
> GPS? That's a 
> > non-starter, because GPS signals aren't always available.
> 
> No I didn't suppose GPS is available on each device, it 
> wouldn't work well under foliage.  Just a rough evaluation of 
> a specific link-layer radio range, correspondign to widely 
> used networks.
> 
> YEs, certainly.  All cabled link-layers have specific 
> limitations on their lengths: 2m USB, 50m Ethernet Category6 
> (IIRC) and so on.
> 
> > I could understand (but

I'm not advocating we "ignore" 802.11, or any other L2 technology, for that matter. I'm advocating that we remain Layer 2 agnostic. As Teco mentioned in another email, there are people in this WG that don't deploy MANET networks based on 802.11, or 802.16, or 802.15.4.

> 
> I'd happily accept to add another specific limitation, from 
> the link-layer of your choice.  And be speecifically 
> addressing these two link layers.  And maybe three.  No more 
> than three.
> 

I don't understand why the Layer 3 addressing scheme needs to be predicated on a specific Layer 2 technology, or set of technologies. The Layer 3 addressing scheme should be totally independent of Layer 2 -- isn't that what layering is all about?

>   specificllay two, not an arbitrary large unknown number.

That essentially boils down to "if it hurts, don't do it", and it doesn't work for my customers. Their environments are dynamic, and they need the ability to respond to ever-changing realities on the ground. 

At this point, I feel that we're in a discussion that is becoming more and more circular, and therefore, dysfunctional. And that, IMO, has been the unfortunate reality of this WG since its inception. 

Regards,
Stan

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 4 Mar 2009 23:57:47 +0100

Hi Charlie,

Yes, I think the issues in this thread touch our basic problems. Here some
follow-up:

- on little wireless nodes that have a single interface:
The scope of MANETs is quite large, e.g. from aircraft carriers to smart
dust. For the most tiny devices, I am not sure we should deal with these.
There are other WGs working on PAN / sensor networks, maybe we could focus
on the somewhat larger stuff. And were a device type have a single
interface, new versions in this category may have more. 
Example: my 8 years old phone has 2 wireless interfaces, 1 wired and one IR.
Only one is IP enabled. Maybe I'll buy a new one some time, I think this one
would have almost all interfaces IP enabled and it would have more than 4
interfaces.

- on guideline for using router loopback interface for management:
I think this is a no-brainer for ISP / enterprise network engineers. Many
documents provide this advice, but I was looking for something that has not
a logo from a certain company. The problem here is, this company has a high
market share in this arena and also publish a lot of guidelines.
Here some refs, I hope this will convince you this is a well accepted
practice.
http://www.apnic.net/training/download/irm-1/irm1-7-addrplan.pdf
http://ws.edu.isoc.org/data/2004/604610702427ef01785c49/loopback-6up.pdf
ftp://ftp.hp.com/pub/networking/software/ProCurve-SR-BGP-Config-Guide-08-05.
pdf
http://www.juniper.net/techpubs/software/junos-es/junos-es92/junos-es-swconf
ig-interfaces-and-routing/special-interfaces.html#loopback-interface-section
http://www.apnic.net/meetings/26/program/apops/transcript.html#yoshinobu-arc
hitecture

- on status of address / interface; socket api for this:
I discussed this with some colleagues, on what the requirements are. We came
to the conclusion that applications should be able to select an address that
belongs to a stable (ifup) interface, e.g. the loopback interface.
Applications should also be able to select an address that belongs to a
physical interface. Multicast applications can take benefits here. Having
different options could make defining default behavior somewhat complex.
Shim mechanisms (MIP/MIP6, Shim6, HIP) and socket interfaces based on names
hide addressing details from the applications. But such an approach may
affect applications for high availability, and in my environment this is
important.

== back to the addressing model:
After some more thoughts, I come to the conclusion that MANET Routers should
advertize as little as possible, for reducing overhead. This is about
routing prefixes. The advertized prefix should "belong" to the indivisible
"mobile object", this means the summary prefix must not split and
sub-prefixes (subnets??) shall be interconnected within the "mobile object".
Single router "mobile object" has this behavior by nature.
Addresses assigned to interfaces come from the advertized prefix and may
have any prefix-length equal or longer than the advertized prefix-length.
Loopback interfaces should have /128 (or /32), as defined in RFCs for this.
Ethernet typically have /64, this is specified in std track RFC and it is a
MUST if SLAAC is used.
Still the question on using /128, /64 or other for globally unique
address-prefixes that are assigned to MANET interfaces of this "mobile
object". Maybe we do not need to restrict this. Mentioning the options and
the consequences is good enough, I think. 
Some consequences with /127 are described in RFC3627. This RFC also mentions
/128: 
      Using two /128 addresses is also one, though often cumbersome,
      approach.  Naturally, not much would be lost if even a shorter
      prefix was used, e.g., /112 or /120.

The diagram in MANET-ARCH 5.1 could be adjusted to reflect my thoughts.
Below, it is more an example and less a "model".

                 <~~~~~~+~~~~~~>
                        |    Assigned Prefix   
                        |    ===================
   2001:db8:0::EUI-64/64| <=== 2001:db8:0::/64 =   
         FE80::EUI-64/64|    ===================             
         MANET Interface|                         Delegated Prefix
           +-----------------------+              /-------------\
           |                       | <<<<<<<<<<<<| 2001:db8::/60 |
           |       MANET           |              \-------------/
           |       Router          |
           |                       |    
           |  ...................  |    Assigned Prefix
           |  !Loopback         !  |    =====================
           |  !2001:db8:F::0/128!  | <=== 2001:db8:F::0/128 =   
           |  '''''''''''''''''''  |    =====================
           +---------------+-------+    
         Ethernet Interface:          Assigned Prefix
            FE80::EUI-64/64:          ===================
      2001:db8:1::EUI-64/64:  <======== 2001:db8:1::/64 =      
                           :          ===================
                    ..............    
                    :            :      
     FE80::EUI-64/64:            :FE80::EUI-64/64
 2001:db8:1::dhcp/64:            :2001:db8:1::EUI-64/64
     +--------------+-+       +--+--------------+
     | Host with DHCP | * * * | Host with SLAAC |
     +----------------+       +-----------------+

In a table format:

 Delegated summary prefix:      2001:db8::/60
   15 x /64: MANET Interface:	       2001:db8:0::/64
             Ethernet Interface:     2001:db8:1::/64
               " "     " "             " "     "
             up to:                  2001:db8:E::/64
   Block for longer prefix lengths:  2001:db8:F::/64      
     Loopback Interface #0:              2001:db8:F::0/128
     (others, e.g. P2P)                    " "     "

This model provides RFC4862 SLAAC service for nearby hosts, also useful for
MANET Router (or NEMO Router) bootstrapping. For getting a delegated prefix,
the a SLAAC address could be used for communication with a DHCP server,
using unicast (to be verified). Important: the /64 prefix that corresponds
with the SLAAC address-prefix MUST NOT be advertized in the MANET Routing
Protocol. Advertizing this as a host prefix is allowed, but getting an own
/60 or whatsoever summary is advised. The result here is a MANET Routing
Protocol requirement (not advertizing /64 SLAAC prefixes).
The MANET Router may act as DHCP Server (or relay agent) for its Delegated
Prefix(es). SLAAC is also supported.

On dec 2007 I posted similar thoughts
(http://www.ietf.org/mail-archive/web/autoconf/current/msg00901.html).
Are we making progress? I think: yes!

Teco.

|-----Oorspronkelijk bericht-----
|Van: Charles E. Perkins [mailto:[email-masked]]
|Verzonden: woensdag 4 maart 2009 0:27
|Aan: Teco Boot
|CC: [email-masked]
|Onderwerp: Re: [Autoconf] Autoconf addressing model
|
|
|Hello Teco,
|
|You raise interesting questions, but I think mostly
|not definitive for the questions at hand.  I don't know
|if I have any good answers, but here are some comments.
|
|Teco Boot wrote:
|> As long as I designed and maintained network infrastructures, I worked
|with
|> "/32 management addresses" on loopback interfaces. Still, I have
|annoying
|> experiences with routers that select the outgoing interface address as
|> default source address. Shutting down an interface could have
|unintended bad
|> impact on your terminal session. Same for link flapping due to other
|causes.
|>
|
|I guess this is relevant for packet forwarders with more than one
|network interface.  For our little wireless nodes that have a single
|interface, I don't imagine we'd see that kind of interface aggravation.
|
|> For this reason, many routers on the Internet use the loopback
|interface for
|> "management". "Management" is the host application on routers. There
|are
|> lots of design guidelines for this. My proposal is using the "Internet
|> lessons learned" in the MANET. Nothing wrong with this, agreed?
|>
|
|I know only a small bit about this.  Do you have a favorite
|document that I could read to learn more?
|
|>
|> With MobileIP, we are discussing a host (could be NEMO Router, but
|then it
|> acts as host on the visiting link). The MobileIP stack is interested
|in the
|> status of the visiting link, but does it propagate this to the
|applications?
|> Or use the applications some kind of virtual interface (e.g. a
|loopback
|> interface)? Or spoof ifup for interface to home link?
|>
|
|Whether or not applications have access to link information is
|something not closely related to Mobile IP.  Whether or not
|the care-of address is available to applications is a surprisingly
|complicated question, which in my opinion opens the door to
|many interesting questions and indicates the insufficiency of
|today's typical application socket interface.
|
|I've had a lot of ideas about how to fix this, but never been
|able to initiate a project to supply a finished proposal.
|
|
|Regards,
|Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Mar 2009 00:41:05 +0100

> Below, it is more an example and less a "model".

In the above figure: I agree with many points that I won't mention.

But I don't agree using the loopback interface for this.

And I don't understand why there's a "MANET Interface" and a "Ethernet 
interface".  I really don't see the need for any virtual interface.

Let me give my take on virtual interfaces...

Some routing protocols use virtual interfaces because at least the 
following problem: it has been shown in practice that when a e.g. wifi 
interface gets disassociated from the AP the interface may go down, and 
in some implementations it may SIGKILL (or worse) the app using that 
socket.  And if the app is the routing protocol the net effect is very 
bad: routing protocol crashes.  This was very bad.  It also meant that 
whenever I would disconnect the Ethernet cable (on some implementations, 
again), the routing protocol implementation would crash; or when my 
bluetooth interface gets down.  Or similar 'mobility' event which would 
never previously appear in the fixed-router-Internet, because people 
wouldn't consciously disconnect Ethernet cables whereas phone lines 
would still get jammed (a modem line being overloaded wouldn't SIGKILL 
the app running on that kernel, because modem separated from computer by 
rs-232 and rs-232 no interface structure).

To cope with that, put up a virtual interface and add routes between 
that virtual interface and the wifi interface.  And run the routing 
protocol on top of _that_ virtual interface instead of the wifi 
interface.  Since it is virtual it never gets down (unless maybe a tree 
falls), the routing protocol implementation will crash less.  It was 
thus shown that the routing protocol running on a virtual interface is 
advantageous, dealing better with mobility events - at least it could be 
deterministic!

However, there exist also implementations of wifi drivers which won't 
put the interface down when the interface gets dissasociated.  Also 
there exist kernels which won't SIGKILL the app, and there exist also 
protocols implementations who'd deal with that SIGKILL more gently if it 
popped up.

Also there exist implementations of routing protocols who would not deal 
at all with any particular interface structure (be that real or virtual) 
- they're independent on the kernel's interface structures being up or 
down or whatever state, but use directly the card's buffers to send or 
receive data.  I agree though these implementations are less widespread.

Overall, I think a safe bet is somewhere in the middle: to not talk 
about virtual interfaces (neither loopback, nor others) but only about 
real interfaces and of specific types.  And to consider the virtual 
interfaces to be a detail of _some_ implementations.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Mar 2009 00:45:22 +0100

> spur of the moment, impromptu" (http://en.wiktionary.org/wiki/ad_hoc).

Along these lines, an interpretation of 'ad-hoc' is a happening which 
hasn't been planned, spontaneous, etc.  This would contradict the goal 
of planning an addressing architecture for it, unless the limits of 
movement and the characteristics of the underlying link-layers are noted.

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 5 Mar 2009 08:50:52 +0100

|-----Oorspronkelijk bericht-----
|Van: Alexandru Petrescu [mailto:[email-masked]]
|Verzonden: donderdag 5 maart 2009 0:45
|Aan: Teco Boot
|CC: 'Alexandru Petrescu'; 'Stan Ratliff (sratliff)'; [email-masked]
|Onderwerp: Re: [Autoconf] Autoconf addressing model
|
|Teco Boot a écrit :
|> Inline.
|>
|> |-----Oorspronkelijk bericht-----
|> |Van: Alexandru Petrescu [mailto:[email-masked]]
|> |Verzonden: woensdag 4 maart 2009 18:20
|> |Aan: Teco Boot
|> |CC: 'Alexandru Petrescu'; 'Stan Ratliff (sratliff)';
[email-masked]
|> |Onderwerp: Re: [Autoconf] Autoconf addressing model
|> |
|> |Teco Boot a écrit :
|> |> Alex,
|> |>
|> |> It happen to be I am working on the customer side, not the
|equipment
|> |> vendor / supplier side. I can say your limitations for 25meter and
|a
|> |> requirement for relay nodes with multiple interfaces are far, far
|> |> from acceptable. I go for what Stan says. Sorry, I cannot go into
|> |> details on what the specs are. I am not in the position to say you,
|> |> this is not the medium to publish and moreover, there is no need
|for
|> |> these details. We in IETF never went in this before (e.g. there is
|no
|> |> range limitation for ICMP messages).
|> |
|> |I meant to say to explicitely consider the characteristics of the
|> |link-layers you consider for AUTOCONF ad-hoc networks.  These all
|have
|> |specifications about their physical lengths (for wired), for dbm
|> |powerlevels and range in meters (wireless).
|>
|> The problem with this is that it is of almost no use for an ad hoc
|network.
|> Ad hoc means "to this", "for this purpose". It refers to dealing with
|> special situations as they occur rather than functions that are
|repeated on
|> a regular basis. (http://www.answers.com/topic/ad-hoc). Or "created on
|the
|> spur of the moment, impromptu" (http://en.wiktionary.org/wiki/ad_hoc).
|
|Along these lines, an interpretation of 'ad-hoc' is a happening which
|hasn't been planned, spontaneous, etc.  This would contradict the goal
|of planning an addressing architecture for it, unless the limits of
|movement and the characteristics of the underlying link-layers are
|noted.

There is a difference in a) designing and building a network, ready for
deployment and b) planning for actual deployment. In military, actual
deployment does not occur quite often (luckily!), but it is exercised
repeatedly. For public safety / disaster relief, the network is often in use
for normal conditions (no disaster), here we may have restrictions as you
suggest. But as soon as there is a disaster (small, large), the conditions
may no longer be true. Here also, the large disasters do not occur
frequently. But if it occurs, damage can be huge. 
For both use cases (military and disaster relief), the requirement is that
the network provides as much connectivity as technically possible, also in
unforeseen conditions. Sorry to bother you with one of the major
requirements I am facing, and I am sure I am not the only one. As said,
MANET is being worked on for many years and actually being deployed.

I described the difference in designing and planning deployment. For
designing the network, we need components that have certain characteristics,
e.g. working well in an ad hoc (unplanned) fashion. IMHO this means, that
when a radio link works well over 25 meter, and it is being used in 30 meter
or an obstacle breaks the link or makes it uni-directional (see my diagrams
for details), the network may not melt down. Connectivity should restored
using alternative paths if available and feasible.

Let's go on with refinement an address model for MANETs. This is more
important than quarreling on 25m or analyzing wording, I think.

Teco.

|
|Alex

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 5 Mar 2009 09:43:02 +0100

|-----Oorspronkelijk bericht-----
|Van: Alexandru Petrescu [mailto:[email-masked]]
|Verzonden: donderdag 5 maart 2009 0:41
|Aan: Teco Boot
|CC: [email-masked]
|Onderwerp: Re: [Autoconf] Autoconf addressing model
|
|Teco Boot a écrit :

|> == back to the addressing model:
|> After some more thoughts, I come to the conclusion that MANET Routers
|should
|> advertize as little as possible, for reducing overhead. This is about
|> routing prefixes. The advertized prefix should "belong" to the
|indivisible
|> "mobile object", this means the summary prefix must not split and
|> sub-prefixes (subnets??) shall be interconnected within the "mobile
|object".
|> Single router "mobile object" has this behavior by nature.
|> Addresses assigned to interfaces come from the advertized prefix and
|may
|> have any prefix-length equal or longer than the advertized prefix-
|length.
|> Loopback interfaces should have /128 (or /32), as defined in RFCs for
|this.
|> Ethernet typically have /64, this is specified in std track RFC and it
|is a
|> MUST if SLAAC is used.
|> Still the question on using /128, /64 or other for globally unique
|> address-prefixes that are assigned to MANET interfaces of this "mobile
|> object". Maybe we do not need to restrict this. Mentioning the options
|and
|> the consequences is good enough, I think.
|> Some consequences with /127 are described in RFC3627. This RFC also
|mentions
|> /128:
|>       Using two /128 addresses is also one, though often cumbersome,
|>       approach.  Naturally, not much would be lost if even a shorter
|>       prefix was used, e.g., /112 or /120.
|>
|>
|> The diagram in MANET-ARCH 5.1 could be adjusted to reflect my
|thoughts.
|> Below, it is more an example and less a "model".
|>
|>
|>                  <~~~~~~+~~~~~~>
|>                         |    Assigned Prefix
|>                         |    ===================
|>    2001:db8:0::EUI-64/64| <=== 2001:db8:0::/64 =
|>          FE80::EUI-64/64|    ===================
|>          MANET Interface|                         Delegated Prefix
|>            +-----------------------+              /-------------\
|>            |                       | <<<<<<<<<<<<| 2001:db8::/60 |
|>            |       MANET           |              \-------------/
|>            |       Router          |
|>            |                       |
|>            |  ...................  |    Assigned Prefix
|>            |  !Loopback         !  |    =====================
|>            |  !2001:db8:F::0/128!  | <=== 2001:db8:F::0/128 =
|>            |  '''''''''''''''''''  |    =====================
|>            +---------------+-------+
|>          Ethernet Interface:          Assigned Prefix
|>             FE80::EUI-64/64:          ===================
|>       2001:db8:1::EUI-64/64:  <======== 2001:db8:1::/64 =
|>                            :          ===================
|>                     ..............
|>                     :            :
|>      FE80::EUI-64/64:            :FE80::EUI-64/64
|>  2001:db8:1::dhcp/64:            :2001:db8:1::EUI-64/64
|>      +--------------+-+       +--+--------------+
|>      | Host with DHCP | * * * | Host with SLAAC |
|>      +----------------+       +-----------------+
|
|In the above figure: I agree with many points that I won't mention.

Thanks.

|But I don't agree using the loopback interface for this.

You don't have to. I mean by this, I will not enforce using a loopback. I
only lists the advantages, which you didn't agree on. I posted reference to
some material that proves using loopback interfaces is BCP in ISP and
enterprise, and I think every addressing model MUST support loopback
interfaces. Please reply [ agree | not agree ]. Please take some time to
understand the consequence of your answer, you may lock-out yourself being
not compatible with many others. I think: we in IETF do your utmost to be
compatible.

Having said this, I will be compatible with you if you do not use loopback
interfaces (open door for me). I would not use loopback interfaces in every
case myself (posted before, example was applications for high availability
that manage interface state themselves). I also strive to reduce host routes
to the maximum extend, for efficiency (ales posted before). In this case my
loopback is hidden for you. If not hidden by summarization, I publish a host
prefix. 

|And I don't understand why there's a "MANET Interface" and a "Ethernet
|interface".  I really don't see the need for any virtual interface.

Hey, this is just an example.

|Let me give my take on virtual interfaces...
|
|Some routing protocols use virtual interfaces because at least the
|following problem: it has been shown in practice that when a e.g. wifi
|interface gets disassociated from the AP the interface may go down, and
|in some implementations it may SIGKILL (or worse) the app using that
|socket.  And if the app is the routing protocol the net effect is very
|bad: routing protocol crashes.  This was very bad.  

I understand this condition very well. But I have very, very different
result. My routing protocol does not crash (if so, I'll have repaired it).
My routing protocol automatically provides an alternative path for me.

For other applications, the effect could harm end user experience. For
example, a terminal session would disconnect. The user may set up a new
connection via alternative paths, using other addresses. We need a solution
for this problem, agreed?

|It also meant that
|whenever I would disconnect the Ethernet cable (on some implementations,
|again), the routing protocol implementation would crash; or when my
|bluetooth interface gets down.  

Again, not in my network.

|Or similar 'mobility' event which would
|never previously appear in the fixed-router-Internet, because people
|wouldn't consciously disconnect Ethernet cables whereas phone lines
|would still get jammed (a modem line being overloaded wouldn't SIGKILL
|the app running on that kernel, because modem separated from computer by
|rs-232 and rs-232 no interface structure).

RS-232 (and many other serial line technologies) have interface state. I
designed networks with fast rerouting (sub-second) using serials.
And for sure, the routing protocol did not crash!!!

|To cope with that, put up a virtual interface and add routes between
|that virtual interface and the wifi interface.  And run the routing
|protocol on top of _that_ virtual interface instead of the wifi
|interface.  

I think you mean here a bridge interface. You suggested this before. You
still own me your test results with 802.11 (IBSS mode) interface and
Ethernet interface in a bridge.

|Since it is virtual it never gets down

Are you sure on this? What if the bridge interface have no ports in up state
in it? I know equipment where the bridge interface goes down as soon as
there is no port in up state anymore. Maybe I use the more enhanced stuff (I
can configure this behavior).

|(unless maybe a tree
|falls), the routing protocol implementation will crash less.

My routing protocol implementation will not crash as trees falls.

|It was
|thus shown that the routing protocol running on a virtual interface is
|advantageous, dealing better with mobility events - at least it could be
|deterministic!

It would take another 100 pages to explain when to use the loopback
interface and when the physical interface for the routing protocol. Please
read some books on IGP and EGP, after that iBGP and eBGP. Or ask some folks
that build BGP networks.

The issue here is, do we use the loopback interface or physical interface
for our host applications running on the MANET Router? Maybe we want to use
loopback for our terminal session, and physical for our wonderful ping tool.

|However, there exist also implementations of wifi drivers which won't
|put the interface down when the interface gets dissasociated.  Also
|there exist kernels which won't SIGKILL the app, and there exist also
|protocols implementations who'd deal with that SIGKILL more gently if it
|popped up.

Such implementations will introduce problems for our routing protocols for
fast rerouting.

And yes, I prefer not bothering end users with messages due to SIGKILL. I
have a reconnect button on my terminal emulation application, and automatic
login. I can even configure automatic relogin. However, this will not
restore my state on the other host and my work-in-progress would get lost.
Or even worse, the command ifup cannot be given in anymore. I spoke to
persons traveled a whole day because destroying their own terminal session,
to give the ifup on a console interface. I would not say loopback interfaces
solves everything, but is helpful in many, many cases.

|Also there exist implementations of routing protocols who would not deal
|at all with any particular interface structure (be that real or virtual)
|- they're independent on the kernel's interface structures being up or
|down or whatever state, but use directly the card's buffers to send or
|receive data.  I agree though these implementations are less widespread.

I can't follow what you mean here. Aren't we mix up control plane and data
plane here? I would stay far away from this, and if many of us do so, it is
indeed not widespread.

|Overall, I think a safe bet is somewhere in the middle: to not talk
|about virtual interfaces (neither loopback, nor others) but only about
|real interfaces and of specific types.  And to consider the virtual
|interfaces to be a detail of _some_ implementations.

Because you might be not compatible with what I am doing, I want to have
this included in the addressing model. Then we know the state of
compatibility.

No problem with specifying using virtual interfaces (loopback or others) is
optional. And I prefer writing down when virtual interfaces (loopback or
others) is useful and when not. For example, 802.1D specifies using a bridge
interface with a 802.11 port in IBSS mode is NOT allowed. You suggested this
scenario repeatedly and I responded over and over: it doesn't work (poor
performance) and it is against the spec.

Please come up with responses that we can agree on. We might be not far from
this.

Teco.

|
|Alex
|
|>
|> In a table format:
|>
|>  Delegated summary prefix:      2001:db8::/60
|>    15 x /64: MANET Interface:	       2001:db8:0::/64
|>              Ethernet Interface:     2001:db8:1::/64
|>                " "     " "             " "     "
|>              up to:                  2001:db8:E::/64
|>    Block for longer prefix lengths:  2001:db8:F::/64
|>      Loopback Interface #0:              2001:db8:F::0/128
|>      (others, e.g. P2P)                    " "     "
|>
|>
|> This model provides RFC4862 SLAAC service for nearby hosts, also
|useful for
|> MANET Router (or NEMO Router) bootstrapping. For getting a delegated
|prefix,
|> the a SLAAC address could be used for communication with a DHCP
|server,
|> using unicast (to be verified). Important: the /64 prefix that
|corresponds
|> with the SLAAC address-prefix MUST NOT be advertized in the MANET
|Routing
|> Protocol. Advertizing this as a host prefix is allowed, but getting an
|own
|> /60 or whatsoever summary is advised. The result here is a MANET
|Routing
|> Protocol requirement (not advertizing /64 SLAAC prefixes).
|> The MANET Router may act as DHCP Server (or relay agent) for its
|Delegated
|> Prefix(es). SLAAC is also supported.
|>
|>
|>
|> On dec 2007 I posted similar thoughts
|> (http://www.ietf.org/mail-archive/web/autoconf/current/msg00901.html).
|> Are we making progress? I think: yes!
|>
|>
|> Teco.
|>
|>
|>
|>
|>
|> |-----Oorspronkelijk bericht-----
|> |Van: Charles E. Perkins [mailto:[email-masked]]
|> |Verzonden: woensdag 4 maart 2009 0:27
|> |Aan: Teco Boot
|> |CC: [email-masked]
|> |Onderwerp: Re: [Autoconf] Autoconf addressing model
|> |
|> |
|> |Hello Teco,
|> |
|> |You raise interesting questions, but I think mostly
|> |not definitive for the questions at hand.  I don't know
|> |if I have any good answers, but here are some comments.
|> |
|> |Teco Boot wrote:
|> |> As long as I designed and maintained network infrastructures, I
|worked
|> |with
|> |> "/32 management addresses" on loopback interfaces. Still, I have
|> |annoying
|> |> experiences with routers that select the outgoing interface address
|as
|> |> default source address. Shutting down an interface could have
|> |unintended bad
|> |> impact on your terminal session. Same for link flapping due to
|other
|> |causes.
|> |>
|> |
|> |I guess this is relevant for packet forwarders with more than one
|> |network interface.  For our little wireless nodes that have a single
|> |interface, I don't imagine we'd see that kind of interface
|aggravation.
|> |
|> |> For this reason, many routers on the Internet use the loopback
|> |interface for
|> |> "management". "Management" is the host application on routers.
|There
|> |are
|> |> lots of design guidelines for this. My proposal is using the
|"Internet
|> |> lessons learned" in the MANET. Nothing wrong with this, agreed?
|> |>
|> |
|> |I know only a small bit about this.  Do you have a favorite
|> |document that I could read to learn more?
|> |
|> |>
|> |> With MobileIP, we are discussing a host (could be NEMO Router, but
|> |then it
|> |> acts as host on the visiting link). The MobileIP stack is
|interested
|> |in the
|> |> status of the visiting link, but does it propagate this to the
|> |applications?
|> |> Or use the applications some kind of virtual interface (e.g. a
|> |loopback
|> |> interface)? Or spoof ifup for interface to home link?
|> |>
|> |
|> |Whether or not applications have access to link information is
|> |something not closely related to Mobile IP.  Whether or not
|> |the care-of address is available to applications is a surprisingly
|> |complicated question, which in my opinion opens the door to
|> |many interesting questions and indicates the insufficiency of
|> |today's typical application socket interface.
|> |
|> |I've had a lot of ideas about how to fix this, but never been
|> |able to initiate a project to supply a finished proposal.
|> |
|> |
|> |Regards,
|> |Charlie P.
|>
|> _______________________________________________
|> Autoconf mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/autoconf
|>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Mar 2009 10:14:34 +0100

I wanted to clarify better myself because I think I'm misunderstood,
sorry for insisting on what may appear as circles but I don't want to be
understood so.

Stan Ratliff (sratliff) a écrit :
> *By definition*, what you describe is not a MANET. As you state, 
> that's just a WiFi access point.

Ok, I said AP because in a hurry.  I also meant AP-free wifi adhoc mode
gatherings of ad-hoc interfaces.  The coverage is also about 25meter.
This is dictated by the max power levels (a number of milliwatts) which
says how strong can 2.5GHz emit in unlicensed spectrum.

If all such ad-hoc interfaces of that IPv6 subnet stay within 25meter
range then they're all fully exposed (no hidden terminals).

And I also mean that larger networks could be made out of building
blocks of 25m (because of powerlevel-limited because
unlicensed-spectrum), by using Routers.  And still keeping the IPv6
subnet to be as small at the safe area in which there are all exposed
terminals, no hidden terminals.

I hope I'm clearer.

> That's already solved -- 802.11 clients can roam from access point to
>  access point.

Well yes and no, depends how it's deployed.  If the APs are bridging
into a backbone then yes, terminals keep their addresses.  But if the
APs route then it's not solved.  (Proxy) Mobile IP may be a solution for
it, but it has its inconvenients in path lengths (RO) and tunnels.

> But again, this should not be an 802.11-centric discussion.

I agree to have it on more than 802.11.

I've been told recently it's not good for link layer characteristics to
  control the link-layers to IP addressing.  Yes, put that way I agree
with it - I don't want link-layers to control IP, rather vice-versa.

But it's also  true that an IPv6 link-local address on Ethernet depends
directly on the MAC addres (a link-layer ID), that an  IPv6 subnet on
802.16 is a prefix-per-mobile model, and that IPv6 auto-configuration on
802.15.4 may use a form of address assigned in RA.

That's what I wanted to say about AUTOCONF addressing architecture and
specific link-layers.

I hope I'm clearer.

Alex

>> No, not constantly re-computed.  But have a fixed view at a point 
>> in time.  Saying everything varies isn't helpful either.
>> 
> 
> It may not be helpful, but it's reality. You can't rely on a fixed 
> view of a dynamic network; again, by definition, there's movement in
>  a MANET. Links come and go, and link quality varies from moment to 
> moment.
> 
> 
>> No I didn't suppose GPS is available on each device, it wouldn't 
>> work well under foliage.  Just a rough evaluation of a specific 
>> link-layer radio range, correspondign to widely used networks.
>> 
>> YEs, certainly.  All cabled link-layers have specific limitations 
>> on their lengths: 2m USB, 50m Ethernet Category6 (IIRC) and so on.
>> 
>>> I could understand (but wouldn't really like) the notion of 
>>> limiting the discussion
>> to links
> I'm not advocating we "ignore" 802.11, or any other L2 technology, 
> for that matter. I'm advocating that we remain Layer 2 agnostic. As 
> Teco mentioned in another email, there are people in this WG that 
> don't deploy MANET networks based on 802.11, or 802.16, or 802.15.4.
> 
>> link-layer of your choice.  And be speecifically addressing these 
>> two link layers.  And maybe three.  No more than three.
>> 
> I don't understand why the Layer 3 addressing scheme needs to be 
> predicated on a specific Layer 2 technology, or set of technologies.
>  The Layer 3 addressing scheme should be totally independent of Layer
>  2 -- isn't that what layering is all about?
> 
>> problem could be addressed at its layer: don't move the command 
>> center under trees risking falling); or maybe have two command 
>> centers, but specificllay two, not an arbitrary large unknown 
>> number.
>> 
> 
> That essentially boils down to "if it hurts, don't do it", and it 
> doesn't work for my customers. Their environments are dynamic, and 
> they need the ability to respond to ever-changing realities on the 
> ground.
> 
> At this point, I feel that we're in a discussion that is becoming 
> more and more circular, and therefore, dysfunctional. And that, IMO,
>  has been the unfortunate reality of this WG since its inception.
> 
> Regards, Stan
> 
> 
>> Alex
>> 
>

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 5 Mar 2009 10:37:31 +0100

Inline.

|-----Oorspronkelijk bericht-----
|Van: [email-masked] [mailto:[email-masked]] Namens
|Alexandru Petrescu
|Verzonden: donderdag 5 maart 2009 10:15
|Aan: Stan Ratliff (sratliff)
|CC: [email-masked]
|Onderwerp: Re: [Autoconf] Autoconf addressing model
|
|I wanted to clarify better myself because I think I'm misunderstood,
|sorry for insisting on what may appear as circles but I don't want to be
|understood so.
|
|Stan Ratliff (sratliff) a écrit :
|>> Stan Ratliff (sratliff) a écrit :
|>>> First off, you *can't* arbitrarily limit subnets to 25m. 25m from
|>>>  what? The center?
|>> Yes, an area of 25meters with a wifi access point in the center.
|>
|> *By definition*, what you describe is not a MANET. As you state,
|> that's just a WiFi access point.
|
|Ok, I said AP because in a hurry.  I also meant AP-free wifi adhoc mode
|gatherings of ad-hoc interfaces.  The coverage is also about 25meter.
|This is dictated by the max power levels (a number of milliwatts) which
|says how strong can 2.5GHz emit in unlicensed spectrum.
|
|If all such ad-hoc interfaces of that IPv6 subnet stay within 25meter
|range then they're all fully exposed (no hidden terminals).

Not true. Maybe in a lab environment, there is no condition where it fails.
In other circumstances, some iron would be enough for limited range (few
meters). Think of (closed) workplace shelters (EMC or ABC protected).
There are also stories on wlan and micro-wave ovens. 
This is mentioned over and over.

|And I also mean that larger networks could be made out of building
|blocks of 25m (because of powerlevel-limited because
|unlicensed-spectrum), by using Routers.  And still keeping the IPv6
|subnet to be as small at the safe area in which there are all exposed
|terminals, no hidden terminals.

No. There is a limit on spectrum and not all segments can use their own.
This introduces hidden terminal in your scenario. Moreover, you might be
familiar with planning WiFi infrastructures. Do you think this is ad hoc?

|I hope I'm clearer.

I don't think so. You came up with scenario's that are against the 802.11
standards and have serious problems when used in ad hoc fashion. Just my
opinion.

|> That's already solved -- 802.11 clients can roam from access point to
|>  access point.
|
|Well yes and no, depends how it's deployed.  If the APs are bridging
|into a backbone then yes, terminals keep their addresses.  But if the
|APs route then it's not solved.  (Proxy) Mobile IP may be a solution for
|it, but it has its inconvenients in path lengths (RO) and tunnels.

No problems if the APs route and the stations run a MANET protocol. I am
aware of other solutions also, where stations stay hosts (e.g. inject
ND/ARP/other info in routing).

|> But again, this should not be an 802.11-centric discussion.
|
|I agree to have it on more than 802.11.
|
|I've been told recently it's not good for link layer characteristics to
|  control the link-layers to IP addressing.  Yes, put that way I agree
|with it - I don't want link-layers to control IP, rather vice-versa.
|
|But it's also  true that an IPv6 link-local address on Ethernet depends
|directly on the MAC addres (a link-layer ID),

Not by definition and not directly. Nodes are free to use any other
Interface ID.

Teco.

| that an  IPv6 subnet on
|802.16 is a prefix-per-mobile model, and that IPv6 auto-configuration on
|802.15.4 may use a form of address assigned in RA.
|
|That's what I wanted to say about AUTOCONF addressing architecture and
|specific link-layers.
|
|I hope I'm clearer.
|
|Alex
|
|>>> And, how do you designate the center? Do you constantly
|>> re-calculate
|>>> the center based on movement?
|>> No, not constantly re-computed.  But have a fixed view at a point
|>> in time.  Saying everything varies isn't helpful either.
|>>
|>
|> It may not be helpful, but it's reality. You can't rely on a fixed
|> view of a dynamic network; again, by definition, there's movement in
|>  a MANET. Links come and go, and link quality varies from moment to
|> moment.
|>
|>
|>>> Also, from a radio perspective, how do you tell how far
|>> apart you are
|>>> in the first place? Do you suppose that all radios have
|>> GPS? That's a
|>>> non-starter, because GPS signals aren't always available.
|>> No I didn't suppose GPS is available on each device, it wouldn't
|>> work well under foliage.  Just a rough evaluation of a specific
|>> link-layer radio range, correspondign to widely used networks.
|>>
|>>> And what about the wired MANET case brought up by Christopher
|>>> Dearlove? Should we limit the cable runs?
|>> YEs, certainly.  All cabled link-layers have specific limitations
|>> on their lengths: 2m USB, 50m Ethernet Category6 (IIRC) and so on.
|>>
|>>> I could understand (but wouldn't really like) the notion of
|>>> limiting the discussion
|>> to links
|>>> that are transitive; but placing some arbitrary distance
|>> limit that's
|>>> based on 802.11 just doesn't cut it for me.
|>> 802.11 is being used widely, no reason to ignore.
|>
|> I'm not advocating we "ignore" 802.11, or any other L2 technology,
|> for that matter. I'm advocating that we remain Layer 2 agnostic. As
|> Teco mentioned in another email, there are people in this WG that
|> don't deploy MANET networks based on 802.11, or 802.16, or 802.15.4.
|>
|>> I'd happily accept to add another specific limitation, from the
|>> link-layer of your choice.  And be speecifically addressing these
|>> two link layers.  And maybe three.  No more than three.
|>>
|>> I find addressing them all to be difficult for me.
|>
|> I don't understand why the Layer 3 addressing scheme needs to be
|> predicated on a specific Layer 2 technology, or set of technologies.
|>  The Layer 3 addressing scheme should be totally independent of Layer
|>  2 -- isn't that what layering is all about?
|>
|>> (about single point of failure being destroyed by a falling tree:
|>> problem could be addressed at its layer: don't move the command
|>> center under trees risking falling); or maybe have two command
|>> centers, but specificllay two, not an arbitrary large unknown
|>> number.
|>>
|>
|> That essentially boils down to "if it hurts, don't do it", and it
|> doesn't work for my customers. Their environments are dynamic, and
|> they need the ability to respond to ever-changing realities on the
|> ground.
|>
|> At this point, I feel that we're in a discussion that is becoming
|> more and more circular, and therefore, dysfunctional. And that, IMO,
|>  has been the unfortunate reality of this WG since its inception.
|>
|> Regards, Stan
|>
|>
|>> Alex
|>>
|>
|
|_______________________________________________
|Autoconf mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/autoconf

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Mar 2009 11:31:49 +0100

Teco Boot a écrit :
[...]
> meters). Think of (closed) workplace shelters (EMC or ABC protected).

Ok I agree there could be such a situation.  What if we came up with an 
object name which doesn't have hidden terminal problems when EMC cages 
are used, and on which an IPv6 subnet could be deployed safely.

> There are also stories on wlan and micro-wave ovens.

YEs, rather exaggerated.  Maybe true some years ago but less true nowadays.

> This is mentioned over and over.

Yes, I agree, but we should mention also the wifi deployments which 
work, are deterministic.  These also exist.

> This introduces hidden terminal in your scenario.

Well if each subnet is 25meter wide and they don't mix with each other 
then there are no interferences on the spectrum, because power levels 
are diminishing with distance.

> Moreover, you might be

It's as much ad-hoc as the name ad-hoc is used in the 802.11 specs and 
iwconfig implementations.

> standards and have serious problems when used in ad hoc fashion. Just my

Well since you seem so confident about how wrong I am then please come 
up with descriptions of wireless systems which work, and which don't 
risk hidden-terminal problems, no electro-magnetic cages, no obstacles, 
no spectrum interference, etc.

> ND/ARP/other info in routing).

IPv6 ND over 802.15.4 draft seems to specify that too.

> Not by definition and not directly. Nodes are free to use any other

Well ok, but I haven't seen much a fe80::1 address on an Ethernet 
interface.  You may, and then I'll wonder why.

Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 5 Mar 2009 12:02:40 -0000

Stan Ratliff
> At this point, I feel that we're in a discussion that
> is becoming more and more circular, and therefore,
> dysfunctional.

This discussion has certainly derailed. My last posting
agreeing with everything Stan said in an earlier posting
than the one I'm quoting unfortunately got lost (at my end).

I think there's a need to cut a lot of the chaff away.
While there are details that are still open for discussion
(otherwise this would have all happened long ago) I think
it should be possible to agree on some ground rules,
especially with regard to L2, that have rough consensus,
and unless multiple people (not just one person) come
back wanting to discuss the issue, we just don't.

Obviously I can't specify a list of such details, as I'm
just one contributor. But I think that such a list would
include

- L2 agnostic, within the limitations of the following
  points. Thus although systems such as IEEE 802.11 are
  important examples, they have no privileged place.

- Wireless systems are the reason for MANETs. But MANETs
  can also use wired links, and some wireless links that
  are much better behaved, while still allowing for the
  more difficult cases also to be covered.

- The differing characteristics of those wireless links compared
  to e.g. an Ethernet have to be allowed for. The characteristics
  that MANET routing protocols are designed to handle need to be
  part of the design. This includes non-transitive links and
  non-symmetric local broadcast transmissions at the least.

Those aren't carefully thought out wordings, and they certainly
aren't complete (the more we can add and retain rough consensus
the better). But they would mean, if we can come to such a
consensus, that we just don't get trapped down cul-de-sacs like
only 802.11, listing specific L2 technologies, and 25m ranges,
and spend our effort usefully elsewhere.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 5 Mar 2009 12:10:28 -0000

> hasn't been planned, spontaneous, etc.

That is the dictionary definition of ad hoc. But "ad hoc network"
has become a term of art, whose fundamentals are about decentralised,
cooperative, multi-hop routing. (I'm not sure if RFC 2501 attempts
a definition, I haven't checked it recently.) "ad hoc" got attached
to such networks because they often were/are ad hoc in the dictionary
sense. But often ad hoc networks are not completely unplanned, but
still retain that label.

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 5 Mar 2009 13:36:06 +0100

Inline.

|-----Oorspronkelijk bericht-----
|Van: Alexandru Petrescu [mailto:[email-masked]]
|Verzonden: donderdag 5 maart 2009 11:32
|Aan: Teco Boot
|CC: 'Alexandru Petrescu'; 'Stan Ratliff (sratliff)'; [email-masked]
|Onderwerp: Re: [Autoconf] Autoconf addressing model
|
|Teco Boot a écrit :
|[...]
|> |If all such ad-hoc interfaces of that IPv6 subnet stay within 25meter
|> |range then they're all fully exposed (no hidden terminals).
|>
|> Not true. Maybe in a lab environment, there is no condition where it
|fails.
|> In other circumstances, some iron would be enough for limited range
|(few
|> meters). Think of (closed) workplace shelters (EMC or ABC protected).
|
|Ok I agree there could be such a situation.  What if we came up with an
|object name which doesn't have hidden terminal problems when EMC cages
|are used, and on which an IPv6 subnet could be deployed safely.

Wires?
TDMA? (or other media access technologies)

But this is of no help. The MANET link characters occur in real life. Why do
you suggest denying this?

By the way, hidden terminal problem has nothing to do with totally
unreachability, as in the EMC cage. The opposite is true, EMC cages (or
turning off the radio) solves the hidden terminal problem. Connectivity gets
hurt. Every improvement may have some disadvantages.

|> There are also stories on wlan and micro-wave ovens.
|
|YEs, rather exaggerated.  Maybe true some years ago but less true
|nowadays.
|
|> This is mentioned over and over.
|
|Yes, I agree, but we should mention also the wifi deployments which
|work, are deterministic.  These also exist.

No one had any doubt about this, I think. Why mentioning an endless list on
things that work? Let's focus on what urgently needs improvements.

|> |And I also mean that larger networks could be made out of building
|> |blocks of 25m (because of powerlevel-limited because
|> |unlicensed-spectrum), by using Routers.  And still keeping the IPv6
|> |subnet to be as small at the safe area in which there are all exposed
|> |terminals, no hidden terminals.
|>
|> No. There is a limit on spectrum and not all segments can use their
|own.
|> This introduces hidden terminal in your scenario.
|
|Well if each subnet is 25meter wide and they don't mix with each other
|then there are no interferences on the spectrum, because power levels
|are diminishing with distance.

Again and again and again. This may be true in a well planned network. It
fails when nodes move. So it does NOT apply to a MANET.

|
|> Moreover, you might be
|> familiar with planning WiFi infrastructures. Do you think this is ad
|hoc?
|
|It's as much ad-hoc as the name ad-hoc is used in the 802.11 specs and
|iwconfig implementations.

I think you absolutely don't know where you are talking about. Sorry to say
so.

|> |I hope I'm clearer.
|>
|> I don't think so. You came up with scenario's that are against the
|802.11
|> standards and have serious problems when used in ad hoc fashion. Just
|my
|> opinion.
|
|Well since you seem so confident about how wrong I am then please come
|up with descriptions of wireless systems which work, and which don't
|risk hidden-terminal problems, no electro-magnetic cages, no obstacles,
|no spectrum interference, etc.

You missed the point MANET works even in the circumstances you described.
MANET Routing provides the best available paths to users (tries to ...). Of
course: no path available, no communication.

|> |> That's already solved -- 802.11 clients can roam from access point
|to
|> |>  access point.
|> |
|> |Well yes and no, depends how it's deployed.  If the APs are bridging
|> |into a backbone then yes, terminals keep their addresses.  But if the
|> |APs route then it's not solved.  (Proxy) Mobile IP may be a solution
|for
|> |it, but it has its inconvenients in path lengths (RO) and tunnels.
|>
|> No problems if the APs route and the stations run a MANET protocol. I
|am
|> aware of other solutions also, where stations stay hosts (e.g. inject
|> ND/ARP/other info in routing).
|
|IPv6 ND over 802.15.4 draft seems to specify that too.
|
|> |> But again, this should not be an 802.11-centric discussion.
|> |
|> |I agree to have it on more than 802.11.
|> |
|> |I've been told recently it's not good for link layer characteristics
|to
|> |  control the link-layers to IP addressing.  Yes, put that way I
|agree
|> |with it - I don't want link-layers to control IP, rather vice-versa.
|> |
|> |But it's also  true that an IPv6 link-local address on Ethernet
|depends
|> |directly on the MAC addres (a link-layer ID),
|>
|> Not by definition and not directly. Nodes are free to use any other
|> Interface ID.
|
|Well ok, but I haven't seen much a fe80::1 address on an Ethernet
|interface.  You may, and then I'll wonder why.

Why can't I configure it? Of course I can.

debian-fs1:~# ip -6 addr                        
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 2001:db8:1:0:20c:29ff:fee3:bdf5/64 scope global dynamic 
       valid_lft 2592000sec preferred_lft 604800sec
    inet6 fe80::1/64 scope link 
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fee3:bdf5/64 scope link 
       valid_lft forever preferred_lft forever

nbs3725#sh ipv int fa0/0.22
FastEthernet0/0.22 is up, line protocol is up
  IPv6 is enabled, link-local address is FE80::2

No problem either with configuring this on each and every interface of a
node. As long as the LL is unique on the link.
So the following topology is valid:

+----------+                        +----------+
|          |fe80::1/64              |          |
|          +========================+          |
| router 1 |              fe80::2/64| router 2 |
|          |fe80::1/64              |          |
|          +========================+          |
|          |              fe80::2/64|          |
+----------+                        +----------+

Agreed on this?
Maybe the OLSR / NHDP design team needs to verify their design on this
topology. Due to lack of a RouterID, topology databases may lack  sufficient
information to distinguish the two links. When fixed, let's check also the
following:

+----------+                        +----------+
|          |fe80::1/64              |          |
|          +========================+          |
| router x |              fe80::2/64| router y |
|          |fe80::2/64              |          |
|          +========================+          |
|          |              fe80::1/64|          |
+----------+                        +----------+

I tested the loopback interface advantage (router 11 & 12):

+------------+                         +------------+
|            |fe80::11/64              |            |
| Router-11  +=========================+ Router-12  |
|            |              fe80::12/64|            |
| loopback0  |fe80::11/64              | loopback0  |
| FD::11/128 +=========================+ FD::12/128 |
|            |              fe80::12/64|            |
+------------+                         +------------+

I turned on OSPFv3 and set up a terminal connection from Router-11 to
Router-12, using the loopback interfaces. Then I shut down and brought up
again the interfaces (ifdown/ifup, if you like), remotely, one at a time. I
experienced no problems with my terminal session.

I repeated the test with the link local addresses. Here also, I experienced
no problems. This is because there are two links with exactly the same
address pairs (an advantage to use same LL addresses on all interfaces).
With a multi-hop path, this will not work.

Teco.

|Alex

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 5 Mar 2009 13:09:41 -0000

> Agreed on this?

I'm withholding any judgement on that.

> topology.

That is a problem for OLSR / NHDP which assumes (one or more)
distinct IP addresses on separate interfaces.

> Due to lack of a RouterID, topology databases may lack  sufficient

That is not a problem.

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 5 Mar 2009 14:43:14 +0100

|> As long as the LL is unique on the link.
|> So the following topology is valid:
|
|> +----------+                        +----------+
|> |          |fe80::1/64              |          |
|> |          +========================+          |
|> | router 1 |              fe80::2/64| router 2 |
|> |          |fe80::1/64              |          |
|> |          +========================+          |
|> |          |              fe80::2/64|          |
|> +----------+                        +----------+
|
|> Agreed on this?
|
|I'm withholding any judgement on that.
|
|> Maybe the OLSR / NHDP design team needs to verify their design on this
|> topology.
|
|That is a problem for OLSR / NHDP which assumes (one or more)
|distinct IP addresses on separate interfaces.

This scenario is not uncommon, where VLANs are used.
Questions are:
Do we want OLSR / NHDP to support VLANs? I think so.
Do we want to introduce a new requirement for MAC addresses for VLANs, being
unique? I don't think so.
Or deprecate EUI-64 used as InterfaceID, e.g. use randomized addresses?

This last one is a bit black/white. NHDP could check uniqueness of local
interface addresses, and generate and configure other addresses if needed.
Not sure on going that way. Use NHDP_InterfaceIDs that are not configured
addresses ? (like OSPF)

I don't prefer a requirement using globally unique addresses for all transit
links being used by OLSR / NHDP.

Teco.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Mar 2009 14:49:18 +0100

Teco Boot a écrit :
[...]
> course: no path available, no communication.

I agree with the last part: the risk is that even the best designed 
MANET protocol will not work when trees fall, cages shield and obstacles 
get in the way.   These are goals which can't be addressed.

[...]
> node. As long as the LL is unique on the link.

Yes, I agree it can.  I don't understand why would one do it.

When over Ethernet there's the MAC address deriving into IID, helping 
ensuring uniqueness.

When over point-to-point links PPP with IPv6 could be used negotiating 
the link layer ID, again ensuring uniqueness.

But I agree an administrator may want to plan all the link-local 
addresses and assign them manually, for some links which don't have MAC 
addresses, are not 802.16 and are not used.

> So the following topology is valid:

Agreed.  But why /64?  An address is /128, and the link-local address' 
prefix is /10.

> information to distinguish the two links.

I agree this should be checked for all routing protocols, to find out 
whether loops form.

> When fixed, let's check also the
> following:
> 
> 
>  Router-12, using the loopback interfaces. Then I shut down and
> brought up again the interfaces (ifdown/ifup, if you like), remotely,
> one at a time. I experienced no problems with my terminal session.

I agree.

> I repeated the test with the link local addresses. Here also, I
> experienced no problems. This is because there are two links with
> exactly the same address pairs (an advantage to use same LL addresses
> on all interfaces). 

Demonstrating the advantage of loopback0 vs eth0 would have implied that
you start OSPFv3 on eth0 instead of loopback0 and that it would have
crashed.

But even then, I'm sure there may exist OSPFv3 implementation which
would not crash when running over eth0 and ifconfig down eth0.

In this sense, if the loopback0 interface is a solution to crashing
OSPFv3-over-eth0, then it is an implementation solution. Some
implementations do, others don't.

 > With a multi-hop path, this will not work.

In my sense, you already pictured a multi-hop network in the first 
topology, so it should work.

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 5 Mar 2009 15:04:41 +0100

Hi Alex,

|Agreed.  But why /64?  An address is /128, and the link-local address'
|prefix is /10.

I used address-prefix format (RFC4291).

And RFC2464:

5.  Link-Local Addresses
   The IPv6 link-local address [AARCH] for an Ethernet interface is
   formed by appending the Interface Identifier, as defined above, to
   the prefix FE80::/64.

The 54 bits following 1111111011 are zero. There is little difference
between FE80::/10 and FE80::/64. On Ethernet, it is the latter.

|> I repeated the test with the link local addresses. Here also, I
|> experienced no problems. This is because there are two links with
|> exactly the same address pairs (an advantage to use same LL addresses
|> on all interfaces).
|
|Demonstrating the advantage of loopback0 vs eth0 would have implied that
|you start OSPFv3 on eth0 instead of loopback0 and that it would have
|crashed.

My routing protocols do not crash. I told you before.

|But even then, I'm sure there may exist OSPFv3 implementation which
|would not crash when running over eth0 and ifconfig down eth0.
|
|In this sense, if the loopback0 interface is a solution to crashing
|OSPFv3-over-eth0, then it is an implementation solution. Some
|implementations do, others don't.

You totally missed the point.

Teco.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Mar 2009 15:15:47 +0100

> |> So the following topology is valid:

Ah!

> between FE80::/10 and FE80::/64. On Ethernet, it is the latter.

Which one should we picture on the AUTOCONF practical addressing scheme? 
  The /10 or the /64?

In a picture like that I'd definitely put an address and the prefix like 
this, in the simplest case:

---\
     \ fe80::1/128   (the address)
      ---------
     / 2001:db8::/64 (the prefix of the subnet on which this interface is
---/                 attached)

> My routing protocols do not crash. I told you before.

Sorry, I don't remember. So then they could work without loopback0 
interface, only over the Ethernet interface, right? (they wouldn't crash 
when the interface goes down and then up).

> You totally missed the point.

Your point seemed to motivate the use of loopback0 interface.  And so, 
because presumably the physical interfaces are not enough.  Am I 
catching your point?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Mar 2009 15:19:32 +0100

>     / 2001:db8::/64 (the prefix of the subnet on which this interface is

For clarification, I meant this:

  /------\
/        \ fe80::1/128   (the address)
| Router |--------------
\        / 2001:db8::/64 (the prefix of the subnet on which
  \------/                 this interface is attached)

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 5 Mar 2009 15:51:26 +0100

Hi Alex,

|> The 54 bits following 1111111011 are zero. There is little difference
|> between FE80::/10 and FE80::/64. On Ethernet, it is the latter.
|
|Which one should we picture on the AUTOCONF practical addressing scheme?
|  The /10 or the /64?

It depends.
With Ethernet (and related 802 addressing), it is /64.
For other interfaces, there is more freedom. But there is RFC4291:
   For all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format.

|
|In a picture like that I'd definitely put an address and the prefix like
|this, in the simplest case:
|
|---\
|     \ fe80::1/128   (the address)
|      ---------
|     / 2001:db8::/64 (the prefix of the subnet on which this interface
|is
|---/                 attached)
|

Why?
Please read RFC4291 section 2.3 (Address Prefixes)

This "fe80::1/128" is an invalid address prefix. 
Address fe80::1 is OK, Address prefixes fe80::1/64 and 2001:db8::1/64 are
also OK.

|> |> I repeated the test with the link local addresses. Here also, I
|> |> experienced no problems. This is because there are two links with
|> |> exactly the same address pairs (an advantage to use same LL
|addresses
|> |> on all interfaces).
|> |
|> |Demonstrating the advantage of loopback0 vs eth0 would have implied
|that
|> |you start OSPFv3 on eth0 instead of loopback0 and that it would have
|> |crashed.
|>
|> My routing protocols do not crash. I told you before.
|
|Sorry, I don't remember. So then they could work without loopback0
|interface, only over the Ethernet interface, right? (they wouldn't crash
|when the interface goes down and then up).
|
|> |But even then, I'm sure there may exist OSPFv3 implementation which
|> |would not crash when running over eth0 and ifconfig down eth0.
|> |
|> |In this sense, if the loopback0 interface is a solution to crashing
|> |OSPFv3-over-eth0, then it is an implementation solution. Some
|> |implementations do, others don't.
|>
|> You totally missed the point.
|
|Your point seemed to motivate the use of loopback0 interface.  And so,
|because presumably the physical interfaces are not enough.  Am I
|catching your point?

You are free using loopback interfaces or not.
I explain why I have an advantage. This is not crashing protocols, it is
eliminating unneeded terminated sessions.

I do not accept a comment that I have no advantage. I have also different
scenarios, some have benefits from a loopback interface, some have not. I am
waiting on an answer from you, on your standpoint to be interoperable with
me or not. I hope your routing protocol doesn't crash when receiving a host
prefix. If so, I do not want to be compatible with you.

Teco.

|Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Mar 2009 16:09:48 +0100

I agree.

> |     \ fe80::1/128   (the address)

Ah ok!  I'd normally picture what are the parameters I need to set up 
the network you illustrated on linux.  So would this be ok:?

  /------\
/        \ fe80::1       (the address)
| Router |--------------
\        / 2001:db8::/64 (the prefix of the subnet on which
  \------/                 this interface is attached)

For me, whereas the 2001:db8::/64 information is enough to add in 
radvd.conf, or to add with ifconfig,  the problem is that I can't just 
say "ifconfig eth0 add fe80::1" and I must say "ifconfig eth0 add 
fe80::1/10", otherwise error.

> prefix. If so, I do not want to be compatible with you.

Well my answer is that as of now I don't use any routing protocol, and 
only put manual prefixes in the routing tables.

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 5 Mar 2009 16:34:53 +0100

Hi Alex,

|> This "fe80::1/128" is an invalid address prefix.
|> Address fe80::1 is OK, Address prefixes fe80::1/64 and 2001:db8::1/64
|are
|> also OK.
|
|Ah ok!  I'd normally picture what are the parameters I need to set up
|the network you illustrated on linux.  So would this be ok:?
|
|  /------\
|/        \ fe80::1       (the address)
|| Router |--------------
|\        / 2001:db8::/64 (the prefix of the subnet on which
|  \------/                 this interface is attached)
|

Now you don't depict the address in subnet 2001:db8::/64. 

|For me, whereas the 2001:db8::/64 information is enough to add in
|radvd.conf, or to add with ifconfig,  the problem is that I can't just
|say "ifconfig eth0 add fe80::1" and I must say "ifconfig eth0 add
|fe80::1/10", otherwise error.

Try ifconfig eth0 inet6 add fe80::1/64
Or  ip -6 addr add fe80::1/64 dev eth0

I think you tried to add an IPv4 address, with failing DNS lookup.

|> You are free using loopback interfaces or not.
|> I explain why I have an advantage. This is not crashing protocols, it
|is
|> eliminating unneeded terminated sessions.
|>
|> I do not accept a comment that I have no advantage. I have also
|different
|> scenarios, some have benefits from a loopback interface, some have
|not. I am
|> waiting on an answer from you, on your standpoint to be interoperable
|with
|> me or not. I hope your routing protocol doesn't crash when receiving a
|host
|> prefix. If so, I do not want to be compatible with you.
|
|Well my answer is that as of now I don't use any routing protocol, and
|only put manual prefixes in the routing tables.

OK for me.
I hope you can live with different settings, preferred by others.

Teco.

|Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Mar 2009 16:41:43 +0100

> |the network you illustrated on linux.  So would this be ok:?

Right, I didn't, and I should have had.  How would you depict a Router 
with one interface, a global subnet prefix, an address within that 
prefix, and a link-local address?  Without indulging any confusion.

If you don't want then I can depict it.

> I think you tried to add an IPv4 address, with failing DNS lookup.

No, it wasn't DNS lookup error, but I avoid saying ifconfig fe80::1/64 
because the prefix fe80::/64 is not an on-link prefix (even though 
fe80::1 is an address on that link).  If I write ifconfig 2001:db8::1/64 
then the 2001:db8::/64 becomes an on-link prefix.

> I hope you can live with different settings, preferred by others.

Well yes but let's first find the most common common settings.

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 5 Mar 2009 17:37:31 +0100

|> |  /------\
|> |/        \ fe80::1       (the address)
|> || Router |--------------
|> |\        / 2001:db8::/64 (the prefix of the subnet on which
|> |  \------/                 this interface is attached)
|> |
|>
|> Now you don't depict the address in subnet 2001:db8::/64.
|
|Right, I didn't, and I should have had.  How would you depict a Router
|with one interface, a global subnet prefix, an address within that
|prefix, and a link-local address?  Without indulging any confusion.

OK, this is a basic setup.
Just depict what you have:
+--------+
|        | fe80::1/64    (the LL address-prefix)
| Router +--------------
|        | 2001:db8::1/64 (the address prefix configured on
+--------+                 this interface)

Maybe use ll::1 as short presentation for fe80::1/64
And p::1/64 for the address prefix, and define the prefix p:: somewhere in
the diagram.

|If you don't want then I can depict it.
|
|> |For me, whereas the 2001:db8::/64 information is enough to add in
|> |radvd.conf, or to add with ifconfig,  the problem is that I can't
|just
|> |say "ifconfig eth0 add fe80::1" and I must say "ifconfig eth0 add
|> |fe80::1/10", otherwise error.
|>
|> Try ifconfig eth0 inet6 add fe80::1/64
|> Or  ip -6 addr add fe80::1/64 dev eth0
|>
|> I think you tried to add an IPv4 address, with failing DNS lookup.
|
|No, it wasn't DNS lookup error, but I avoid saying ifconfig fe80::1/64
|because the prefix fe80::/64 is not an on-link prefix (even though
|fe80::1 is an address on that link).  If I write ifconfig 2001:db8::1/64
|then the 2001:db8::/64 becomes an on-link prefix.

I would say it is mandatory for interfaces to have a link-local address (RFC
4291). And I think they are on-link by definition.
Or are you interested in a less common or a rare setup?

Teco.

---

From: "Joe Macker" <[email-masked]>
Date: Thu, 5 Mar 2009 11:44:58 -0500

IMHO, many successful manet networks are often partially planned.

Chris RFC 2501 attempts to tip its hat in this direction

--------
  The technology of Mobile Ad hoc Networking is somewhat synonymous
   with Mobile Packet Radio Networking (a term coined via during early
   military research in the 70's and 80's), Mobile Mesh Networking (a
   term that appeared in an article in The Economist regarding the
   structure of future military networks) and Mobile, Multihop, Wireless
   Networking (perhaps the most accurate term, although a bit
   cumbersome).
---------
> Sent: Thursday, March 05, 2009 7:10 AM
> To: Alexandru Petrescu; Teco Boot
> Cc: [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Mar 2009 17:48:47 +0100

Teco Boot a écrit :
[...]
> Just depict what you have:

I agree with this starting point.

I'm wondering what others in the WG think about this starting point in 
depicting a practical addressing architecture for AUTOCONF.  I would 
really appreciate to have some oppinions about this.

> And p::1/64 for the address prefix, and define the prefix p:: somewhere in

No, not for the moment.

> Or are you interested in a less common or a rare setup?

Right, I agree with you.  Have a link-local address on every physical 
interface.  I'm not yet interested in less common setup.

Alex

---

From: "Joe Macker" <[email-masked]>
Date: Thu, 5 Mar 2009 11:55:34 -0500

Ditto what Stan says... for what its worth.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Stan Ratliff (sratliff)
> Sent: Wednesday, March 04, 2009 4:35 PM
> To: Alexandru Petrescu
> Cc: [email-masked]
> *By definition*, what you describe is not a MANET. As you state, that's just a WiFi access point. That's
> already solved -- 802.11 clients can roam from access point to access point. But again, this should not be
> an 802.11-centric discussion.
> 
> >
> It may not be helpful, but it's reality. You can't rely on a fixed view of a dynamic network; again, by
> definition, there's movement in a MANET. Links come and go, and link quality varies from moment to moment.
> 
> 
> I'm not advocating we "ignore" 802.11, or any other L2 technology, for that matter. I'm advocating that we
> remain Layer 2 agnostic. As Teco mentioned in another email, there are people in this WG that don't deploy
> MANET networks based on 802.11, or 802.16, or 802.15.4.
> 
> >
> I don't understand why the Layer 3 addressing scheme needs to be predicated on a specific Layer 2
> technology, or set of technologies. The Layer 3 addressing scheme should be totally independent of Layer 2 -
> - isn't that what layering is all about?
> 
> >
> That essentially boils down to "if it hurts, don't do it", and it doesn't work for my customers. Their
> environments are dynamic, and they need the ability to respond to ever-changing realities on the ground.
> 
> At this point, I feel that we're in a discussion that is becoming more and more circular, and therefore,
> dysfunctional. And that, IMO, has been the unfortunate reality of this WG since its inception.
> 
> Regards,
> Stan
> 
> 
> > Alex
> >

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 5 Mar 2009 18:14:07 +0100

OK, we can start with a single interface setup:
Agreed on the starting point with three nodes, and non-transitivity solved
by MANET Routing?

                           <-------------------------v-------->
<------v-------------------------->                  |
   <---|----------------------v----------------------|--->
       |                      |                      |
       |2001:db8:1::1/64      |2001:db8:2::2/64      |2001:db8:3::3/64
       |fe80::1/64            |fe80::2/64            |fe80::3/64
   +---+---+              +---+---+              +---+---+
   |Router1|              |Router2|              |Router3|
   +-------+              +-------+              +-------+

Routing table Router1:
Destination       Next-hop    Hops
===============   ========    ====
2001:db8:2::/64   fe80::2     1
2001:db8:3::/64   fe80::2     2

Routing table Router2:
Destination       Next-hop    Hops
===============   ========    ====
2001:db8:1::/64   fe80::1     1
2001:db8:3::/64   fe80::3     1

Routing table Router3:
Destination       Next-hop    Hops
===============   ========    ====
2001:db8:1::/64   fe80::2     2
2001:db8:2::/64   fe80::2     1

I see a problem with this, who has assigned the globally unique prefixes?
Manually configured? Is it intended to connect to the Internet? Is the
Access Router known on forehand?
Maybe it is better to start with ULA as the most basic setup.

Teco.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 5 Mar 2009 17:19:04 -0000

> I see a problem with this, who has assigned the globally unique
prefixes?

Isn't that (part of) the problem this group is to address?
At this point we are specifying a requirement that (assuming
that model, which I'm not commenting on) such prefixes are
to be assigned. How it happens (as long as it's possible, and
manual configuration, though not the required solution, is
presumably an existence proof for that) is not the issue
right now.

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 5 Mar 2009 18:29:59 +0100

OK, I can agree. My point was verifying that we had the basic setup. Assume
a bootstrapping setup of a disconnected network, then we would not have the
2001: prefix. A self-generated ULA prefix can be used. As a next step, the
globally unique addresses can be added or may replace the ULA.

Teco.

|-----Oorspronkelijk bericht-----
|Van: Dearlove, Christopher (UK) [mailto:[email-masked]]
|Verzonden: donderdag 5 maart 2009 18:19
|Aan: Teco Boot; Alexandru Petrescu
|CC: [email-masked]
|Onderwerp: RE: [Autoconf] Autoconf addressing model
|
|
|> I see a problem with this, who has assigned the globally unique
|prefixes?
|
|Isn't that (part of) the problem this group is to address?
|At this point we are specifying a requirement that (assuming
|that model, which I'm not commenting on) such prefixes are
|to be assigned. How it happens (as long as it's possible, and
|manual configuration, though not the required solution, is
|presumably an existence proof for that) is not the issue
|right now.
|
|
|********************************************************************
|This email and any attachments are confidential to the intended
|recipient and may also be privileged. If you are not the intended
|recipient please delete it from your system and notify the sender.
|You should not copy it or use it for any purpose nor disclose or
|distribute its contents to any other person.
|********************************************************************

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 05 Mar 2009 18:53:54 +0100

>        |fe80::1/64            |fe80::2/64            |fe80::3/64

Teco I don't agree with this setup.  It's a significant leap of faith 
from the initial starting point.

I need first to listen to what others think about the initial starting 
point.

Alex