Multi-6 [WAS: OT - Vint Cerf joins Google]

The most basic question is if there will be a problem if we solve the multihoming question in the traditional IPv4 way? And if so, should we solve the problem by throwing hardware at it and hoping that when it becomes a problem the hardware will be sufficiently advanced to be able to solve it?

We can solve the multihoming question in the traditional IPv4 way, de-aggregation. We can argue if that means give end sites a /32, or allow provider independent /48s, but the fact of the matter is a prefix whatever size creates routing state. The sheer size of the IPv6 space allows for lots of routing state.

On the other side, if you remove the routing state then you have a trade off where the information you previously attained through routing state must now be detected in the forwarding plane. We are seeing this now with respect to how end systems detect an outage.


The problem as I see it is that the IETF community is focused on the protocol design, how end hosts signal shim6 capabilities, and failure detection.

They are not focused on operational requirements such as
1. The ability to inter-AS traffic engineering polices
2. To be able to configure and manage inter-AS traffic engineering polices at the network level and not on each individual host
3. The need for transit ASes to leverage traffic engineering.

This is evident by the fact that the language in RFC-3582 that attempted to document traffic engineering requirements was down graded to .goals. in order to get adopted.

The problem as I see it, is that there are only a few providers making this claim that these requirements are indeed requirements and need to be solved before there will be wide spread adoption of IPv6. Most people involved in IETF either don.t care about multihoming, feel that simple fail-over will solve the problem for 90% of the Internet, or only are concerned with things that affect the protocol, and they believe multihoming isn.t one of them.

The process to define how these things work will be done in the IETF, in the shim6 working group... if this might be important to you, perhaps you will want to join the discussion and make your rerquirements/views/issues well known now, before the protocol is specified.