Re: [16NG] ipv6 over ipv6cs document approval

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

ND just runs normally on IPv6CS, similar to any p2p link.

-Syam

On Nov 23, 2007 3:25 PM, Junghoon Jee <[e-mail]> wrote:
> Hi Raj,
>
> >One of the reasons for choosing a PtP link model is to avoid the issues
> related to ND.
>
> Multilink subnet issues are the main reason of that.
>
> >Because of the PtP link type there is no question about an MS being
> transitioned out of Idle mode because of ND.
>
> So, we should not send neighbor discovery packets in case of the IPv6CS?
>
> >The document does not need to specify anything further regarding ND.
>
> Junghoon
>
> 2007/11/23, Basavaraj Patil <[e-mail]>:
>
> >
> >
> > One of the reasons for choosing a PtP link model is to avoid the issues
> related to ND.
> > Because of the PtP link type there is no question about an MS being
> transitioned out of Idle mode because of ND.
> > The document does not need to specify anything further regarding ND.
> >
> > -Raj
> >
> >
> >
> > On 11/22/07 3:01 AM, "ext Junghoon Jee" < [e-mail]> wrote:
> >
> >
> >
> > Hi Jari,
> >
> > I agree to apply the suggested changes.
> >
> > Let me share my unsolved question regarding how to deal with neighbor
> discovery packets for IPv6CS case.
> >
> > Do we have to block neighbor discovery packets not to wake up idle/sleep
> SSs ? Or,
> > Do we have to let them delivered in that p2p link not to break the NUD
> model?
> > Is there no need to specify about that in this document?
> >
> > BR,
> > Junghoon
> >
> >
> > 2007/11/22, Jari Arkko <[e-mail]>:
> >
> >
> >
> > We're trying to close the remaining issues and approve
> > the current document.
> >
> > The current proposal is what we have in the draft, with
> > the following changes. If there is any concern with
> > these changes, let me know as soon as possible.
> >
> > There are a few editorial changes. The substantive
> > changes are clarifying MTU rules in the presence
> > of tunneling on the BS side, and strengthening
> > the requirements related to interoperability.
> >
> > ----
> >
> > Please change in Section 8.1:
> >
> > OLD:
> >    The use of router advertisements as a means for movement detection is
> >    not recommended for MNs connected via 802.16 links as the frequency
> >    of periodic router advertisements can be high.
> > NEW:
> >    The use of router advertisements as a means for movement detection is
> >    not recommended for MNs connected via 802.16 links as the frequency
> >    of periodic router advertisements would have to be high.
> >
> > Please add new text at the end of Section 4 (just before 4.1),
> > these are the new paragraphs:
> >
> >    In any case, the MS and BS MUST negotiate at most one
> >    convergence sublayer for IPv6 transport on a given link.
> >
> >    In addition, to ensure interoperability between devices that
> >    support different encapsulations, it is REQUIRED that BS
> >    implementations support all standards track encapsulations
> >    defined for 802.16 by the IETF. At the time of writing this
> >    specification, this is the only encapsulation, but additional
> >    specifications are being worked on. It is, however, not
> >    required that the BS implementations use all the encapsulations
> >    they support; some modes of operation may be off by
> >    configuration.
> >
> > Change in Appendix D:
> >
> > OLD:
> >    It is
> >    recommended that the default MTU for IPv6 be set to 1400 octets for
> >    the MS in WiMAX networks.
> > NEW:
> >    It is recommended that the MTU for IPv6 be set to 1400 octets in
> >    WiMAX networks, and this value (different from the default)
> >    be communicated to the MS.
> >
> > Change Section 6.3 to:
> >
> >   The MTU value for IPv6 packets on an 802.16 link is configurable.
> >   The default MTU for IPv6 packets over an 802.16 link SHOULD be 1500
> >   octets.
> >
> >   The 802.16 MAC PDU (Protocol Data Unit) is composed of a 6 byte
> >   header followed by an optional payload and an optional CRC covering
> >   the header and the payload.  The length of the PDU is indicated by
> >   the Len parameter in the Generic MAC Header.  The Len parameter has a
> >   size of 11 bits.  Hence the total MAC PDU size is 2048 bytes.  The
> >   IPv6 payload size can vary.  In certain deployment scenarios the MTU
> >   value can be greater than the default.  Neighbor Discovery for IPv6
> >   [RFC4861] defines an MTU option that an AR MUST advertise, via router
> >   advertisement (RA) if a value different from 1500 is used.
> >   If an AR advertises an
> >   MTU via the RA MTU option, the MN SHOULD use the MTU from the RA.
> >   Nodes that implement Path MTU discovery [RFC1981] MAY use the
> >   mechanism to determine the MTU for the IPv6 packets.
> >
> > In the abstract:
> >    s/fxed/fixed/
> >
> > In section 6.1:
> >    s/it is recommended that a tunnel is established/it is recommended
> >    that a tunnel be established/
> >
> >
> >
> > _______________________________________________
> > 16NG mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/16ng  <
> 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