At Fri, 14 Jun 2019 19:13:34 +0100,
NABIL BENAMAR <n.benamar@xxxxxxxxxxxxx> wrote:
> Thank you for your comment.
>
> What do you think of the following changes:
>
> OLD
>
> In the Introduction
>
> “
>
> "....The resulting stack operates over 802.11-OCB
> and provides at least P2P connectivity using IPv6 ND and link-local
> addresses."
> “
> NEW
> “
> "......The resulting stack inherits from IPv6 over Ethernet [RFC
> 2464] and operates over 802.11-OCB
> providing at least P2P connectivity using IPv6 ND and link-local addresses.
I don't have a strong opinion on this addition, but it wouldn't do
harm.
> In section 4.3
>
>
> I will add the following sentence
>
> The best practices for forming IPv6 addresses are inherited from
> Ethernet..
> In particular, the IID is 64 bits long [RFC2464
> <https://tools.ietf..org/html/rfc2464>].
This doesn't seem to be very consistent with the tone of the other
part of the section, in particular:
Among these types of
addresses only the IPv6 link-local addresses MAY be formed using an
EUI-64 identifier, in particular during transition time.
and
If the IPv6 link-local address is formed using an EUI-64 identifier,...
In that RFC2464 only specifies EUI-64 based identifier while this
draft states it's a MAY. If I were to edit the section, I'd simply
specify the IID length at the end of the section like this:
Whether or not the interface identifier is derived from the EUI-64
identifier, its length is 64 bits as is the case for Ethernet
[RFC2464].
And for section 4.4, I'd add, for example, the following sentence at
the end of the second paragraph:
Regardless of how to form the Interface Identifier, its length is 64
bits, as is the case of the IPv6 over Ethernet specification
[RFC2464].
--
JINMEI, Tatuya
NABIL BENAMAR <n.benamar@xxxxxxxxxxxxx> wrote:
> Thank you for your comment.
>
> What do you think of the following changes:
>
> OLD
>
> In the Introduction
>
> “
>
> "....The resulting stack operates over 802.11-OCB
> and provides at least P2P connectivity using IPv6 ND and link-local
> addresses."
> “
> NEW
> “
> "......The resulting stack inherits from IPv6 over Ethernet [RFC
> 2464] and operates over 802.11-OCB
> providing at least P2P connectivity using IPv6 ND and link-local addresses.
I don't have a strong opinion on this addition, but it wouldn't do
harm.
> In section 4.3
>
>
> I will add the following sentence
>
> The best practices for forming IPv6 addresses are inherited from
> Ethernet..
> In particular, the IID is 64 bits long [RFC2464
> <https://tools.ietf..org/html/rfc2464>].
This doesn't seem to be very consistent with the tone of the other
part of the section, in particular:
Among these types of
addresses only the IPv6 link-local addresses MAY be formed using an
EUI-64 identifier, in particular during transition time.
and
If the IPv6 link-local address is formed using an EUI-64 identifier,...
In that RFC2464 only specifies EUI-64 based identifier while this
draft states it's a MAY. If I were to edit the section, I'd simply
specify the IID length at the end of the section like this:
Whether or not the interface identifier is derived from the EUI-64
identifier, its length is 64 bits as is the case for Ethernet
[RFC2464].
And for section 4.4, I'd add, for example, the following sentence at
the end of the second paragraph:
Regardless of how to form the Interface Identifier, its length is 64
bits, as is the case of the IPv6 over Ethernet specification
[RFC2464].
--
JINMEI, Tatuya
