On Mon, 23 Aug 2010 09:06:50 +0900
Randy Bush <randy@psg.com> wrote:

> > If the /127 draft is a rebuttal of RFC3627
> 
> and if it isn't?  maybe it's just a bug report on one bit?
> 

Well, firstly, this is the text in the /127 draft which seems to
suggest to me it is:

"This document provides rationale for using 127-bit prefix lengths,
   reevaluates the reasons why doing so was considered harmful, and
   specifies that /127 prefixes MUST be supported on inter-router links
   configured for use as point-to-point links."

The MUST in capitals is the key word. The Interface ID has been 64 bits
in length since RFC2373 (July 1998) for global prefixes. Many RFCs rely
on that. This draft is setting itself up to be the new authoritative
statement on an exception to all the prior RFCs that have followed the
64 IID specification. I think therefore it is obligated to address all
the issues that an exception creates.

Alternatively, if it was published as an Informational RFC, I think the
threshold of detail required could be lower.

IMHO, where the real problem lies isn't the /64 prefix length, it's in
the neighbor discovery neighbor solicitation/neighbor advertisement
mechanism, and even more specifically, it's caused by these two
requirements in the Neighbor Discovery RFC, "7.2.2. Sending Neighbor
Solicitations" -

" While waiting for address resolution to complete, the sender MUST,
   for each neighbor, retain a small queue of packets waiting for
   address resolution to complete.  The queue MUST hold at least one
   packet, and MAY contain more.  However, the number of queued packets
   per neighbor SHOULD be limited to some small value.  When a queue
   overflows, the new arrival SHOULD replace the oldest entry.  Once
   address resolution completes, the node transmits any queued packets."

and

"If no Neighbor Advertisement is received after MAX_MULTICAST_SOLICIT
 solicitations, address resolution has failed.  The sender MUST return
 ICMP destination unreachable indications with code 3 (Address
 Unreachable) for each packet queued awaiting address resolution."

The MUST of holding a queue of NS triggering packets, and the MUST of
returning an ICMP destination unreachable create remotely exploitable
state on a router's interface. Switching off NS/NA on links where it
could be (i.e. point-to-point links), mitigates that, however it then
creates the ping-pong problem. /127s is a mitigation for that, however
it isn't a solution for links containing end-nodes i.e. LANs. There'll
still be millions of them that are remotely exploitable from offlink
sources. So /127s are very much a partial rather than full solution.
Lengthening the prefix length/shortening the IID is always a
mitigation, not a solution to the remote exploitable state.

I think there are two realities which reduce the usefulness of
these MUST implement mechanisms -

o  the Internet is best effort, so if a source node wants to be
confident that the packet arrived, it needs to be prepared to
re-transmit it. Queueing it on a router while NS/NA takes place helps
but doesn't avoid a node having to be prepared to retransmit.

o  Also due to the best effort nature of the Internet, there is a
possibility that the ICMP destination unreachable won't make it back to
the original packet's source, with perimeter firewalls being one of the
causes.

If those MUSTs were loosened to SHOULDs or MAYs, then it would be
acceptable to avoid having a router maintain state while the ND
NS/NA transaction takes place.

Once that state requirement is removed, I think there are a number of
ways to solve the layer 3 to layer 2 address mapping function on a link
-

o  have nodes periodically announce themselves via unsolicited
multicasts - the ES-IS model.

o  have nodes register there presence via a two way transaction - the
6lowpan ND optimisation mechanism might be a candidate.

o  use an NS/NA transaction, with the NS containing a magic
cookie in the flow label field or maybe an ND option that is copied
into the NA, and verified by the NS originator. The number of NSes per
second might be rate limited to avoid creating a CPU DoS because of
cookie generation. Source nodes will eventually retransmit their
packets if the NS doesn't occur because the cookie generation rate
limit was exceeded.

o  use an NS/NA transaction, and just accept NAs when ever they arrive.
There are more trust issues here because on the onlink nodes could DoS
the router with NAs - however they have far more of an incentive to not
do it because they're likely to be DoSing the router that provides them
with offlink connectivity. This is essentially a passive/solicited
version of the ES-IS model. It could also be considered a "loose" or
existing ND NS/NA "compatibility" mode of the more "strict" NS/NA cookie
transaction mode.

These mechanisms are applicable to any type of link, would preserve the
simplicity of universal 64 bit IIDs and the other benefits of them e.g.
CGAs, as well as avoiding the ping-pong problem.



> > Other examples - there are probably more - of things I think that should
> > be discussed, beyond what is in RFC3627 -
> 
> where is that darned immersion heater?
> 

No sure what they do. Can I buy one that runs IPv6?

Regards,
Mark.