Re: [Autoconf] Autoconf addressing model

["Teco Boot" <[e-mail]>]

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:[e-mail]]
|Verzonden: zaterdag 28 februari 2009 14:44
|Aan: Teco Boot
|CC: [e-mail]; '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:[e-mail]]
|> |Verzonden: donderdag 26 februari 2009 21:41
|> |Aan: Alexandru Petrescu
|> |CC: Teco Boot; [e-mail]
|> |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/
|++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++