[16NG] Re: 16NG Digest, Vol 6, Issue 16

[" 김상언 " <[e-mail]>]

In RFC3314, section 2.1 describes the limitation of the 3GPP address
assignments.

Think of RFC 3041.

We need a consensus that privacy extension require or not even if p2p subnet
model.

S.E Kim at KT

2007/5/4, [e-mail] <[e-mail]>rg>:
>
> 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. RE:  DAD in IEEE802.16 (Tjandra Paula-CPT015)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 3 May 2007 18:18:38 -0400
> From: "Tjandra Paula-CPT015" <[e-mail]>
> Subject: RE: [16NG] DAD in IEEE802.16
> To: "Behcet Sarikaya" <[e-mail]>rg>,      "gabriel montenegro"
>        <[e-mail]>
> Cc: [e-mail]
> Message-ID:
>        <[e-mail]>
> Content-Type: text/plain; charset="utf-8"
>
> Is it a requirement to assign unique prefix per MS in WiMAX?
> <draft-ietf-16ng-ipv6-over-ipv6cs> seems to imply that it is.
> Assuming that the MS/host has a unique prefix, why would the MS/host need
> to perform DAD?
>
> Regards, Paula.
>
> ________________________________
>
> From: Behcet Sarikaya [mailto:[e-mail]]
> Sent: Thursday, May 03, 2007 4:48 PM
> To: gabriel montenegro
> Cc: [e-mail]
> Subject: Re: [16NG] DAD in IEEE802.16
>
>
> Gabriel,
> Let's take RFC3314. It says:
> DAD is not performed, as the GGSN
>   will not assign the same address to multiple nodes.
>
> So the context is important. Of course I agree with the above sentence,
> but in other contexts, DAD is needed.
>
> Regards,
>
> Behcet
>
> ----- Original Message ----
> From: gabriel montenegro <[e-mail]>
> To: Behcet Sarikaya <[e-mail]>
> Cc: [e-mail]
> Sent: Thursday, May 3, 2007 4:17:37 PM
> Subject: Re: [16NG] DAD in IEEE802.16
>
>
> Behcet said: "I don't think we can say that DAD is not needed."
>
> This is what the documents I refer to below *already* say is fine under
> certain conditions. I believe those same conditions are likely to be
> generally satisfied in
> networks beyond those being explicitly mentioned in those documents (e.g.,
> wimax).
>
> If you want those documents to not say it may be ok to forgo DAD, then
> it's too late for the RFCs, but perhaps you can still argue it for
> the "IP Version 6 over PPP", but better hurry as it is in IESG right now.
> I happen to think that what it says is correct.
>
> -gabriel
>
>
> ----- Original Message ----
> From: Behcet Sarikaya <[e-mail]>
> To: gabriel montenegro <[e-mail]>
> Cc: [e-mail]
> Sent: Thursday, May 3, 2007 11:45:33 AM
> Subject: Re: [16NG] DAD in IEEE802.16
>
>
> Isn't DAD recommended even on p2p links? You are generating an address
> from either your MAC address or using some random numbers, you can not avoid
> a collision 100%. I heard that Vista generates a new IPv6 address every
> hour. I don't think we can say that DAD is not needed.
>
> --behcet
>
>
> ----- Original Message ----
> From: gabriel montenegro <[e-mail]>
> To: Syam Madanapalli <[e-mail]>om>; Frank Xia <
> [e-mail]>
> Cc: [e-mail]
> Sent: Thursday, May 3, 2007 12:00:04 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 <mailto:[e-mail]>
>
>                To: Behcet Sarikaya <mailto:[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]<mailtolto:
> [e-mail]> >
>                        To: Frank Xia <[e-mail]>
>                        Cc: 김상언 < [e-mail] <mailto:
> [e-mail]> >; [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 <mailto:
> [e-mail]>
>                                        To: Frank Xia <mailto:
> [e-mail]>
>                                        Cc: Daniel Park <mailto:
> [e-mail]>  ; 김상언 <mailto:[e-mail]>  ;
> [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] <mailto:[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 <mailto:
> [e-mail]>
>
>                                        To: '源�?곸뼵' <mailto:
> [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] <mailto:[e-mail]> >:
>
>                                        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] <mailto:[e-mail]> >
>                                        Cc: Internet Architecture Board <
> [e-mail]>gt;,  16ng mailing list
>                                               < [e-mail]>gt;, 16ng chair
> < [e-mail] <mailto:[e-mail]> >,
> 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.16network 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
>
>
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> http://www1.ietf.org/pipermail/16ng/attachments/20070503/7f22bf3f/attachment.html
>
> ------------------------------
>
> _______________________________________________
> 16NG mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/16ng
>
>
> End of 16NG Digest, Vol 6, Issue 16
> ***********************************
>

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