>>>>> On Fri, 3 Sep 2004 11:57:36 +0200 , 
>>>>> "Elwyn Davies" <[EMAIL PROTECTED]> said:

> Getting the wording right without creating double maintenance is a problem.

> The point is that an address prefix only specifies the (prefix length) left
> most bits.  RFC3513 has examples with essentially arbitrary bits to the
> right of the prefix.  FE80::0/10 implies but does not make explicit what the
> rest of the bits should be as well as putting back the double maintenance
> thing.

Okay, I see your first point.  Regarding the double maintenance issue,
I still think it's controversial.  In addition to the points I raised
in my previous message, we've already have several double-maintenance
issues on the unicast link-local prefix: several RFCs has already
hard-coded the concrete prefix of FE80::/10 or FE80::/64.  To name a
few:

  RFC2464, RFC2472, RFC2491, RFC2497, RFC2590, RFC3146 (IPv6 over xxx links)
  RFC2529 (6over4)
  RFC2546 (6bone routing practice)
  RFC3315 (DHCPv6)
  ...

and I'm quite sure several other I-Ds also hard-coding the concrete
prefix.

Will we really want to generalize the description for the existing
RFCs when they are to be revised?  Also, do we really want to "correct"
all those I-Ds, before publication, not to hardcode the constant to
avoid double maintenance problem?  I don't think so.  And if not, why
is rfc2462bis so special?

So,

> How about:

> A link-local address is formed by combining the well-known link-local prefix
> [RFC3513] with the interface identifier as follows:
...

the organization of the suggested text looks fine, but I'd still
rather be concrete on the constant.  And then the revised text would
be as follows:

=========================== from here =================================
A link-local address is formed by combining the well-known link-local
prefix FE80::0 [RFC3513] (of appropriate length) with the interface
identifier as follows:

1. The left-most 'prefix length' bits of the address are the link
   local prefix
2. The bits in the address to the right of the link-local prefix are
   set to all zeroes
3. If the length of the interface identifier is N bits, the right-most
   N bits of the address are replaced by the interface identifier.

If the sum of the prefix length and N is larger than 128 ...
=========================== to here ===================================

Can we live with this?

                                        JINMEI, Tatuya
                                        Communication Platform Lab.
                                        Corporate R&D Center, Toshiba Corp.
                                        [EMAIL PROTECTED]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[EMAIL PROTECTED]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to