[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)
The working group last call has closed, and the only issue that I saw was
the issue of ingress filtering affecting a temporarily homed network.
Personally, I'm not sure that was not covered in section 3.3:
3.3 Ingress Filtering
An important consideration in Section 2.3, in the case where the
network being renumbered is connected to an external provider, the
network's ingress filtering policy and its provider's ingress
filtering policy. Both the network firewall's ingress filter and the
provider's ingress filter on the access link to the network should be
configured to prevent attacks that use source address spoofing.
Ingress filtering is considered in detail in "Ingress Filtering for
Multihomed Networks" [RFC3704].
but I have added the following to the introduction:
1.4 Multihoming Issues
In addition to the considerations presented, the operational matters
of multihoming may need to be addressed. Networks are generally
renumbered for one of three reasons: the network itself is changing
its addressing policy and must renumber to implement the new policy
(for example, a company has been acquired and is changing addresses
to those used by its new owner), an upstream provider has changed its
prefixes and its customers are forced to do so at the same time, or a
company is changing providers and must perforce use addresses
assigned by the new provider. The third case is common.
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].
If this is deemed a sufficient change, I think the documents at
may be considered responsive to the WG last call. I will put in a note to
internet-drafts to post them on Monday barring further comment, and request
the chairs to forward them to the IESG.