[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?