[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: (v6ops) WG Last Call: draft-ietf-v6ops-renumbering-procedure-00.txt (fwd)



At 11:23 PM 07/07/04 +0200, Iljitsch van Beijnum wrote:
On 7-jul-04, at 22:39, Fred Baker wrote:
When a company changes providers, it is common to institute an overlap period, during which it is served by both providers. By definition, the network is multihomed during such a period. While this document is not about multihoming per se, problems can arise as a result of ingress filtering policies applied by the upstream provider or one of its upstream providers, so the user of this document need also be cognizant of these issues. This is discussed in detail, and approaches to dealing with it are described, in [RFC2827] and [RFC3704].

These references outline ingress filtering, but there is only about half a page in the second one about how to route traffic with certain addresses to a certain provider, and this half page provides very little actual guidance.


A few paragraphs along the lines of "ask one ISP to temporarily accept packets with the other's addresses and use that one for outgoing traffic or use policy routing to match ISPs to the source addresses in outgoing packets, or if these approaches aren't possible, implement a flag-day type of transition" would be very helpful, I think.

In a word, no.


There was a serious attempt last fall to turn this document, which is about "how to renumber a network", into "how to configure ingress filtering and route traffic within multihomed networks". the problem is, there exist a lot of multihomed networks that are not periodically renumbered, and the issues of multihoming apply in them, and (believe it or not) not all networks that get renumbered are multihomed. Yes, a network might be multihomed temporarily while being renumbered, but that doesn't make renumbering==multihoming. They are in fact very different discussions.

In the interest of ever getting a chance to actually do anything useful with "how to renumber a network", Pekka and I put the entire BCP 38 discussion into a separate document, which is now RFC 3704. This working group looked at that document, decided it was sufficient to describe those issues, and published it as an RFC. If it is not sufficient, fixing RFC 3704 is the task of the day, and should be part of the recharter effort that is currently under discussion. Alternatively, Multi6 could produce something useful on the topic.

May I suggest that, by 12 July, you post an updated version of RFC 3704?