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

["Daniel Park" <[e-mail]>]

First off, I'm not sure why your subject is posted on the list tagging Digest.

Anyhow, IPv6CS document already mentioned RFC3041 for private IID
extension and this document is entirely based on P2P subnet model
(assignment of unique prefix for each host).

9.1.  Interface Identifier

   The MS has a 48-bit globally unique MAC address as specified in
   802.16 [802.16].  This MAC address MUST be used to generate the
   modified EUI-64 format-based interface identifier as specified in the
   IP Version 6 Addressing Architecture [RFC4291].  The modified EUI-64
   interface identifier is used in stateless address autoconfiguration.
   As in other links that support IPv6, EUI-64 based interface
   identifiers are not mandatory and other mechanisms, such as random
   interface identifiers, Privacy Extensions for Stateless Address
   Autoconfiguration in IPv6 [RFC3041] MAY also be used.


Anything else ?

-- Daniel Park

On 5/8/07, 김상언 <[e-mail]> wrote:
>
> 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]>gt;; 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]
> <mailto:[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]>rg>,  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 ",
> >
> 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
> >
> >
> >
> > -------------- 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
>
>

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