>>>>> On Tue, 22 Feb 2005 13:47:07 -0500,
>>>>> "Soliman, Hesham" <[EMAIL PROTECTED]> said:
>> Non-editorial comments
>>
>> 1. (throughout the document)
>>
>> There is a mixture of
>> - how IPv6 operates over different link layers
>> and
>> - how IP operates over different link layers
>> even though there does not seem to be ambiguity of what "IP" means.
>> I guess we can simply use "how IP"...for all the cases.
> => I'd rather use IPv6 if that's ok with everyone since this doc is only
> applicable
> to IPv6.
Hmm, I actually don't have a strong preference as long as the result
is consistent, but just "IP" seems to be more aligned with the sense
of Section 2.1:
IP - Internet Protocol Version 6. The terms IPv4 and
IPv6 are used only in contexts where necessary to avoid
ambiguity.
>> 4. Section 2.3. (Addresses)
>>
>> Note that this specification does not strictly comply with the
>> consistency requirements for the scopes of source and destination
>> addresses. It is possible in some cases for hosts to use a source
>> address of a larger scope than the destination address in the IPv6
>> header.
>>
>> what's the "consistency requirements"? What ever they are, should we
>> bother to mention this in the first place?
> => We can refer to src address selection rules here for the consistency
> requirements.
So do you mean RFC3484 here? Then I guess we should be more generic,
e.g.:
Note that this specification does not strictly comply with the
default address selection rules described in [RFC3484]. In
particular, it is possible in some cases for hosts to use a source
address of a larger scope than the destination address in the IPv6
header, even if [RFC3484] would not prefer that combination.
>> 5. Section 4.2. (Router Advertisement Message Format)
>>
>> Reserved A 6-bit unused field. It MUST be initialized to
>> zero by the sender and MUST be ignored by the
>> receiver.
>>
>> I'm wondering whether we can be more flexible here, since we've
>> already had several proposals that use the "Reserved" field. I know
>> our consensus is that rfc2461bis itself does not included those
>> extensions, but I think it is less-confusing to note that
>> the Reserved
>> field may be used in future extensions.
> => It's sort of self explanatory that Reserved can be used in future, the
> important
> thing is that it's set to zero and ignored on reception.
My concern is that people who read RFC2461bis might see a new
implementation that support the "H" bit of RFC3775 and say "this
implementation does not conform to RFC2461bis because it does not set
the reserved field to zero". Basically, I'm not intending to insist
on this point, but I think it would not harm to make a note about
future extensions, particularly because we already know we have
extensions. (I won't defend myself on this more. If you still think
it's too much, please just ignore this comment).
>> 8. Section 4.6.2. (Prefix Information)
>>
>> Prefix An IP address or a prefix of an IP address. The
>> Prefix Length field contains the number of valid
>> leading bits in the prefix. [...
>> ...] A router SHOULD NOT send a prefix
>> option for the link-local prefix and a
>> host SHOULD
>> ignore such a prefix option.
>>
>> => I don't see why we cannot use 'MUST (NOT)' here. Is there any
>> scenario where it makes sense for a router to include the link-local
>> prefix in the prefix information option? (Perhaps it's too late to
>> make this comment, and I'm personally fine is the current wording).
> => MUSTs are used to indicate that the protocol would break if a certain
> action]
> is taken. In this case the protocol will not break so no need for MUST.
Hmm, it's different from my view of SHOULD/MUST/etc, but I won't
insist on it. So please just ignore this comment.
>> 11. Section 6.3.4. (Processing Received Router Advertisements)
>>
>> Stateless address autoconfiguration [ADDRCONF] may in some
>> circumstances increase the Valid Lifetime of a prefix or ignore it
>> completely in order to prevent a particular denial of
>> service attack.
>>
>> "the Valid Lifetime of a prefix" is not really correct in the context
>> of [ADDRCONF]; the lifetime is associated with addresses, not
>> prefixes. And [ADDRCONF] does not directly manipulate prefix
>> lifetimes. So, I think it's better to say, e.g.:
>>
>> Stateless address autoconfiguration [ADDRCONF] may in some
>> circumstances use a larger Valid Lifetime of a prefix or
>> ignore the
>> Valid Lifetime completely in order to prevent a particular denial
>> of service attack.
> => I don't see how this is different from the above though. Using a larger LT
> means
> you've increased it.
My point was that there's a no notion of "Valid Lifetime of a
**prefix**" in [ADDRCONF]. It only has "Valid (and Preferred)
Lifetime of an address". That's why I suggested using "use". I
believe it clarifies the things a bit and is more accurate, but the
original text would not confuse the reader. So, I'd leave the
decision to you.
>> 15. Section 11.1 (Threat analysis)
>>
>> 2461bis-02 has removed the following part of RFC2461:
(snip)
>> But I believe these requirements are still valid and should be
>> included *when we use IPsec* for ND, even if we note the
>> limitation of
>> the use of IPsec to secure ND.
> => Since we removed all reference to IPsec except on its limitations, I don't
> think we should add this one last bit because it might confuse people.
> Realistically,
> IPsec is not going to be used with ND in a large network.
Hmm...I agree with the "realistic" view itself, but unless we prohibit
the use of IPsec, I believe it is overkilling to remove requirements
(using RFC2119 keywords) when it is used.
Is it so harmful to revise the paragraph to, e.g., the following?
In some cases, it may be acceptable to use statically configured
security associations with either [IPv6-AH] or [IPv6-ESP] to secure
Neighbor Discovery messages. However, it is important to note that
statically configured security associations are not scalable
(especially when considering multicast links) and are therefore
limited to small networks with known hosts. In any case, when
[IPv6-AH] is used, received Authentication Headers in Neighbor
Discovery packets MUST be verified for correctness and packets with
incorrect authentication MUST be ignored.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
