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

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

 Section 9.2 in <draft-ietf-16ng-ipv6-over-ipv6cs-09> states that "it may be
redundant to perform DAD on a global unicast address that is configured
using the EUI-64 or generated as per
RFC3041<http://tools.ietf.org/html/rfc3041>[
RFC3041 <http://tools.ietf.org/html/rfc3041>] for the interface as part of
the IPv6 stateless address autoconfiguration protocol"

I think that DAD is not redundant but necessary for randomly generated IID
on per-MS prefix.

What do you think about it?

S.E Kim at KT

2007/5/8, Daniel Park <[e-mail]>om>:
>
> 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
> > >
> > ***********************************
>

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