Hello, Ted.
Thank you for your reply.
My comments are below.
2008/11/4 Ted Lemon <[EMAIL PROTECTED]>:
> On Nov 3, 2008, at 6:40 PM, Joseph Hyunwook Cha wrote:
>>
>> However, if the service provider provides DHCPv6 service for the internet
>> connectivity of custome
Hello, folks.
I would like to introduce DHCPv6 proxy agent in a saparate thread.
The following is a rough description regarding the DHCPv6 proxy agent.
Any comments will be appreciated.
1. Motivation
Under the environments where classic bridge technology can not be applicable,
local hosts on t
Hello, Teemu.
Thank you for your clarification.
>>Since DHCPv6 server is also able to assign multiple addresses
>>to single client depending on the poliy, the host can activate
>>its server with the assigned address except the one used by
>>itself if it has
>>DHCPv6 server installed. Then, other
Hello, all.
I would like to share my interests on this issue and discuss DHCPv6
based solution more.
Solutions suggested by Pekka are below.
1) run DHCPv6 again, with a different DUID or client identifier (could
it get more /128's that way,
2) use DHCPv6 IAs to request multiple addresses? Then it
Hello, all.
I would like to see what is the IETF consensus on this topic.
Currently we have no further conclusion on this topic than the point that it is
very difficult to choose the silver bullet among several options listed by
Thomas and Ralph. However, I also believe that we need to encourag
Hello, Teemu.
Thank you for your clarification.
> Consider cellular host case:
> - host implements e.g. ND proxy and DHCPv6 PD for WAN connection sharing
> - host attaches to a network where only DHCPv6 happens to be used
> - host gets single /128 IPv6 address from DHCPv6
> - host tries to get som
Hello, Teemu.
My comments are below.
2008/10/23 <[EMAIL PROTECTED]>:
> Hi,
>
>>-Original Message-
>>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
>>Behalf Of ext Ted Lemon
>>Sent: 16 October, 2008 20:49
>>To: Iljitsch van Beijnum
>>Cc: David W. Hankins; [EMAIL PROTECTED]; List Mail
Hello, Teemu.
A few comments are added below.
2008/10/23 <[EMAIL PROTECTED]>:
> Hi,
>
> Used link-layer does have an impact: on cellular networks the link-layer is
> nowadays most often opened on-demand (i.e. when an application starts), or
> quickly reopened e.g. if network connection is temp
Hello, David.
A few comments are inserted.
2008/10/23 David W. Hankins <[EMAIL PROTECTED]>:
> Just a few things that I think are potential factual errors or
> misreads that need clarifying.
>
> On Tue, Oct 14, 2008 at 09:48:42AM +0200, Iljitsch van Beijnum wrote:
>> It's not a question of "problem
Hello, Tony.
Thank you for your agreement and interests in the issues being
addressed by the draft "draft-cha-ipv6-ra-mo-00.txt".
Since I feel that we need to discuss how to solve the issues more, I
would like to insert my comments as below.
2008/10/24 Tony Hain <[EMAIL PROTECTED]>:
> I agree wi
Hello, Ralph and all.
I would like to insert another option into the following list.
draft-ietf-ipv6-ra-mo-flags-01.txt
I am not clear why this WG document failed to proceed. However, I view
this document as nice base docuement since I think that it seems that
we do not have clear reason to deprec
Hello, Thomas.
Inline comments are continued below.
2008/10/15 Thomas Narten <[EMAIL PROTECTED]>:
> Joseph Hyunwook Cha <[EMAIL PROTECTED]> writes:
>
>> Hello, Thomas.
>
>> Thank you for your analysis and suggestions.
>
>> IMO, as long as M&
Hello, Ted.
Linux kernel provides rtnl socket interface for applications to get latest
received valude of M&O bits in RA. You can obtain wanted informations using
libnl APIs, which is the way that DHCPv6 client maintained by Redhat does. (I
did not try this, but just checked source codes.) For
Hello, Thomas.
Thank you for your analysis and suggestions.
IMO, as long as M&O flags are configured correctly, there is no reason to
ignore the bits. So, I do not think that one of two options should be selected
and specified exclusively. What I am saying is that it will be ok if there is
an
Hello, James
> If the point is to somehow "save resources" by turning off DHCP when
> not wanted, isn't that really more of a client implementation issue
> than it is a protocol issue? The existing M/O bits only suggest when
> starting DHCP might be good. It's up to implementations to determine
>>> One part of the situation that may have changed - or, perhaps, wasn't
>>> considered - is the case of implementors reading RFC 486[12] without
>>> the knowledge of previous discussions of the M/O flags. How will
>>> those implementors interpret the text in RFCs 486[12] and 246[12], and
>>> ho
Thomas,
I would like to add a few comments as below.
>
> --- Original Message ---
> Sender : Thomas Narten<[EMAIL PROTECTED]>
> Date : 2008-09-18 22:01 (GMT+09:00)
> Title : Re: Request for Advices on the draft "draft-cha-ipv6-ra-mo-00.txt"
>
> HYUN WOOK CHA <[EMAIL PROTECTED]> writes:
>
17 matches
Mail list logo
