Re: RFC 3484 section 6 rule 9 causing more operational problems

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 4 Mar 2009, Andrew Sullivan wrote:
>
> May I assume that we'll see your I-D specifying the change as soon as
> possible, then?  (I appreciate that it's a little late for a -00, but
> maybe after the queue re-opens?)

I'm happy to say that Arifumi's I-D that Tim linked to already addresses
this problem, and seems to make a sensible recommendation. I'm upset that
it's too late to avoid serious operational pain.

http://www.watersprings.org/pub/id/draft-arifumi-6man-rfc3484-revise-00.txt

2.5.  To disable or restrict RFC 3484 Section 6 Rule 9

   Possible changes to RFC 3484 are as follows:

   1.  To delete Rule 9 completely.

   3.  To apply Rule 9 for IPv6 conditionally and not for IPv4.  When
       the length of matching bits of the destination address and the
       source address is longer than N, the rule 9 is applied.
       Otherwise, the order of the destination addresses do not change.
       The N should be configurable and it should be 32 by default.
       This is simply because the two sites whose matching bit length is
       longer than 32 are probably adjacent.

   Now that IPv6 PI address is admitted in some RIRs, hierachical
   address assignment is not maintained anymore.  It seems that the
   longest matching algorithm is not worth the adverse effect of
   disalbing the DNS based load balance technique.  Therefore, the
   proposal 1 or 3 seems to be preferable.

Tony.
-- 
f.anthony.n.finch  <dot@xxxxxxxx>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.
_______________________________________________

Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]