Re: [16NG] DAD in IEEE802.16

[Frank Xia <[e-mail]>]

Hi Gabiel and Syam

I am also not sure if it make sense to consider END.
Just as you know, I did not push the issue.

But I really don't think it is  "such a minor issue".
Just as the material you listed, there are some adaptation in different scenarios.

There were some also some discussion in 16NG mailing list.


BR
Frank




  ----- Original Message ----- 
  From: gabriel montenegro 
  To: Syam Madanapalli ; Frank Xia 
  Cc: [e-mail] 
  Sent: Thursday, May 03, 2007 12:00 PM
  Subject: Re: [16NG] DAD in IEEE802.16


  I really don't think it makes sense to consider END, a non-standard, for such a minor issue, which might actually be a non-issue.
  DAD itself may not be even needed, as mentioned by Syam already. This point is mentioned informationally in the DAD discussions in:

      Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards    
      http://tools.ietf.org/html/rfc3314

      Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts
      http://tools.ietf.org/html/rfc3316  

  and normatively in section 5 of:

    IP Version 6 over PPP
      http://tools.ietf.org/html/draft-ietf-ipv6-over-ppp-v2-02

  which is currently in IESG processing. Even though the above docs don't spell out w-i-m-a-x, the link characteristics from the point of addressing are
  similar enough that the same considerations can apply.

  -gabriel


  ----- Original Message ----
  From: Syam Madanapalli <[e-mail]>
  To: Frank Xia <[e-mail]>
  Cc: [e-mail]
  Sent: Thursday, May 3, 2007 8:38:59 AM
  Subject: Re: [16NG] DAD in IEEE802.16


  Hi Frank,


  On 5/3/07, Frank Xia <[e-mail]> wrote: 
     
    Hi Syam

    Even in ODAD, there is a normal DAD procedure in parallel.
    END is to improve normal DAD, not ODAD.
    END can co-work with ODAD well.


  I see no reason to use ODAD along with END.
  END might have had better position if it were proposed
  before ODAD :-)
   



    Any way, just as you said, is it useful enough to modify the router?


  Yep, if we can answer this, then we will be in better position to support this proposal.



    I don't know, but I think that any feasible improvement can be considered.


  I agree.

  Thanks,
  Syam



    BR
    Frank
      ----- Original Message ----- 
      From: Syam Madanapalli 
      To: Behcet Sarikaya 
      Cc: [e-mail] 
      Sent: Thursday, May 03, 2007 2:18 AM
      Subject: Re: [16NG] DAD in IEEE802.16

       
      Hi Bachet,

      Doing things deterministically is always good.
      But here I am wondering if it is worth the implementation changes on the routers as well as on hosts,
      especially on p2p links where the chance of collission is very very remote as the p2p link will be
      using just two addresses out of 2 ^64.

      Assign unique prefix using prefix delegation for each host or  configuring the router not to
      construct the IPv6 address using the advertised prefix in case the router advertises the prefix
      along with the ODAD may solve the problem completely, I think.


      Thanks,
      Syam

       
      On 5/3/07, Behcet Sarikaya <[e-mail] > wrote: 
        Syam, isn't it better to make it deterministic in p2p links where you have an authoritative address cache?

        --behcet

         
        ----- Original Message ----
        From: Syam Madanapalli < [e-mail]>
        To: Frank Xia <[e-mail]>
        Cc: 김상언 < [e-mail]>gt;; [e-mail]
        Sent: Wednesday, May 2, 2007 1:02:35 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.

        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 <[e-mail] > wrote: 
          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 ; 김상언 ; [e-mail] 
            Sent: Wednesday, May 02, 2007 12:22 PM
            Subject: Re: [16NG] DAD in IEEE802.16

             

            Hi Frank and Sangeon,

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

            Thanks,
            Syam

             
            On 5/2/07, Frank Xia < [e-mail] > wrote: 
              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: '源�?곸뼵' ; [e-mail] 
                Sent: Tuesday, May 01, 2007 6:39 PM
                Subject: [16NG] DAD in IEEE802.16

                 
                [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:[e-mail]] 

                  Sent: Monday, April 30, 2007 11:14 PM 
                  To: [e-mail] 
                  Cc: [e-mail]; [e-mail]
                  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, [e-mail] < [e-mail]>gt;: 
                    Send 16NG mailing list submissions to
                           [e-mail]

                    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
                           [e-mail] 

                    You can reach the person managing the list at
                           [e-mail] 

                    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 < [e-mail] >
                    Subject: [16NG] Document Action: 'Analysis of IPv6 Link Models for 
                           802.16 based Networks' to Informational RFC
                    To: IETF-Announce < [e-mail] >
                    Cc: Internet Architecture Board <[e-mail]>rg>,  16ng mailing list
                           < [e-mail]>gt;, 16ng chair < [e-mail]>gt;,       RFC Editor 
                           <[e-mail]>
                    Message-ID: < [e-mail]>

                    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"quot;,
                                 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
                    [e-mail]
                    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: [phone]
                  Mobile: [phone]
                  E-mail: [e-mail] 
                  ------------------------------------------------ 


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









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






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

         




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




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

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