Re: The renumbering problem [Re: [BEHAVE] Comments on the NAT66 draft]

[james woodyatt <[e-mail]>]

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 <[e-mail]>
member of technical staff, communications engineering