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

Fred Baker <[email protected]>
Newsgroups gmane.ietf.v6ops,gmane.ietf.multi6
Message-ID <[email protected]>
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

     ftp://ftpeng.cisco.com/fred/v6ops/renumber.html
     ftp://ftpeng.cisco.com/fred/v6ops/renumber.txt
     ftp://ftpeng.cisco.com/fred/v6ops/renumber.xml

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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.