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

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

Hi Jari,
  Packet CS handles both IPv4 and IPv6, more specifically as Raj wrote it:
There is no IPv4 specific part of the packet CS. There is only the IP
specific part of the packet CS which deals with IPv4 and IPv6.

Also, 16ng has a charter item for IPv4 operation. So we need to specify IPv4 operation in point to point links.

  How are we going to handle this? An easy way would be to add a section to the current draft and change its title a bit. Or we write an entrirely new draft.

  Kind regards,

--behcet

----- Original Message ----
From: Jari Arkko <[email-masked]>
To: Behcet Sarikaya <[email-masked]>
Cc: [email-masked]
Sent: Thursday, December 14, 2006 9:22:38 AM
Subject: Re: [16NG] AD review of draft-ietf-16ng-ipv6-over-ipv6cs

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:
> 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: Daniel Park <[email-masked]>
Date: Fri, 15 Dec 2006 08:29:20 +0900

Behcet, 

As I presented it at the last IETF meeting, I am 
in tne progress of drafting the IPv4CS draft. 
Hopefully it will be ready for further discussion
soon (before IETF-68). 

Now, following the 16ng milestone, we will try
to focus on the IPv6CS deliverable to be ready
for the IESG. 

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.

  ----- Original Message ----- 
  From: Behcet Sarikaya 
  To: Jari Arkko 
  Cc: [email-masked] 
  Sent: Friday, December 15, 2006 5:14 AM
  Subject: Re: [16NG] AD review of draft-ietf-16ng-ipv6-over-ipv6cs

  Hi Jari,

    Kind regards,

  --behcet

  ----- Original Message ----
  From: Jari Arkko <[email-masked]>
  To: Behcet Sarikaya <[email-masked]>
  Cc: [email-masked]
  Sent: Thursday, December 14, 2006 9:22:38 AM
  Subject: Re: [16NG] AD review of draft-ietf-16ng-ipv6-over-ipv6cs

  --Jari

  > >    o  delivering the CS PDU to theappropriate service flow and transport

------------------------------------------------------------------------------