Subject: Re: [16NG] AD review of draft-ietf-16ng-ipv6-over-ipv6cs

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 14 Dec 2006 05:34:55 -0800 (PST)

Should we also have a few paragraphs on IPv4 operation in Packet CS in this draft just like the Eth CS draft?
Such a change, if welcome would solve a number of problems, hoping that it would not delay the RFC process.

Regards.

--behcet

----- Original Message ----
From: Jari Arkko <[email-masked]>
To: Basavaraj Patil <[email-masked]>; "[email-masked]" <[email-masked]>
Cc: [email-masked]
Sent: Wednesday, December 13, 2006 1:02:53 PM
Subject: [16NG] AD review of draft-ietf-16ng-ipv6-over-ipv6cs

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.

>                        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.
> 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."

>    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.
> 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.

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.

>    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."

>    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.

>    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].

>    [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.

>    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.
> 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.

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

--Jari

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

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

---

From: Jari Arkko <[email-masked]>
Date: Thu, 14 Dec 2006 17:22:38 +0200

IPv4 seems very important for the EthCS draft
because it handles both -- but I'm not sure why
we would need to talk about it in the IPv6CS draft.
(Other than possibly due to negotiations involving
CS selection.)

--Jari

Behcet Sarikaya kirjoitti:
> To: Basavaraj Patil <[email-masked]>;
> "[email-masked]" <[email-masked]>
> Cc: [email-masked]

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 14 Dec 2006 10:18:17 -0600

Hi Jari,

The scope of the I-D is specifically limited to IPv6 only. Hence I would
prefer to keep it that way as well.

-Raj

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 14 Dec 2006 17:23:25 +0100

> prefer to keep it that way as well.

Yes, I prefer it being IPv6-only too.  It risks becoming too long with IPv4.

Alex