Re: [Autoconf] Autoconf addressing model

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

|-----Oorspronkelijk bericht-----
|Van: Alexandru Petrescu [mailto:[e-mail]]
|Verzonden: donderdag 5 maart 2009 0:41
|Aan: Teco Boot
|CC: [e-mail]
|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:[e-mail]]
|> |Verzonden: woensdag 4 maart 2009 0:27
|> |Aan: Teco Boot
|> |CC: [e-mail]
|> |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
|> [e-mail]
|> https://www.ietf.org/mailman/listinfo/autoconf
|>