Hi, Yao.
No, it will not.
Talking about RFC 5095,
it will support in v1.5.0 or v2.0.0 as major revision/version up
because the test specification has not been fixed by IPv6 Ready Logo Program.
Anyway, I also must fix cleanup procedure of v1.5.0b2 as v1.5.0b3.
But v1.5.0b3 will not use for getting LOGO.
Thanks,
On Tue, 29 Jan 2008 17:01:34 -0700
Yinghui Yao <Yinghui.Yao@alcatel-lucent.com> wrote:
> Hi Yukiyo,
>
> Will support for RFC 5095 be included in 1.4.10 as well?
>
> Thanks,
> Yao
>
> Yukiyo Akisada wrote:
> > Hi, Yao.
> >
> > It is still under debuging.
> >
> > This modification will be released as minor revision up.
> > So, it will released as bug fix of v1.4.9.
> > The version will be v1.4.10.
> >
> > It doesn't take a long time.
> > I hope that everything can be done in one week.
> >
> > Please wait for a while.
> >
> > Regards,
> >
> >
> > On Tue, 29 Jan 2008 09:07:09 -0700
> > Yinghui Yao <Yinghui.Yao@alcatel-lucent.com> wrote:
> >
> >
> >> Thanks Yukiyo. When and which version of the software will be updated?
> >>
> >> Regards,
> >> Yinghui Yao
> >> Alcatel-Lucent
> >>
> >> Yukiyo Akisada wrote:
> >>
> >>> Hi, Yao.
> >>>
> >>> The cleanup procedure will be updated.
> >>>
> >>> Because some of current cleanup procedures is not same as the specification.
> >>> We must follow the specification.
> >>>
> >>> Actual specification will take the following.
> >>>
> >>> TN NUT
> >>> | |
> >>> |---> | unsolicited NA (multicast, S=0&O=1, different TLL)
> >>> | |
> >>> |------>| Echo Request
> >>> |<------| Echo Reply
> >>> | |
> >>> * | Wait (DELAY_FIRST_PROBE_TIME)
> >>> | |
> >>> |<------| NS (unicast)
> >>> |<------| NS (unicast)
> >>> |<------| NS (unicast)
> >>> | |
> >>> V V
> >>>
> >>> It will work for everything.
> >>>
> >>> // Personally, I wanted to consider NA is sending a packet.
> >>> // But, specification accepts both. :-)
> >>>
> >>> Thanks,
> >>>
> >>>
> >>> On Mon, 28 Jan 2008 17:03:24 -0700
> >>> Yinghui Yao <Yinghui.Yao@alcatel-lucent.com> wrote:
> >>>
> >>>
> >>>
> >>>> Hi,
> >>>>
> >>>> Has anyone especially TAHI guys ever questioned wisdom behind the
> >>>> sequence that TAHI clears NUT's ND entry
> >>>>
> >>>> TN NUT
> >>>> | |
> >>>> | ----> | NS (unicast) (different cached address)
> >>>> | <---- | NA
> >>>> | |
> >>>> * | Wait (DELAY_FIRST_PROBE_TIME)
> >>>> | |
> >>>> | <---- | NS (unicast)
> >>>> | <---- | NS (unicast)
> >>>> | <---- | NS (unicast)
> >>>> | |
> >>>> V V
> >>>>
> >>>> I understand it's based on RFC 2461 section 7.3.3
> >>>>
> >>>> "The first time a node sends a packet to a neighbor whose entry is
> >>>> STALE, the sender changes the state to DELAY and a sets a timer to
> >>>> expire in DELAY_FIRST_PROBE_TIME seconds."
> >>>>
> >>>> Does "NA packet sent from NUT" count as "sending a packet". I would
> >>>> think "sending a packet"
> >>>> really means sending packets other than ND e.g. ICMP, TCP/UDP packets.
> >>>>
> >>>> Thanks,
> >>>> Yinghui Yao
> >>>> Alcatel-Lucent
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>> ------------------------------------------------------------------------
> >>> Yukiyo Akisada <akisada@tahi.org>
> >>>
> >>>
> >>
> >>
> >
> >
> > ------------------------------------------------------------------------
> > Yukiyo Akisada <akisada@tahi.org>
> >
>
>
------------------------------------------------------------------------
Yukiyo Akisada <akisada@tahi.org>