Re: [16NG] DAD in IEEE802.16

["Syam Madanapalli" <[e-mail]>]

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 <[e-mail]>
>  *To:* Behcet Sarikaya <[e-mail]>
> *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 <[e-mail]>
> > > *To:* Frank Xia <[e-mail]>
> > > *Cc:* Daniel Park <[e-mail]> ; 김상언<[e-mail]>om>;
> > > [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
> > > > <http://tools.ietf.org/wg/16ng/draft-xia-16ng-end-01.txt+>
> > > >
> > > > Comments are welcomed.
> > > >
> > > > BR
> > > > Frank
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >  ----- Original Message -----
> > > > *From:* Daniel Park <[e-mail]>
> > > > *To:* '源�?곸뼵' <[e-mail]> ; [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