so what has happen to this? Still no feedback from authors or chairs or?
On Wed, 11 Jul 2007, Paul Vixie wrote:
I'm not sure what the status of Paul's document is since the drafts
directory only contains this one:
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ula-central-02.txt
Is Paul'
Folks,
Please see a new version of our I-D at the URL below.
http://www.ietf.org/internet-drafts/draft-wbeebee-nd-implementation-pitf
alls-02.txt
See change log to understand what has changed from the -01 version.
Gross changes worth highlighting are:
1. A new section 7 has been added to t
Hemant Singh (shemant) writes:
> Hemant Singh (shemant) writes:
> > Now, I'd like to focus the discussion back to how will the PPP peer
> > (which is a server)
>
> Nit: PPP doesn't define "client" or "server." It's peer-to-peer.
>
> I know PPP is a p2p model. I was using the term server to ref
James,
Please see in line below with "".
-Original Message-
From: James Carlson [mailto:[EMAIL PROTECTED]
Sent: Monday, July 23, 2007 12:42 PM
To: Hemant Singh (shemant)
Cc: Ole Troan (otroan); [EMAIL PROTECTED]; JINMEI Tatuya / ;
ipv6@ietf.org; Dave Thaler
Subject: RE: Neighbor Disc
Hemant Singh (shemant) writes:
> I am saying when the M bit is clear, then a node cannot acquire an
> address using DHCPv6. However, I agree with you DHCPv6 is much better
> alternative than PPP.
>
> Now, I'd like to focus the discussion back to how will the PPP peer
> (which is a server)
Nit: P
Hemant Singh (shemant) writes:
> The topic under discussion is how does a SLAAC PPP client acquire an
> IPv6 address using DHCPv6?
Using stateful DHCPv6 (with the RA 'M' bit set to one), of course.
> Yes, stateless DHCPv6 can be used to dole out
> options to the SLAAC client but you cannot have t
James,
I am saying when the M bit is clear, then a node cannot acquire an
address using DHCPv6. However, I agree with you DHCPv6 is much better
alternative than PPP.
Now, I'd like to focus the discussion back to how will the PPP peer
(which is a server) going to fix the bug when this peer hasn't
Hemant:
Sorry that the re-posting got interjected with the thread of thought
that you want to carry forward. The intention wasn't to derail it.
Rather, it is a result of my own posting frustrations. Please continue
the discussion on reachability detection
Regards,
Srihari Varada
Hemant Sing
I will be out of the office starting 07/23/2007 and will not return until
07/27/2007.
I will respond to your message when I return.
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.or
Srihari,
I think we are de-focusing the discussion again and going into the same circle
from last week all over again. I said the bug is in the peer as to why peer did
not respond with an NA to the NUD NS from PPP client? James agreed with me. I
also said, having any node, not just a PPP client
[text formatted reply (July 22, 2007) to van Beijnum is being reposted
-- apologies for the mix-up]
The subject took a detour from its original context of the need for
address resolution through the Neighbor Discovery protocol.
The author is appreciative of the belated feedback though the la
James,
The topic under discussion is how does a SLAAC PPP client acquire an
IPv6 address using DHCPv6? Yes, stateless DHCPv6 can be used to dole out
options to the SLAAC client but you cannot have the SLAAC client obtain
an IPV6 address with stateless DHCPv6. Sorry, I wasn't clear like so in
my e
Hemant Singh (shemant) writes:
> Let's clear the air. I agree with Srihari's email on IPV6CP and new
> options.
So do I. Those issues are just out of scope.
> Now let's see what the PPP interop issues are:
>
> The sender PPP node is ND compliant when it issues a unicast NS for NUD
> before send
[Resending the message that couldn't get posted on July 18, 2007 ...]
All:
Followed the thread on the subject, and noted the interoperability
problem between link partners, with no link-level addresses, on a
point-to-point link (such as PPP).
It is gathered that the implementation interopera
[here is the email that had posting problems]
The subject took a detour from its original context
of the need for address resolution through the Neighbor Discovery
protocol.
The author is appreciative of the belated feedback though the last call
for its parent draft (draft-ietf-ipv6-over-ppp
All,
The recent discussion on the various forms of centrally maintained
ULA addresses clearly shows that there is no firm consensus on the
correct direction. Given that, I have asked the authors of the
ULA-central draft to analyze the discussion to this point and post a
summary of the comment
Let's clear the air. I agree with Srihari's email on IPV6CP and new
options. Now let's see what the PPP interop issues are:
The sender PPP node is ND compliant when it issues a unicast NS for NUD
before sending any data. The PPP peer of this sending node has a bug as
to why the peer is not respond
Iljitsch van Beijnum writes:
> On 20-jul-2007, at 2:36, James Carlson wrote:
>
> >> Still better to have different maximum packet sizes for v4
> >> and v6, though.
>
> > That sounds like an IP configuration issue, not a PPP issue.
>
> Isn't that what the NCPs are for, to provide the necessary gl
18 matches
Mail list logo
