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

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 7 Jul 2004 23:23:44 +0200

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.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 8 Jul 2004 07:29:43 +0300 (EEST)

On Wed, 7 Jul 2004, Fred Baker wrote:
> >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.
[...]

A possible compromise here could be putting RFC3704 in as a
*normative* reference (btw, some of those other ones might be as well
because they're required for understanding), implying that it's a MUST
read.. which could be interpreted as not having to summarize or
repeats its contents here.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Fred Baker <[email-masked]>
Date: Wed, 07 Jul 2004 15:27:34 -0700

At 11:23 PM 07/07/04 +0200, Iljitsch van Beijnum 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.
>

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?

---

From: Fred Baker <[email-masked]>
Date: Wed, 07 Jul 2004 13:39:23 -0700

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.

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.

---

From: Fred Baker <[email-masked]>
Date: Thu, 08 Jul 2004 00:41:47 -0700

At 07:29 AM 07/08/04 +0300, Pekka Savola wrote:
>A possible compromise here could be putting RFC3704 in as a *normative*
>reference (btw, some of those other ones might be as well because they're
>required for understanding), implying that it's a MUST read.. which could
>be interpreted as not having to summarize or repeats its contents here.

I'm perfectly willing to do that. Will that address the issues?

Glancing through, I at the moment have all references as informational. It
occurs to me that this is probably not right. Would you suggest the
following, or would you also make others normative? There is probably an
argument for making all or almost all of the RFCs normative, but my sense
is not to take quite that expansive of a view.

         <references title="Normative References">
                         <?rfc include="reference.RFC.2072" ?>
                         <?rfc include="reference.RFC.2460" ?>
                         <?rfc include="reference.RFC.2461" ?>
                         <?rfc include="reference.RFC.2462" ?>
                         <?rfc include="reference.RFC.3315" ?>
                         <?rfc include="reference.RFC.3704" ?>
         </references>
                 <references title="Informative References">
                         <?rfc include="reference.RFC.1034" ?>
                         <?rfc include="reference.RFC.1035" ?>
                         <?rfc include="reference.RFC.1305" ?>
                         <?rfc include="reference.RFC.1995" ?>
                         <?rfc include="reference.RFC.1996" ?>
                         <?rfc include="reference.RFC.2136" ?>
                         <?rfc include="reference.RFC.2535" ?>
                         <?rfc include="reference.RFC.2827" ?>
                         <?rfc include="reference.RFC.2845" ?>
                         <?rfc include="reference.RFC.2931" ?>
                         <?rfc include="reference.RFC.3007" ?>
                         <?rfc include="reference.RFC.3177" ?>
                         <?rfc
include="reference.I-D.ietf-dhc-dhcpv6-opt-prefix-delegation"?>
                         <?rfc
include="reference.I-D.ietf-dnsop-ipv6-dns-issues"?>

    [Clausewitz]
               von Clausewitz, C., Howard, M., Paret, P. and D. Brodie,
               "On War, Chapter VII, 'Friction in War'", June 1989.

    [I-D.ietf-dhc-dhcpv6-opt-prefix-delegation]
               Troan, O. and R. Droms, "IPv6 Prefix Options for DHCPv6",
               draft-ietf-dhc-dhcpv6-opt-prefix-delegation-05 (work in
               progress), October 2003.

    [I-D.ietf-dnsop-ipv6-dns-issues]
               Durand, A., Ihren, J. and P. Savola, "Operational
               Considerations and Issues with IPv6 DNS",
               draft-ietf-dnsop-ipv6-dns-issues-07 (work in progress),
               May 2004.

    [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
               STD 13, RFC 1034, November 1987.

    [RFC1035]  Mockapetris, P., "Domain names - implementation and
               specification", STD 13, RFC 1035, November 1987.

    [RFC1305]  Mills, D., "Network Time Protocol (Version 3)
               Specification, Implementation", RFC 1305, March 1992.

    [RFC1995]  Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
               August 1996.

    [RFC1996]  Vixie, P., "A Mechanism for Prompt Notification of Zone
               Changes (DNS NOTIFY)", RFC 1996, August 1996.

    [RFC2072]  Berkowitz, H., "Router Renumbering Guide", RFC 2072,
               January 1997.

    [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
               Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
               April 1997.

    [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
               (IPv6) Specification", RFC 2460, December 1998.

    [RFC2461]  Narten, T., Nordmark, E. and W. Simpson, "Neighbor
               Discovery for IP Version 6 (IPv6)", RFC 2461, December
               1998.

    [RFC2462]  Thomson, S. and T. Narten, "IPv6 Stateless Address
               Autoconfiguration", RFC 2462, December 1998.

    [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
               RFC 2535, March 1999.

    [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
               Defeating Denial of Service Attacks which employ IP Source
               Address Spoofing", BCP 38, RFC 2827, May 2000.

    [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D. and B.
               Wellington, "Secret Key Transaction Authentication for DNS
               (TSIG)", RFC 2845, May 2000.

    [RFC2931]  Eastlake, D., "DNS Request and Transaction Signatures (
               SIG(0)s)", RFC 2931, September 2000.

    [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
               Update", RFC 3007, November 2000.

    [RFC3177]  IAB and IESG, "IAB/IESG Recommendations on IPv6 Address
               Allocations to Sites", RFC 3177, September 2001.

    [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
               M. Carney, "Dynamic Host Configuration Protocol for IPv6
               (DHCPv6)", RFC 3315, July 2003.

    [RFC3704]  Baker, F. and P. Savola, "Ingress Filtering for Multihomed
               Networks", BCP 84, RFC 3704, March 2004.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 08 Jul 2004 12:00:25 +0200

I's suggest that at this point in the discussion you can drop
the cross-posting to multi6.

While you are tweaking, it might be worth adding a note that
the eventual multi6 solution(s) may add new issues to
the renumbering recipe, or alternatively may simplify it.

    Brian

Fred Baker wrote:
> Glancing through, I at the moment have all references as informational. 
> It occurs to me that this is probably not right. Would you suggest the 
> argument for making all or almost all of the RFCs normative, but my 
> sense is not to take quite that expansive of a view.
>

---

From: Fred Baker <[email-masked]>
Date: Thu, 08 Jul 2004 09:15:41 -0700

At 12:00 PM 07/08/04 +0200, Brian E Carpenter wrote:
>While you are tweaking, it might be worth adding a note that the eventual
>multi6 solution(s) may add new issues to the renumbering recipe, or
>alternatively may simplify it.

Actually, I'm not at all sure that they can.

The problems with renumbering without a flag day are not in the technology
there to assign new addresses and such. They are first and perhaps foremost
in the applications and configuration scripts that forego those tools in
favor of static or configuration.

More subtly, there are issues with the "who knows what when" operational
steps that ensure that a one system knows a given address of another system
if and only if the other system is using it and the connecting
infrastructure in fact connects them. If you have selected a new address
but one of the eleven routers between you and I doesn't know how to route
to the prefix, when I use your new address I experience a disruption. If an
address is being advertised for you, or was advertised yesterday with a TTL
that leaves me with an active record today, and you stop using the address,
I experience a disruption. I'm talking about making this work not only in
theory in a corner of the world, but operationally supporting applications
using them on an end to end basis.

But as you ask, I will drop the Multi6 copy after this note.