Re: [Autoconf] Autoconf addressing model

[Alexandru Petrescu <[e-mail]>]

Teco Boot a écrit :
> 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.

I agree.

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

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.

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

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