Hi Tony, thanks for your reply (and for reading the draft as well). Please see
my in-line comments:
>From: Tony Hain <[EMAIL PROTECTED]>
>Date: 2006/08/23 Wed PM 01:03:47 CDT
>To: [EMAIL PROTECTED], 'Ralph Droms' <[EMAIL PROTECTED]>
>Cc: "'Durand, Alain'" <[EMAIL PROTECTED]>,
'IETF IPv6
Tim,
I took a look at the I-D and it reads well. I see that you
(and the co-authors) are asking RSs to carry PIOs by way of
requesting specific prefixes, and that you are asking for new
flag bits (the 'P' bit in the RS message 'Reserved' field and
the 'D' bit in the PIO 'Reserved1' field) which wo
Rao Satyanarayana wrote:
> ...
> What we would like to know now is are there any bugs in the proposal
> being specified?
Routers do not currently *send* RS messages.
Bug == "ICMPv6 is an integral part of the IPv6 stack and
hence the proposed mechanism for Prefix Delegation does not require
>From: Ralph Droms <[EMAIL PROTECTED]>
>Date: 2006/08/23 Wed AM 06:23:39 CDT
>To: "<[EMAIL PROTECTED]>" <[EMAIL PROTECTED]>
>Cc: "Durand, Alain" <[EMAIL PROTECTED]>,
Syam Madanapalli <[EMAIL PROTECTED]>,
IETF IPv6 Mailing List
>Subject: Re: Prefix Delegation using ICMPv6
>Some m
>From: Ralph Droms <[EMAIL PROTECTED]>
>Date: 2006/08/23 Wed AM 05:43:09 CDT
>To: "<[EMAIL PROTECTED]>" <[EMAIL PROTECTED]>
>Cc: "Durand, Alain" <[EMAIL PROTECTED]>,
Syam Madanapalli <[EMAIL PROTECTED]>,
IETF IPv6 Mailing List
>Subject: Re: Prefix Delegation using ICMPv6
>Tim -
>From: Rao Satyanarayana-W60007 <[EMAIL PROTECTED]>
>Date: 2006/08/23 Wed PM 05:54:07 CDT
>To: Ralph Droms <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
>Cc: "Durand, Alain" <[EMAIL PROTECTED]>,
IETF IPv6 Mailing List
>Subject: RE: Prefix Delegation using ICMPv6
Satya,
You put this so much bet
>From: Jari Arkko <[EMAIL PROTECTED]>
>Date: 2006/08/23 Wed AM 07:24:59 CDT
>To: [EMAIL PROTECTED]
>Cc: Ralph Droms <[EMAIL PROTECTED]>, IETF IPv6 Mailing List
>Subject: Re: Prefix Delegation using ICMPv6
>Tim,
>
>>Given that there is a historical precedent for being able to do something via
>>m
Ralph,
Implementation and test effort is always there whether it is a existing
protocol or a new protocol to catch implementation specific bugs. Even
if one licenses a particular implementation, there is always testing
involved though the effort can be less focused on testing the licensed
component
Tim - The answer to your exact question is, of course, yes. But, in
my opinion, that question is not the right starting point for our
conversation.
A better question to start with, which we certainly ought to ask as
members of an engineering organization like the IETF, is: "Is there a
su
>From: Ole Troan <[EMAIL PROTECTED]>
>Date: 2006/08/23 Wed AM 12:57:16 CDT
>To: Syam Madanapalli <[EMAIL PROTECTED]>
>Cc: IETF IPv6 Mailing List
>Subject: Re: Prefix Delegation using ICMPv6
>I don't understand the rationale for this work either.
Hi Ole, thanks for the reply. Sorry it took me so
Hi Brian,
Thanks also for replying; my apologies for my tardy response:
>From: Brian E Carpenter <[EMAIL PROTECTED]>
>Date: 2006/08/23 Wed AM 03:09:42 CDT
>To: [EMAIL PROTECTED]
>Cc: "Durand, Alain" <[EMAIL PROTECTED]>,
Syam Madanapalli <[EMAIL PROTECTED]>,
IETF IPv6 Mailing Lis
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
I think another point is that if they're concerned about having to run a
separate DHCPv6 client "process" to handle PD (as was I think discussed
in an earlier email), there's nothing in the DHCPv6 specification that
says you can not implement DHCPv6 in the IPv6 kernel. If PD is integral
to your net
[EMAIL PROTECTED] wrote:
> >Tim - SLAAC and DHCPv6 are fundamentally different ways to assign
> >addresses.
>
> Ralph thanks, I'm glad you (realize that) see my point. There is more than
> one IETF standardized way to do host addressing. Do you believe it is
> good that more than one IETF standar
Syam - I'm feeling really dense at this point. I don't understand
"unique prefix for host" and assigning the unique prefix for each
host between the CPE and the subscriber PC. In your scenario, what
devices participate in PD in the diagram I included? Is there a
description of the scenar
Yes, I think there needs to be a distinction made between:
a) prefix delegation, in which the upstream router gives the prefix to the
downstream node in the expectation that the downstream node will be routing
to nodes downstream from it,
b) prefix assignment, in which the upstream router adver
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 either.
>>
>> the first PD proposal (b
We believe that there is a need for an alternate way of doing PD simply
because the DHCP PD is not intrinsic to the stack and makes it unusable
sometimes. ICMPv6 is intrinsic ( by intrinsic, I mean that is always
available in the ipv6 stack implementations) and this proposal builds on
the current N
Some more detailed responses in line...
- Ralph
On Aug 22, 2006, at 11:25 PM, <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> wrote:
Hi Alain,
Thanks for the quick e-mail. As one of the co-authors, I'd in turn
like to reply (and state that ICMPv6 PD is ANOTHER way to do IPv6
PD, NOT a replacem
Tim,
>Given that there is a historical precedent for being able to do something via
>more than one standardized IETF way, I'd suggest that IPv6 PD is another such
>case where such an approach is warranted.
>...
>I'd like to repeat my/our contention that ICMPv6 PD is not meant to replace
>DHCPv6
>> 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. Netlmm hosts
are required to work with existing stacks, and I would
generally expect them to use
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 either.
the first PD proposal (by Brian Haberman) was indeed based on using
ICMP as transport. separate messa
Also, the subnet model that NetLMM WG wants to choose is to have
a unique prefix for each MN.
What is a "prefix"? In IPv6 it can be anywhere between /1 and
/127. (If it's longer than /64 it means you aren't using
ND, but ND is additional to the basic IPv6 architecture).
NetLMM is indeed usin
Tim - I don't think I made my point clear. SLAAC, DHCP and manual
addressing are all very different ways to accomplish the same result,
stemming from very different requirements:
SLAAC - all nodes on a link share the same prefixes; advertising
device sends a single message with confi
On Wed, 23 Aug 2006, Syam Madanapalli wrote:
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 o
Syam Madanapalli wrote:
> Currently DHCP mechanism works only between routers whereas this
> new mechanism works for end hosts.
The difference between a router and a host is a routing process and a
willingness to forward packets, not how it interprets ICMP or whether it
can parse DHCP.
Eliot
--
[EMAIL PROTECTED] wrote:
From: "Durand, Alain" <[EMAIL PROTECTED]>
Date: 2006/08/22 Tue PM 10:31:10 CDT
To: [EMAIL PROTECTED], Syam Madanapalli <[EMAIL PROTECTED]>,
IETF IPv6 Mailing List
Subject: RE: RE: Prefix Delegation using ICMPv6
Thanks for the quick e-mail. As one of the c
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
28 matches
Mail list logo
