Subject: [16NG] DAD in IEEE802.16

From: Daniel Park <[email-masked]>
Date: Wed, 02 May 2007 08:39:50 +0900

[Trimming the list and subject]
 
Sangeon, 
 
IPv6 subnet model document was gone. Its status
is in RFC Queue. If you have any concern regarding
IPv6 DAD, it may take place in IPv6CS or EthernetCS
document in my sense. Can you elaborate on your
concern more specific ?
 
-- Daniel Park

  _____  

From: 김상언 [mailto:[email-masked]] 
Sent: Monday, April 30, 2007 11:14 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: 16NG Digest, Vol 5, Issue 22

Hi all,
 
The one of the important thing in IEEE802.16 is missed.
RFC 2462 specifies autoconfiguration in wired-based IPv6 Internet. It did
not specify configuration time.
To use RFC 2462 specfication in IEEE802.16e network, it is required faster
procedure than current DAD procedure.
Has anyone can tell the DAD processing time?
 
If the IEEE 802.16 network will consume more than one seconds to handover
at IP layer, Does it practical?
 
So, I would like to propose to add some technical resolution for section
3.1.3 and 3.3.3.
 
regards,

2007/4/28, [email-masked] <[email-masked]>: 

Send 16NG mailing list submissions to
       [email-masked]

To subscribe or unsubscribe via the World Wide Web, visit 
       https://www1.ietf.org/mailman/listinfo/16ng
or, via email, send a message with subject or body 'help' to
       [email-masked]

You can reach the person managing the list at
       [email-masked]

When replying, please edit your Subject line so it is more specific 
than "Re: Contents of 16NG digest..."

Today's Topics:

  1.  Document Action: 'Analysis of IPv6 Link Models for  802.16
     based Networks' to Informational RFC  (The IESG)

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

Message: 1
Date: Fri, 27 Apr 2007 11:30:34 -0400
From: The IESG <[email-masked]  <mailto:[email-masked]> >
Subject: [16NG] Document Action: 'Analysis of IPv6 Link Models for
       802.16 based Networks' to Informational RFC
To: IETF-Announce <[email-masked]  <mailto:[email-masked]> >
Cc: Internet Architecture Board <[email-masked]>,  16ng mailing list
       <[email-masked]>, 16ng chair <  <mailto:[email-masked]>
[email-masked]>,       RFC Editor
       <[email-masked]>
Message-ID: <  <mailto:[email-masked]> E1HhSP4-
[email-masked]>

The IESG has approved the following document:

- 'Analysis of IPv6 Link Models for 802.16 based Networks '
  <draft-ietf-16ng-ipv6-link-model-analysis-03.txt > as an Informational RFC

This document is the product of the IP over IEEE 802.16 Networks Working
Group.

The IESG contact persons are Jari Arkko and Mark Townsley.

A URL of this Internet-Draft is: 
http://www.ietf.org/internet-drafts/draft-ietf-16ng-ipv6-link-model-
analysis-03.txt

Technical Summary

This document provides different IPv6 link models that are suitable 
for 802.16 based networks and provides analysis of various
considerations for each link model and the applicability of each link
model under different deployment scenarios.

Working Group Summary

This document is result of a Design Team that was formed 
to analyze the IPv6 link models for 802.16 based networks.
Based on the recommendations of the design team and this
document, the working group has chosen the unique-prefix-per-
link/mn model over the previously assumed shared prefix 
model. The new model is in use in the IPv6 over 802.16 IPCS
document (draft-ietf-16ng-ipv6-over-ipv6cs), and has also
been adopted by the Wimax Forum.

Protocol Quality

Jari Arkko has revied this document for the IESG. 

Note to RFC Editor

Please insert "IEEE" in front of references to 802.16
or other IEEE specification numbers throughout the
document, including the title.

Please expand "MS" to "MS (Mobile Station)" on first 
occurence in Section 1. Similarly, expand "BS" to
"BS (Base Station)". And later in the document,
"CS" to "CS (Convergence Sublayer)".

Please expand "MLD" to "MLD (Multicast Listener 
Discovery)" in Section 3.1.3.

Please add the following informative reference:

  [WiMAXArch]
             "WiMAX End-to-End Network Systems Architecture
             http://www.wimaxforum.org/technology/documents",
             August 2006.

and refer to that from Section 1, 2nd paragraph, 1st sentence.

In Section 3.1, change "on per MS basis" to "on a per MS basis". 

Also in Section 3.1, paragraph 1: change "does not any multicast"
to "does not provide any multicast". And change "illustrates high"
to "illustrate a". Finally, change "one more" to "one or more". 

Change the section titles (3 instances) that say "Reuse of
Existing Standards" to "Reuse of Existing Specifications".

Replace the text in the Security Considerations section
with the following: 

   This document provides the analysis of various IPv6 link models for
   IEEE 802.16 based networks and this document as such does not
   introduce any new security threats. No matter what the link model
   is, the networks employ the same link-layer security mechanisms
   defined in [5]. However, the chosen link model affects the scope
   of link local communication, and this may have security implications
   for protocols that are designed to work within the link scope. This 
   is the concern for shared link model compared other models wherein
   private resources e.g. personal printer cannot be put onto a public
   WiMAX network. This may restrict the usage of shared prefix model
   to enterprise environments.

   The Neighbor Discovery related security issues are document in [RFC

   2461] [RFC 2462] and these are applicable for all the models
   described in this documents. The model specific security 
   considerations are documented in their respective protocol
   specifications.

Place a new top-level section between Sections 5 and 6:

   X. Effect on Routing

   The model used for in a 802.16 network may have a significant
   impact on how routing protocols are run over such a network.
   The deployment model presented in this document discusses the
   least impacting model on routing as connectivity on the provider 
   edge is intentionally limited to point to point connectivity
   from one BS to any one of multiple MSs. Any other deployment
   model may cause a significant impact on routing protocols,
   however, but they are outside the scope of this document. 

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

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

End of 16NG Digest, Vol 5, Issue 22
***********************************

-- 
------------------------------------------------ 
Sang-Eon Kim
Senior Researcher
Infra. Lab., KT
139-791, Woomyeon-dong, Seocho-gu, Seoul, Korea

Voice: +82-2-526-6117
Mobile: +82-10-3073-4084
E-mail: [email-masked]  <mailto:[email-masked]> 
------------------------------------------------ 

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

---

From: Frank Xia <[email-masked]>
Date: Wed, 02 May 2007 11:23:24 -0500

Hi Deniel and Sangeon

A  solution is proposed in the END draft and it applies to p2p link model as well.

http://tools.ietf.org/wg/16ng/draft-xia-16ng-end-01.txt

Comments are welcomed.

BR
Frank

  ----- Original Message ----- 
  From: Daniel Park 
  To: '김상언' ; [email-masked] 
  Sent: Tuesday, May 01, 2007 6:39 PM
  Subject: [16NG] DAD in IEEE802.16

  Sangeon, 

  -- Daniel Park

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

    Hi all,

    The one of the important thing in IEEE802.16 is missed.
    RFC 2462 specifies autoconfiguration in wired-based IPv6 Internet. It did not specify configuration time.
    To use RFC 2462 specfication in IEEE802.16e network, it is required faster procedure than current DAD procedure.
    Has anyone can tell the DAD processing time?

    If the IEEE 802.16 network will consume more than one seconds to handover at IP layer, Does it practical?

    So, I would like to propose to add some technical resolution for section 3.1.3 and 3.3.3.

    regards,

      Today's Topics:

      Message: 1
      Date: Fri, 27 Apr 2007 11:30:34 -0400
      From: The IESG <[email-masked] >
      Subject: [16NG] Document Action: 'Analysis of IPv6 Link Models for
             802.16 based Networks' to Informational RFC
      To: IETF-Announce <[email-masked] >
      Cc: Internet Architecture Board <[email-masked]>,  16ng mailing list
             <[email-masked]>, 16ng chair < [email-masked]>,       RFC Editor
             <[email-masked]>
      Message-ID: < [email-masked]>

      A URL of this Internet-Draft is: 
      http://www.ietf.org/internet-drafts/draft-ietf-16ng-ipv6-link-model-analysis-03.txt

      Technical Summary

      Working Group Summary

      Protocol Quality

      Note to RFC Editor

        [WiMAXArch]

         X. Effect on Routing

    Voice: +82-2-526-6117
    Mobile: +82-10-3073-4084
    E-mail: [email-masked] 
    ------------------------------------------------ 

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

---

From: "Syam Madanapalli" <[email-masked]>
Date: Wed, 2 May 2007 22:52:05 +0530

Hi Frank and Sangeon,

How about using Optimistic DAD (RFC 4429) to minimize the delay?

Thanks,
Syam

On 5/2/07, Frank Xia <[email-masked]> wrote:
> *From:* Daniel Park <[email-masked]>
> *To:* '김상언' <[email-masked]> ; [email-masked]
> *Sent:* Tuesday, May 01, 2007 6:39 PM
> *Subject:* [16NG] DAD in IEEE802.16
>
>
> *From:* 김상언 [mailto:[email-masked]]
> *Sent:* Monday, April 30, 2007 11:14 PM
> *To:* [email-masked]
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: 16NG Digest, Vol 5, Issue 22
>
>
>  Hi all,
>
> To use RFC 2462 specfication in IEEE802.16e network, it is
> required faster procedure than current DAD procedure.

---

From: Frank Xia <[email-masked]>
Date: Wed, 02 May 2007 12:43:41 -0500

Hi Syam

END can work together with  Optimistic DAD, and some of the description in our draft is
" If END and [OPTDAD] are enabled, the SS will benefit from both the
   reliability and time advantages.
"

Any way , there are some constraints for Optimistic DAD, 
please refer to the words form RFC4429:
  * Optimistic DAD SHOULD only be used when the implementation is aware
        that the address is based on a most likely unique interface
        identifier (such as in [RFC2464]), generated randomly [RFC3041],
        or by a well-distributed hash function [RFC3972] or assigned by
        Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315].
        Optimistic DAD SHOULD NOT be used for manually entered
        addresses."

BR
Frank
  ----- Original Message ----- 
  From: Syam Madanapalli 
  To: Frank Xia 
  Cc: Daniel Park ; ���� ; [email-masked] 
  Sent: Wednesday, May 02, 2007 12:22 PM
  Subject: Re: [16NG] DAD in IEEE802.16

  Hi Frank and Sangeon,

  Thanks,
  Syam

    Comments are welcomed.

    BR
    Frank

      ----- Original Message ----- 
      From: Daniel Park 
      To: '김?�언' ; [email-masked] 
      Sent: Tuesday, May 01, 2007 6:39 PM
      Subject: [16NG] DAD in IEEE802.16

      Sangeon, 

      -- Daniel Park

------------------------------------------------------------------------
        From: 김?�언 [mailto:[email-masked]] 
        Sent: Monday, April 30, 2007 11:14 PM 
        To: [email-masked]
        Cc: [email-masked]; [email-masked]
        Subject: Re: 16NG Digest, Vol 5, Issue 22

        Hi all,

        regards,

        2007/4/28, [email-masked] < [email-masked]>: 
          Send 16NG mailing list submissions to
                 [email-masked]

          Today's Topics:

          Message: 1
          Date: Fri, 27 Apr 2007 11:30:34 -0400
          From: The IESG < [email-masked] >
          Subject: [16NG] Document Action: 'Analysis of IPv6 Link Models for
                 802.16 based Networks' to Informational RFC
          To: IETF-Announce < [email-masked] >
          Cc: Internet Architecture Board <[email-masked]>,  16ng mailing list
                 < [email-masked]>, 16ng chair < [email-masked]>,       RFC Editor
                 <[email-masked]>
          Message-ID: < [email-masked]>

          Technical Summary

          Working Group Summary

          Protocol Quality

          Note to RFC Editor

            [WiMAXArch]

             X. Effect on Routing

        Voice: +82-2-526-6117
        Mobile: +82-10-3073-4084

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

---

From: "Syam Madanapalli" <[email-masked]>
Date: Wed, 2 May 2007 23:32:35 +0530

Hi Frank,

I understand the proposed END mechanism is more deterministic, however it
comes at
a cost: router modification and availability of authoritative address cache.

And personally I do not like the RA as a response to DAD NS to tell the host
that
the address is unique, and at NA cannot be used as it will not be
interoperable with
unmodified hosts which will treat that the address is duplicate.

IEEE 802.16 based hosts would have the unique MAC address, so ODAD would
work well I think.

Thanks,
Syam

On 5/2/07, Frank Xia <[email-masked]> wrote:
> *From:* Syam Madanapalli <[email-masked]>
> *To:* Frank Xia <[email-masked]>
> *Cc:* Daniel Park <[email-masked]> ; 김상언 <[email-masked]>;
> [email-masked]
> *Sent:* Wednesday, May 02, 2007 12:22 PM
> *Subject:* Re: [16NG] DAD in IEEE802.16
>
>
>
> Hi Frank and Sangeon,
>
> > <http://tools.ietf.org/wg/16ng/draft-xia-16ng-end-01.txt+>
> >
> > Comments are welcomed.
> >
> > BR
> > Frank
> >
> >
> >
> >
> >
> > *To:* '源�?곸뼵' <[email-masked]> ; [email-masked]
> > *From:* 源�?곸뼵 [mailto:[email-masked]]

---

From: Frank Xia <[email-masked]>
Date: Wed, 02 May 2007 13:27:35 -0500

Hi Syam

please see my inline comments.

BR
Frank

  ----- Original Message ----- 
  From: Syam Madanapalli 
  To: Frank Xia 
  Cc: Daniel Park ; 김상언 ; [email-masked] 
  Sent: Wednesday, May 02, 2007 1:02 PM
  Subject: Re: [16NG] DAD in IEEE802.16

  Hi Frank,

  I understand the proposed END mechanism is more deterministic, however it comes at
  a cost: router modification and availability of authoritative address cache.
  Frank=>AR in 802.16 networks has an authoritative address cache, especially in P-to-P link model.

  And personally I do not like the RA as a response to DAD NS to tell the host that 
  the address is unique, and at NA cannot be used as it will not be interoperable with
  unmodified hosts which will treat that the address is duplicate.

  Frank => END is an Enhancement of ND. So it can be interoperable with unmodified hosts. 
  Unmodified hosts just ignor the option carried by RA (NOT NA).
  It is full compatible with RFC2461.

  IEEE 802.16 based hosts would have the unique MAC address, so ODAD would
  work well I think.
  Frank=>Some IPv6 address formulation is not related to MAC address.
  It is not reasonable to bind IPv6 address with MAC address.

  Thanks,
  Syam

     
    BR
    Frank
      ----- Original Message ----- 
      From: Syam Madanapalli 
      To: Frank Xia 
      Cc: Daniel Park ; 김상언 ; [email-masked] 
      Sent: Wednesday, May 02, 2007 12:22 PM
      Subject: Re: [16NG] DAD in IEEE802.16

      Hi Frank and Sangeon,

      Thanks,
      Syam

      On 5/2/07, Frank Xia <[email-masked] > wrote: 
        Hi Deniel and Sangeon

        Comments are welcomed.

        BR
        Frank

          ----- Original Message ----- 
          From: Daniel Park 
          To: '源�?곸뼵' ; [email-masked] 
          Sent: Tuesday, May 01, 2007 6:39 PM
          Subject: [16NG] DAD in IEEE802.16

          Sangeon, 

          -- Daniel Park

--------------------------------------------------------------------
            From: 源�?곸뼵 [mailto:[email-masked]] 

             
            Hi all,

            regards,

              Today's Topics:

              Message: 1

              Technical Summary

              Working Group Summary

              Protocol Quality

              Note to RFC Editor

                [WiMAXArch]

                 X. Effect on Routing

            Voice: +82-2-526-6117
            Mobile: +82-10-3073-4084