I agree that the issues mentioned in the draft
draft-madanapalli-ipv6-periodic-rtr-advts-00.txt
should not be blocking 2461bis, and should be moved forward.
But I think the draft is applicable for certain category of networks
(Cellular Networks) so it may not be a good idea to put the same
inform
ate in PD in the diagram I included? Is there a
description of the scenario I can read?
- Ralph
On Aug 23, 2006, at 1:14 PM, Syam Madanapalli wrote:
> Hello Ralph,
>
> On 8/23/06, Ralph Droms <[EMAIL PROTECTED]> wrote:
>> Questions in line...
>>
>> - Ralph
>>
&
On 8/23/06, Jari Arkko <[EMAIL PROTECTED]> wrote:
>> Also, the subnet model that NetLMM WG wants to choose is to have
>> a unique prefix for each MN.
>
Having a unique prefix for each MN is not the same as a
requirement to perform prefix delegation.
I am not sure if there is any difference as
Hello Ralph,
On 8/23/06, Ralph Droms <[EMAIL PROTECTED]> wrote:
Questions in line...
- Ralph
On Aug 23, 2006, at 3:54 AM, Syam Madanapalli wrote:
> Hi,
>
> On 8/23/06, Ole Troan <[EMAIL PROTECTED]> wrote:
>> I don't understand the rationale for this work eit
Hi,
On 8/23/06, Ole Troan <[EMAIL PROTECTED]> wrote:
I don't understand the rationale for this work either.
the first PD proposal (by Brian Haberman) was indeed based on using
ICMP as transport. separate message types instead of
piggy-backing on RS/RA though. as we continued to develop that
mec
A new draft has been published for prefix delegation using ICMPv6.
http://www.ietf.org/internet-drafts/draft-rao-ipv6-prefix-delegation-00.txt
Please review and provide comments/suggestions.
Thanks,
Syam
IETF IPv6 working grou
the expiry of the default router lifetime tigger
the DNA? Is it specified in the DNA Spec?
Thanks,
Syam
On 8/11/06, Syam Madanapalli <[EMAIL PROTECTED]> wrote:
Hello Erik,
On 8/11/06, Erik Nordmark <[EMAIL PROTECTED]> wrote:
> Syam Madanapalli wrote:
>
> > I am not sur
Hello Erik,
On 8/11/06, Erik Nordmark <[EMAIL PROTECTED]> wrote:
Syam Madanapalli wrote:
> I am not sure if this works.
> Let us say the router lifetime is X seconds
> and the host wakes up every Y seconds to retrieve
> any packets from the AP/BS.
> If Y > X then we are
Hello Erik,
-Original Message-
From: Erik Nordmark [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 09, 2006 12:31 PM
To: Syam Madanapalli
Cc: Francis Dupont; ipv6@ietf.org
Subject: Re: Proposal to change aspects of Neighbor Discovery
Syam Madanapalli wrote:
eady dealing with dormant
On 8/8/06, Francis Dupont <[EMAIL PROTECTED]> wrote:
In your previous mail you wrote:
On 8/8/06, Francis Dupont <[EMAIL PROTECTED]> wrote:
> In your previous mail you wrote:
>
> The I-D:
> draft-madanapalli-ipv6-periodic-rtr-advts-00.txt
> proposes several changes to ND proce
On 8/8/06, Francis Dupont <[EMAIL PROTECTED]> wrote:
In your previous mail you wrote:
The I-D:
draft-madanapalli-ipv6-periodic-rtr-advts-00.txt
proposes several changes to ND procedures and parameters.
=> I strongly object not about the document itself but about its
principle because IMH
802.16 is point-to-multipoint connection oriented technology. There
will be a seperate connection for each subscriber station from base station.
A subsriber station cannot establish a direct connection to another subscriber
station. The 802.16 connection just covers the last mile. So I am not sure
On 5/3/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Hi Bob,
>> How important is this? I didn't make the meeting at the last IETF
>> meeting, but in Vancouver, it didn't seem like they were planning any
>> big work items.
>
>It's another IPv6 over effort. What makes this one more
>complica
>
> There was also some question in the past of what to do when the M and
> O bits *change* between router advertisements. I can't remember who
> brought it up. I don't recall seeing any resolution to this.
> While secure RA sounds really neat, I suspect it will not be widely
> usable on netwo
>
> > I choose not to try to get to the mic, but on the debated
> > requirement point
> > 3; why is there a belief that the DHCP relay information is correctly
> > configured if the simpler set of 2 bits is improperly configured?
>
> I think a case can be made for the notion that most routers and
The flags are just hints, the host can always ignore
them. If it is inappropriate to try to use DHCP when flags
are zero, let it be so. Similarly if the flag(s) is (are) set,
the host can always ignore.
Otherwise we need to say that the M/O flags are triggers
of DHCP. So we need to agree if the
Hi,
We tried to summarize the discussion on M/O flags, but we (authors of
the M/O flags) were busy with other things, so we could not do that. But
from the discussion we found three different opinions
1. Leave M/O Flags unchanged
2. Flags independently represent DHCPv6 and DHCP lite (M-flag for
Isn't it such a long idscussion a proof for the confusion in
understanding the M/O
bits? Instead of leaving the discussion here, thinking that there is
no confusion or
be fore taking any radical changes (either discarding M or O or both flags, or
making changes to the DHCPv6 protocols), it is bett
On 5/21/05, Ralph Droms <[EMAIL PROTECTED]> wrote:
> Well...DHCPv6 doesn't have any better mechanism for announcing
> availability of a server than does DHCPv4 (which is to say "none").
> There has not been an identified need to push an announcement of DHCP
> server availability out to clients.
>
>
On 5/20/05, Soliman, Hesham <[EMAIL PROTECTED]> wrote:
>
> > > This proposal looks better and easy to understand. However,
> > > if we just rely on timeout for concluding the
> > unavailabiliy of DHCP server,
> > > how does the client re-invoke DHCP if the DHCP server is
> > available later i
This proposal looks better and easy to understand. However,
if we just rely on timeout for concluding the unavailabiliy of DHCP server,
how does the client re-invoke DHCP if the DHCP server is available later in
time? I think we need one bit to inform the clients about the
availabilty of DHCP
serv
On 5/18/05, Thomas Narten <[EMAIL PROTECTED]> wrote:
Let me just start off by saying I pretty much agree completely with
what Bernie just said.
Even I do agrre, what Bernie said. I understodd from his mail, a node can
fall back to Information Configuration Behavior (DHCPv6 Lite) if ti fails do
Fu
Hi Jinmei,
I am wondering whether you are talking about the duplicate address (/128) or
duplicate prefix. Let us say, you have an address configured using DHCP
with differe IID and if you are using SLAAC using differe IID but same
prefix; is this okay?
-Syam
- Original Message -
From:
> >> I disagree with the interpretation of M=0.
> >>
> >> M has no impact on stateless autoconf. The existence
> >> of prefixes in the RA marked as "autoconf from this
> >> prefix" controls stateless autoconf. If M=0 and no
> >> prefixes are advertised as autoconf-able, the host
> >> has no asser
Hi Ralph,
- Original Message -
From: "Ralph Droms" <[EMAIL PROTECTED]>
To: "Fred Templin" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; "Stig Venaas" <[EMAIL PROTECTED]>
Sent: Wednesday, August 25, 2004 6:56 PM
Subject: Re: Stateful != M , Stateless != O
> I disagree with the interpretat
Hi Jinmei,
>
> I don't mind adding the appendix as long we just describe possible
> issues (if any) and do NOT try to provide workaround like combining
> router/parameters.
That looks fine, we will just describe the issues and leave the
implementation
details to the developers.
>
> JINMEI, Tat
Hi Greg,
- Original Message -
From: "Greg Daley" <[EMAIL PROTECTED]>
To: "Syam Madanapalli" <[EMAIL PROTECTED]>
Cc: "Pekka Savola" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Soohong Daniel
Park" <[EMAIL PROTECTED]>; &
> > Sorry, it doesn't clearly answer my question. So can I rephrase your
> > statement to "3736 is an implementation hint for DHCPv6 servers and
> > relays, not clients."?
> >
>
> Oh, sorry for the confusion.
>
> Yes I believe so.
That means there will not be any DHCPv6 Client that just implement
- Original Message -
From: "Pekka Savola" <[EMAIL PROTECTED]>
To: "Syam Madanapalli" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; "Soohong Daniel Park"
<[EMAIL PROTECTED]>
Sent: Wednesday, August 11, 2004 2:
- Original Message -
From: )>
To: "Pekka Savola" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; "Soohong Daniel Park" <[EMAIL PROTECTED]>
Sent: Tuesday, August 10, 2004 4:58 PM
Subject: Re: comments on draft-daniel-ipv6-ra-mo-flags-00.txt
> Thanks for the comments.
>
> > On Mon, 9 Aug
30 matches
Mail list logo
