Subject: [16NG] Responses to your comments on I-D draft-ietf-16ng-ipv6-over-ipv6cs-02

From: Basavaraj Patil <[email-masked]>
Date: Fri, 15 Dec 2006 16:15:17 -0600

Jari,

I have addressed your comments in Rev 3 of the I-D (submitted to the
drafts editor and should be published soon). Comments inline:

>Hi,
>
>I reviewed the new version of this specification.
>Overall, it has no major technical problems but
>still needs another editing round to tighten
>the language, move non-core descriptive text to
>an appendix, correct a few mistakes, and explain
>how IPCS/Eth/Etc will be interoperable in a
>multi-vendor environment that is not completely
>under the control of a single administration.
>
>Please see the comments below:
>
>>    The scope of this document is limited to IPv6 operation over the IP
>>    specific part of the Packet CS only.  It should be noted that while
>>    capability exchange of the MS and BS is performed, there is no
>>    negotiation of which service specific part of the packet CS will be
>>    used for IPv6 transport.
>This is still problematic.
>
>I would not keep on raising this if I thought the current
>text would pass the final IESG review, but given the attention
>to this issue in the chartering stage you HAVE to provide
>a credible explanation of how this does not end up
>in interoperability problems.

I have addressed this comment in a separate email. Please refer to:
http://www1.ietf.org/mail-archive/web/16ng/current/msg00021.html

>
>>                        Figure 3: IPv6 encapsulation
>This is vague. I know it was me who asked for the
>picture, but this picture is not helpful in terms
>of me actually knowing how to implement anything.
>Perhaps you should just keep the first sentence
>of Section 4.1, and add references to the specific
>IEEE documents and their sections.

I have added some additional text in this section in rev 3 of the
I-D. So maybe that clarifies. The new text is:

"For transmission of IPv6 packets via the IP specific part of the
Packet CS of 802.16, the IPv6 layer interfaces with the 802.6 MAC
directly. The IPv6 layer delivers the IPv6 packet to the Packet CS of
the 802.16. The packet CS defines a set of classifiers that are used
to determine how to handle the packet. "
and continues with the classifiers description.
"The MAC encapsulates the
IPv6 packet in the 6 byte MAC header and transmits it."

>> 5.1.  WiMAX network architecture and IPv6 support
>> 6.1.1.  IPv6 link in WiMAX
>> 6.2.1.  IPv6 link establishment in WiMAX
>> 6.3.1.  Maximum transmission unit in WiMAX
>
>I would like to move the WIMAX sections to an
>appendix. I do not see anything in them that
>requires the implementor to know about it,
>as long as we are talking about the "IPv6
>over 802.16" part. And this spec is the
>better the shorter it is. And there will
>be less questions from the reviewers
>and the rest of the IESG.
>
>You can add a forward reference
>to the appendix in their place,
>however. For instance, "Further details
>relating to the network setup / tunnel set
>up / MTU in WIMAX networks are described
>in Appendix X."

Okay. Done. Gabriel also had a similar comment.

>
>>    The collection of service flows (tunnels) to an MS is defined as a
>>    single link.  Each link has only an MS and an AR.  Each MS belongs to
>>    a different link.  No two MSs belong to the same link.  A different
>>    prefix should be assigned to each unique link.  This link is fully
>>    consistent with a standard IP link, without exception and conforms
>>    with the definition of a point-to-point link in RFC2461 [RFC2461].
>This part of 6.1.1 should probably be listed
>in Section 6.1 already, because it appears
>to be universally true.

Okay. Done.

>> The prefixes
>>    are advertised with the on-link (L-bit) flag set to facilitate
>>    Detecting Network Attachment (DNA) operation [RFC4135].
>You are referring to a goals document and there is
>no published protocol to go with it.

Agree. I deleted the reference to the DNA goals RFC.

>
>But there are other reasons why setting the L bit
>makes sense. In general, this specification mixes
>operational advice with implementation requirement,
>and it is very unclear whether, for instance,
>if L=0 would be disallowed in 802.16.
>
>I would suggest making it clear which parts of
>the document actually state something that is
>mandatory and what is not. For instance, this
>section could be rewritten as follows:
>
>   Each MS MUST be considered to be on a separate subnet as
>   a result of the point-to-point connection.
>
>   The size and number of the prefixes is a configuration
>   issue. Also, prefix delegation may be used to provide
>   additional prefixes for a router connected over 802.16.
>
>   The other properties of the prefixes are also a
>   configuration issue. But typically the prefixes
>   are advertised with the on-link (L-bit) flag set.

Thanks for this text. I have incorporated it.

>
>>    The MS has a 48-bit MAC address as specified in 802.16e [802.16e].
>>    This MAC address is used to generate the 64 bit interface identifier
>>    which is used by the MS for address autoconfiguration.
>>    The IID is
>>    generated by the MS as specified in RFC2464 [RFC2464].  For addresses
>>    that are based on privacy extensions, the MS may generate random IIDs
>>    as specified in RFC3041 [RFC3041].
>IID is an undefined abbreviation in this document.
>Also, again, its hard to determine what the document is
>really mandating in terms of EUI-64 usage.
>
>How about this: "The MS has a 48-bit MAC address as specified in
>802.16e [802.16e]. This MAC address can be used if EUI-64 -based
>interface identifier is needed for autoconfiguration [RFC 4291].
>As in other links that support IPv6, EUI-64 -based interface
>identifiers are not mandatory and other mechanisms, such as
>random interface identifiers [RFC 3041] may also be used."

I have incorporated your suggested text. Thx.

>
>>    If the A-bit in the prefix information option (PIO) is set, the MS
>>    performs stateless address autoconfiguration as per RFC 2461, 2462.
>>    The AR is the default router that advertises a unique /64 prefix (or
>>    prefixes) that is used by the MS to configure an address.
>The second sentence seems to imply that the prefix
>size has to be exactly 64 bits. You could fix that
>but I'm not sure the second sentence is actually
>adding anything useful here. You already stated
>earlier that the prefixes are per-MN.

Changed the /64 prefix limitation in the main body of the
document. Specified /64 prefix as the option in the WiMAX specific
section in the appendix.

>
>>    This document does not introduce any new vulnerabilities to IPv6
>>    specifications or operation as a result of the 802.16 air interface
>>    or the WiMAX network architecture.
>I do not think you want to claim that there are no
>new vulnerabilities because of the 802.16 link.
>How about this:
>
>  This document does not introduce any new vulnerabilities to IPv6
>  specifications or operation. The security of the 802.16 air
>  interface is the subject of [REFERENCE]. In addition, the
>  security issues of the network architecture spanning beyond
>  the 802.16 base stations is the subject of the documents
>  defining such architectures, such as [REFERENCE].

I agree. I have incorporated the text with the appropriate references.

>
>>    [RFC3041]  Narten, T. and R. Draves, "Privacy Extensions for
>>               Stateless Address Autoconfiguration in IPv6", RFC 3041,
>>               January 2001, <ftp://ftp.isi.edu/in-notes/rfc3041>.
>Please refer to draft-ietf-ipv6-privacy-addrs-v2-05, because
>it is in the RFC Editor's queue already.
>>    [RFC3314]  Wasserman, Ed., M., "Recommendations for IPv6 in Third
>>               Generation Partnership Project (3GPP) Standards",
>>               RFC 3314, September 2002,
>>               <ftp://ftp.isi.edu/in-notes/rfc3314>.
>>    [RFC3756]  Nikander, P., Kempf, J., and E.  Nordmark, "IPv6 Neighbor
>>               Discovery (ND) Trust Models and Threats", RFC 3756,
>>               May 2004, <ftp://ftp.isi.edu/in-notes/rfc3756 >.
>>
>>    [RFC4135]  Choi, JH. and G. Daley, "Goals of Detecting Network
>>               Attachment in IPv6", RFC 4135, August 2005,
>>               <ftp://ftp.isi.edu/in-notes/rfc4135>.
>These should be informational references. Nothing
>in those document is needed to implement this.

Okay.

>
>>    The addressing scheme for IPv6 hosts in 802.16 network follows the
>>    IETFs recommendation for hosts specified in RFC 4294.  The IPv6 node
>>    requirements RFC RFC4294 [RFC4294] specifies a set of RFCs that are
>>    applicable for addressing.
>> ... 
>>    [RFC4294]  Loughney, Ed., J., "IPv6 Node requirements", RFC 4294,
>>               April 2006, <ftp://ftp.isi.edu/in-notes/rfc4294>.
>Not sure what "recommendation" exists in 4294 -- it simply points
>to existing RFCs on, say, addressing. Perhaps you meant RFC 3314
>in the first sentence? By the way it isn't mentioned in the text.

No... I meant 4294. And not 3314. I had 3314 earlier... But changed it.

>> TBD.
>
>I realize this in an acks section, but the document
>needs to be complete when its shipped to the IESG.
>You cannot edit it afterwards.

Done.

>
>>    o  delivering the CS PDU to theappropriate service flow and transport
>s/thea/the a/

Ack.

-Raj
>--Jari

_______________________________________________
16NG mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/16ng

---

From: Jari Arkko <[email-masked]>
Date: Sun, 17 Dec 2006 22:26:19 +0200

Basavaraj,

Thanks for incorporating the changes! Further discussion
> IPv6 packet in the 6 byte MAC header and transmits it."
Can you add references to the relevant IEEE spec
and section on how the encapsulation is done. Are
there any details that you need to give, such as
how to fill certain parameters (like EtherType in
Ethernet).

For an example of what the encapsulation part
of an IPv6 over Foo document should say, look
at RFC 2464 Section 3.
> No... I meant 4294. And not 3314. I had 3314 earlier... But changed it.
Hmm... does RFC 4294 really provide some addressing scheme
recommendations? Or do you mean that RFC 4294 points
to RFC 3513, which describes the IPv6 addressing architecture.
But I'm not sure it can be characterized as a "recommendation".

Anyway, this is not a major sticking point for me, but I'm
still confused what you mean here.

--Jari