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

From: Behcet Sarikaya <[email-masked]>
Date: Sat, 16 Dec 2006 09:22:43 -0800 (PST)

It is rather strange but the urgency is v4 draft for Release 1 is much more than v6 draft because v6 operation is optional and I guess you have to have something, i.e. at least v4. 
Lost in procedures.

Kind regards,

--behcet

----- Original Message ----
From: Daniel Park <[email-masked]>
To: Behcet Sarikaya <[email-masked]>; Jari Arkko <[email-masked]>
Cc: [email-masked]
Sent: Thursday, December 14, 2006 5:29:20 PM
Subject: Re: [16NG] AD review of draft-ietf-16ng-ipv6-over-ipv6cs

DIV {
MARGIN:0px;}

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

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