Re: [16NG] ipv6 over ipv6cs document approval

["Junghoon Jee" <[e-mail]>]

Yes, the major problem comes from the periodic RA.

I was thinking about the case when AR sends neighbor discovery packets to
the SS which is in the sleep/idle state.
The AR's sending the unsolicited NAs to SS can be a case for that which is
described in the section 7.2.6 of RFC 4861.

Maybe we need not allow that optional behavior in the case of IPv6CS?

Junghoon

2007/11/23, Syam Madanapalli <[e-mail]>:

> Hi Junghoon,
>
> On the IPv6 CS link, there will be two nodes: MS and AR.
> ND packets from one MS will never reach other MS.
> Problem may arise from periodic RAs, which may require
> increasing the periodic RA interval.
>
> Thanks,
> Syam
>
>
>
> On Nov 23, 2007 5:35 PM, Junghoon Jee <[e-mail]> wrote:
> > Hi Syam,
> >
> > Then, what can we do not to wake up the idle/sleep SSs?
> >
> > Junghoon
> >
> >
> > 2007/11/23, 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