[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The renumbering problem [Re: [BEHAVE] Comments on the NAT66 draft]
On Nov 16, 2008, at 21:29, Brian E Carpenter wrote:
On 2008-11-11 11:24, james woodyatt wrote:
...
That said, I'm not impressed by the arguments put forward by the
opponents of RFC 4864 local network protection who, in my view, are
greatly exaggerating the seriousness of the network renumbering
problem.
James, and anyone else who is still able to focus on this thread:
Please read draft-carpenter-renum-needs-work-00.txt and send
comments and suggestions to its authors.
I'm delighted to read this draft. I remain unconvinced by arguments
that the network renumbering problem is a compelling argument for the
need to insert thirty gazillion PI routes into the DFZ.
----
Some thoughts on section 2.2, Existing Host-related Mechanisms => PPP...
For IPv4, PPP endpoints acquire (during IPCP negotiation) both their
own address and the address of their peer, which may be assumed to be
the default router if no routing protocol is operating. Renumbering
events arise when IPCP negotiation is restarted on an existing link,
when LCP is terminated and restarted, or when the point-to-point
medium is reconnected. (I can't remember right now whether NCP must
be renegotiated if an authentication protocol is restarted while NCP
is up.) Peers may propose either the local or remote address or
require the other peer to do so. Negotiation is complete when both
peers are in agreement. In practice, if no routing protocol is used,
then the provider proposes both addresses and requires the subscriber
either to accept the connection or abort.
For IPv6, PPP endpoints acquire both local and remote addresses during
IP6CP negotiation in much the same way as for IPv4, but the addresses
are link-local scope only. In practice, each side can propose its own
address and renegotiation is only necessary when there is a
collision. Once link-local addresses are assigned and IP6CP is
complete, automatic assignment of global scope addresses is performed
by the same methods as with multipoint links, i.e. either SLAAC or
DHCP6, which are described in the subsequent sections of the draft.
----
Also: section 2.5 about DNS... this section really, really, really
ought to at least think about mentioning DNS-SD (for which the
relevant Internet Drafts-- for reasons that continue to plague the
twilight of my waking dreams-- are categorized as Informational, and
not Standards Track).
If you've never heard of DNS-SD before, then please look at...
<http://www.dns-sd.org/>
...and follow the links from there. The executive summary is that not
only can we dynamically update the DNS with host address records, we
can even do it with *service* instances too, which are pointers to
service records that reference host records. It works pretty well.
Really. I renumber some of my networks *dozens* *of* *times* *per*
*DAY*. Some of these are *virtual* networks. It's not even remotely
painful until I start trying to do it a few dozen times per *hour*.
That's pretty good!
Yes, DNS-SD and DNSSEC are quite compatible. Really. Come join us in
the Future™. It's nice here. Stuff just works.
-----
The M&O bits. I'm one of those who thinks that ICMP6 is the protocol
that ought to be used for control and management of the Internet. I
think that DHCP (with DHCP6, it's 2nd-system-effect offspring) is a
monster that slipped its leash a long time, and we're all poorer for
it now. So, it should not be a surprise that I favor resolving the so-
called "M&O ambiguity" by clarifying the specification to say that
starting the DHCP6 client is *always* OPTIONAL and that nodes *always*
MAY self-assign a global scope address after receiving any RA
containing a PIO with A=1.
I recognize that my preferred approach poses some problems (many of
which are the subject of ongoing work in the SAVI and V6OPS working
groups), but I contend that we will all be better off if *those* are
the problems we choose to make for ourselves and we proceed now to set
our minds to solving them. The other problems we invite for ourselves
resolving the M&O ambiguity by different means are more troubling, I
say. We might as well just get rid of SLAAC altogether and require
DHCP6 everywhere. I know that would make some people happy, but not
me. I rather like zero configuration networking.
-----
On section 4.1.2, Transport Layer Issues... let me just say that SCTP
is made of the purest elegance and beauty. We should deprecate TCP
over IPv6 in favor of SCTP, it's so good. Oh wait... worse is
better. I keep forgetting.
So, if we *can't* migrate to SCTP, and we MUST find a way to live with
TCP and UDP, then we're just going to have to lump it when renumbering
causes failurage on TCP/UDP flows. But that shouldn't be so bad,
really. You want SCTP-style multihoming with your TCP transports?
Then you can implement it in your session^H^H^H^H^H^H^H application
layer. (If I wanted to be especially curmudgeonly, I'd suggest a BEEP
tuning profile for the TCP transport mapping, but I'll go easy on that
for now.)
-----
On section 4.1.4, Application Layer Issues... the following quote is
the understatement literally of the decade:
The sensitivity depends on whether the implementation stores IP
addresses in such a way that it may refer back to them later,
without allowing for the fact that they may no longer be valid.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This, in my view, is the main reason why IPv6 renumbering should be
regarded as "still needs some work" instead of "why are we worrying
about this?" But the work in question isn't IETF work, I contend.
It's just mundane code-wrangling work.
I've highlighted what I regard as the crucial phrase. We're talking
about software bugs. We're talking about software bugs of a general
class, i.e. cache coherency failures, that cannot really be mitigated
by sacrificing fundamental principles of the Internet architecture to
make the renumbering events that expose them less frequent. There are
so many other ways, which have nothing to do with network renumbering
events, that bugs of this class can make expensive software failures
happen. I'd prefer we find ways to build better coders, than we were
to expend any effort trying to take Internet address renumbering off
the long list of interesting ways that incoherent caches can break
software.
My employers have a developer technote on their website that speaks to
this general class of software problem in networked applications. The
tenth anniversary [!] of its original composition came and went a few
days ago. The document is here:
<http://developer.apple.com/technotes/tn/tn1145.html>
Seriously. Check it out. Application layer issues with renumbering
events would not be expensive if the platform-independent lessons of
that technical note were more widely applied.
I am so *so* tired of making excuses for bad code. Just once, I'd
like to be able to say, "I see your coders thought it would be a good
idea to store IP addresses in a persistent store without any cache
coherency protocol, and now you can't renumber your network without
eating the time and expense of qualifying a radical new implementation
of your hugely business-critical software application. You know
what? That's your own fault. Not ours. p.s. I bet you'll read that
tech-note next time, right?"
--
james woodyatt <jhw@apple.com>
member of technical staff, communications engineering