Thanks for the comments! Sorry for the late reply. Some comments inline
I have one question on the protocol, and several on documentation.
Since this is a significant protocol, documentation is very
important.
For the sake of new implementors I have a number of suggestions for
ok, sounds good to me, which means we have no open issues on the draft.
Hesham
-Original Message-
From: Basavaraj Patil [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 01, 2006 2:51 AM
To: ext JINMEI Tatuya / 神明達哉 ; Soliman, Hesham
Cc: ipv6@ietf.org; Thomas Narten
with 1).
Hesham
-Original Message-
From: Basavaraj Patil [mailto:[EMAIL PROTECTED]
Sent: Saturday, October 28, 2006 4:24 AM
To: iesg@ietf.org
Cc: Syam Madanapalli; Soliman, Hesham; Thomas Narten
Subject: Re: Last Call: 'Neighbor Discovery for IP version 6
(IPv6)' to Draft
Thanks. But I still believe that a host should be able to test
if it is reachable in dormant mode (reachable, or reachable within
reasonable delay). This is good for dormant mode security.
= I'm not sure that you appreciate the fact that these are *logical*
channels, where *logical*
The paging channel is not dedicated to one terminal, it serves
all terminals (there are thousands of terminals in a paging area).
Paging channels can be overloaded (naturally or maliciously). In
this case, an incoming session may be missed.
= This is completely orthogonal to this
I wasn't assuming this.
NUD checks the traffic channel in both directions. That's OK.
But after the NUD procedure, the host enters dormant mode and
becomes reachable via another channel: the paging channel that
wasn't tested.
Consequently, the following scenario is possible:
Hello,
I couldn't understand why NUD is the responsibility of IP,
but the other is not.
So, why NUD isn't the link-layer's responsibility?
= Because of two reasons:
- Some link layers fon't have this connection-oriented service and
therefore do not do NUD.
- NUD tests reachability
.
= Completely different issue. ND is not a MIP function and is certainly
not a beacon and we're not trying to make it one. A message every 30
mins is not a beacon.
Hesham
jak
- Original Message -
From: Soliman, Hesham [EMAIL PROTECTED]
To: James Kempf [EMAIL PROTECTED
3) The current ND specs have an upper limit of 30 minutes on the
interval between router advertisements. That should be
changed, to
allow deployments to use a higher value. (that is the
assertion/problem.)
This is certainly possible and one could do it, but at some
jak Dunno. Most of the terminal engineers I've talked to
don't want to
bring up the traffic channel at all if the terminal is in
dormant mode.
They're comparing that kind of a design to what they
currently have where
dormant mode is entirely controlled by the circuit
Most wireless link protocols that provide robust dormant
mode support have a
separate dormant mode (aka paging) signaling channel that is
extremely
narrowband and requires very low receiver power to monitor.
This channel is
independent of the traffic channel over which IP
Folks,
Please take a look at Bob's text below. I'd like to suggest that
we replace the current text in 2461bis with the one below.
Any objections? I'll wait for another week before I can conclude
that we agree on this, i.e. if no one responds.
Hesham
For example:
M :
that the router is
reachable before you start applying other metrics for preferring
it over another router.
Hesham
Fred
[EMAIL PROTECTED]
-Original Message-
From: Soliman, Hesham [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 20, 2006 12:51 PM
To: Templin, Fred L
for the host
to prefer some on-link routers over others in its default router
selection process.
Fred
[EMAIL PROTECTED]
-Original Message-
From: Soliman, Hesham [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 20, 2006 1:37 PM
To: Templin, Fred L; ipv6@ietf.org
Subject: RE
, the draft will be updated and the reference to ICMP errors in the
state machine will be removed.
Thanks,
Hesham
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of Soliman, Hesham
Sent: Friday, January 06, 2006 10:31 AM
To: IPv6 WG
Subject: Sending
The basic issue left is whether we should allow a node to
send an ICMP error
due to the reception of an NA without the SLLAO. The
reason for sending the
ICMP error is to inform upper layers that the communication has
failed.
It took me a while to figure out what you are
on whether we could add this clarification to the
spec or
keep it as is.
Hesham
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of Soliman, Hesham
Sent: Thursday, January 05, 2006 6:09 AM
To: JINMEI Tatuya /
Cc: IPv6 WG
Subject: RE: Fwd: Request
Sorry for the late response I was out of the office.
= This can be added to the text at the beginning of 7.2.,
which discusses this issues.
Hmm, so the behavior corresponding to the following entry
(shown again
just to be accurate) is not currently described in the draft:
= Not
the change to APPENDIX C should cover the case of
an unsolicited ND message does not contain source/target LLAO,
AND the receiving node does not have a neighbor cache entry for
the source/target
(there are two conditions for a single 'case')
Is this now clear and
(Sorry for the delayed response...I hope you still remember the
context)
= No probs, I remember it clearly.
I've compared the difference of the state machine in Appendix C
between the 03 and 05 versions (attached below). At
least it doesn't
seem to cover the case where the
Hi Bob,
Dave,
I think we can handle this during IESG last call. Does anyone
oppose Dave's suggestion
below to update this statement according to RFC 4311 ?
Before answering the question, what would the exact change be to
draft-ietf-ipv6-2461bis-05.txt?
= Sorry, I think
is really viable without
delaying 2461bis.
I believe Hesham is suggesting (b), and if appropriate text can be
constructed I would support this.
= Thanks for the detailed description. Yes I was suggesting (b) above.
Hesham
-Dave
-Original Message-
From: Soliman, Hesham
Title: 2461bis and host-load-sharing
Dave,
I
think we can handle this during IESG last call. Does anyone oppose Dave's
suggestion
below
to update this statement according to RFC 4311 ?
Thx,
Hesham
-Original Message-From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]On
Sending in hibernate mode.
I'm not sure if this one is correctly addressed:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg05107.html
(BTW: msg05107 is a comment on version 03, and I could not get a 04
version. Has that version been issued, or is the version number
bumped?)
Folks,
The latest version of 2461bis should appear soon on the web.
All issues raised so far were addressed in this draft.
I think this concludes the WG LC and hopefully the chairs would
initiate IESG LC soon.
Thanks,
Hesham
===
This
All done, except:
define the policy for the Neighbour Discovery options (since
this hasn't
previously been properly defined).
= Did you mean the policy of allocating new option numbers?
- it should probably explicitly define the ICMP types and ND options
which are being continued
= I'm not sure I understand what you mean here. What do you
mean by don't have an explicit registration in RFC2461.?
The IANA considerations section in RFC2461 was very skimpy
and didn't
explicitly say what new ICMPv6 message types were being
added or what
the set of ND
for it. I guess whoever updates
3810 in future can consider this point. For now I think it's
sufficient to add a reference in 2461bis.
Hesham
Regards,
Elwyn
Soliman, Hesham wrote:
My understanding that as well as a reference to MLDv2 we
would need to
mention
My understanding that as well as a reference to MLDv2 we
would need to
mention that if any of the routers are 'legacy' that support only
MLDv1, then any MLDv2 routers would have to have their
configuration
flags set to make them operate in MLDv1 compatibility
mode. Hosts
I have one issue with APPENDIX A. The direct mention of the on-link
assumption was removed from the appendix (from the second bullet item
1), but it is still implied by the text that remains. The text is:
1) If no Router Advertisement is received on any interfaces, a
On Wed, 2005-06-01 at 12:16, Soliman, Hesham wrote:
= How do you know if you have no route to the destination?
You consult your forwarding table.
Could it not be on one of the links?
It could be if you have a forwarding table entry that points
to one or
more of your
Jinmei, thanks for catching this.
(B
(BFor those not familiar with the issue. There were two issues regarding
(Bthe RA improvement:
(B1. Relaxing the requirements on inter-RA intervals. This issue was raised by
(BMIPv6.
(B2. Eliminating random delays before sending RAs.Also a request
(B
(B 17. APPENDIX A (MULTIHOMED HOSTS)
(B
(B [...] Under
(B similar conditions in the non-multihomed host case, a node
(B treats all destinations as residing on-link, and
(B communication
(B proceeds. [...]
(B
(B This is the so-called
* Nodes implementing Optimistic DAD SHOULD additionally
implement
Secure Neighbor Discovery [SEND].
This seems like gratuitous recommendation. This either requires
justification, or removal. (I'd think the latter.)
= Agreed. I think it should be removed as it's more
om: [EMAIL PROTECTED]
(B [mailto:[EMAIL PROTECTED]
(B Sent: Wednesday, May 25, 2005 3:01 PM
(B To: Soliman, Hesham
(B Cc: ipv6@ietf.org
(B Subject: Re: 2461bis update
(B
(B
(B On Tue, 24 May 2005 10:04:25 -0400,
(B "Soliman, Hesham" [EMAIL PROTECTED] said:
(B
(B The only comments I made for this section (except the very recent one
(B we are now discussing) were the latter part of the section. More
(B specifically, I agreed with Pekka that the latter part contained a
(B redundant condition, and also suggested to clarify the complex
(B
: Thursday, May 26, 2005 12:17 AM
(B To: Soliman, Hesham
(B Cc: ipv6@ietf.org
(B Subject: Re: 2461bis update
(B
(B
(B On Wed, 25 May 2005 23:31:24 -0400,
(B "Soliman, Hesham" [EMAIL PROTECTED] said:
(B
(B = Yes this is clearly wrong. I'll update this. As for the
(B
Hi all,
I submitted an updated revision of 2461bis which includes
the resolutions that were agreed on by the WG in the last meeting
(the SLLAO thread). It also includes fixes for the comments Tatuya
raised on the last version.
I think this draft is now ready for the IESG.
Thanks,
Hesham
Make that 200 %.
Hesham
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of
Ralph Droms
Sent: Monday, May 23, 2005 2:47 PM
To: [EMAIL PROTECTED]
Cc: dhcwg@ietf.org; Bob Hinden; ipv6@ietf.org
Subject: Re: IPv6 WG Last
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
In some scenarios there is a danger in the following approach:
- hosts boots
- looks for DHCP server, doesn't find one
- Keeps looking every couple of minutes
This leads to inefficient use of power and network resources
in some wireless devices. A more efficient way to do things is
to indicate
, 2005-05-20 at 14:50 -0400, Soliman, Hesham wrote:
In some scenarios there is a danger in the following approach:
- hosts boots
- looks for DHCP server, doesn't find one
- Keeps looking every couple of minutes
A client is free to use some other timeout (2 hours instead of 2
minutes
whether DHCP should be run are useful. But, those bits are advisory
only.
- Bernie
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Soliman, Hesham
Sent: Friday, May 20, 2005 3:15 PM
To: Ralph Droms (rdroms)
Cc: dhcwg@ietf.org; ipv6
Sure, this is fine with me. Will add it to the next rev.
(B
(BHesham
(B
(B -Original Message-
(B From: [EMAIL PROTECTED]
(B [mailto:[EMAIL PROTECTED]
(B Sent: Wednesday, April 27, 2005 4:21 AM
(B To: Soliman, Hesham
(B Cc: ipv6@ietf.org
(B Subject: Forward: Re: IPv6 WG
PROTECTED]
(B Sent: Tuesday, March 08, 2005 3:13 PM
(B To: [EMAIL PROTECTED]
(B Cc: Soliman, Hesham; ipv6@ietf.org
(B Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO
(B
(B
(B On Tue, 22 Feb 2005 16:26:26 +1100,
(B Greg Daley [EMAIL PROTECTED] said:
(B
(B Okay, so
(B = I'd rather use IPv6 if that's ok with everyone since
(B this doc is only applicable
(B to IPv6.
(B
(B Hmm, I actually don't have a strong preference as long as the result
(B is consistent, but just "IP" seems to be more aligned with the sense
(B of Section 2.1:
(B
(B
Hi Tatuya,
(B
(BThanks for the review, some answers inline.
(B
(B Non-editorial comments
(B
(B 1. (throughout the document)
(B
(B There is a mixture of
(B- how IPv6 operates over different link layers
(B and
(B- how IP operates over different link layers
(B even
Sorry for the late reply.
6.2.1. says,
2369The above variables contain information that is
placed in outgoing
2370Router Advertisement messages. Hosts use the
received information to
2371initialize a set of analogous variables that
control their
this is clear, if not let me know ASAP because I'm submitting
the draft soon before the deadline.
Hesham
-Original Message-
From: Greg Daley [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 20, 2005 6:13 PM
To: Christian Vogt
Cc: Soliman, Hesham; ipv6@ietf.org; Mark Doll; Roland
ok thanks.
-Original Message-
From: Greg Daley [mailto:[EMAIL PROTECTED]
Sent: Sunday, February 20, 2005 6:53 PM
To: Soliman, Hesham
Cc: Christian Vogt; ipv6@ietf.org; Mark Doll; Roland Bless
Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO
Soliman
Hi all,
I just submitted the (hopefully) last rev of 2461bis.
This revision includes all comments discussed on the list
till today. The only two things missing are updating the Ack
section and getting the RFC number for ADDRCONF in the references
section. I guess the latter can be a note to the
(BThanks,
(BHesham
(B
(B
(B -Original Message-
(B From: [EMAIL PROTECTED]
(B [mailto:[EMAIL PROTECTED]
(B Sent: Sunday, February 20, 2005 9:57 PM
(B To: Soliman, Hesham
(B Cc: ipv6@ietf.org
(B Subject: comments on draft-ietf-ipv6-2461bis-01.txt
(B
(B
(B Hi,
(B
Christian,
Thanks for the detailed description. I think Nick brought this up
some time ago too.
My suggestion is that upon reception of an RS with no SLLAO the
router checks if an entry already exists, if none exists then it
creates one and puts it in STALE. If an entry already exists with
a
]
Sent: Friday, February 18, 2005 9:19 PM
To: Soliman, Hesham
Cc: Christian Vogt; ipv6@ietf.org; Mark Doll; Roland Bless
Subject: Re: RFC 2461[bis]: RS with srcaddr but w/o SLLAO
Hi Hesham,
Soliman, Hesham wrote:
Christian,
Thanks for the detailed description. I think Nick
Sent: Friday, February 11, 2005 3:11 PM
(B To: Erik Nordmark
(B Cc: Pekka Savola; Soliman, Hesham; IPv6 WG
(B Subject: Re: IPv6 WG Last Call:draft-ietf-ipv6-2461bis-01.txt
(B
(B
(B Catching up a possibly minor point of an old thread...
(B
(B On Thu, 13 Jan 2005 10:39:15 -0800
Pekka, all,
Sorry for the delay in resolving this but there were too many comments
and too little time! Seems like most of your comments were clearly addressed
by me or other people on the list and most are being put in the next rev
(thanks).
But I'm going to address the unresolved ones so
Alain Durand wrote:
...
The argument that NDproxy will only be used in a certain
environments
where SEND is not needed is clearly bogus, The IETF is not about
defining standards for special cases but for the whole Internet.
I disagree as a matter of principle. It is
== 'or the source chooses to ignore unauthenticated Redirect
messages' smells quite a bit from a leftover of IPsec
AH times. Reword?
Can't SeND nodes choose to ignore redirects that aren't
protected by SeND?
Sure. I was just referring this editorially, that
Pekka,
Thanks for the comments.
My response inline. If I don't address a comment below, it means
I have no problem updating the draft with the comment.
Others please take a look and voice opinions if you have them.
We should try to make this LC have a deadline :)
substantial
---
I couldn't find any mention of RFC2526 Reserved IPv6 Subnet Anycast
Addresses
in the node requirement document.
Is it OK for an IPv6 node to ignore it? in practice, should/must an
implementation
have some code to:
1- prohibit such addresses to be configured on an interface
2-
Thanks for the comments.
(B
(B
(B at Draft Standard. Substantive comments should be directed to
(B the mailing list. Editorial comments can be sent to the document
(B editor. This last call will end on 11/15/2004.
(B
(B I've not gone through the entire document (it's so
Title: RFC2461bis: Multicast capable vs Multicast Service [was RE: Comments for rc2461bis]
Your
mail server forgot ;)
Using the term 'multicast services' around this area is
confusing. If the link MUST provide multicast services maybe that is
something that should be in the basic
Quoting from S5.2:
Next-hop determination for a given unicast destination operates as
follows. The sender performs a longest prefix match against the
Prefix List to determine whether the packet's destination
is on- or
off-link. If the destination is on-link, the
One major comment:
5. Security Considerations
Further work will be required to integrate Optimistic DAD
with Secure
Neighbor Discovery [SEND].
==
]
Sent: Sunday, September 12, 2004 12:30 PM
To: Francis Dupont; Soliman, Hesham
Cc: Brian Haberman; [EMAIL PROTECTED]
Subject: RE: AH and flow label
The suggestions of making the flow label immutable and protecting it by
AH look like bad ideas. The 20 bits in the flow label are the only
reserved
Having read the whole thread, I can't see any convincing reason
to include the flow label in AH.
= I guess I've said my 2 cents on this point.
Apart from the arguments already expressed, what do we do if
AH fails because of a changed flow label? We discard the packet
instead of delivering it.
Ok, please see RFC 3697 for the latest document on the
flow label. This reflects current concensus.
Hesham
-Original Message-
From: Manfredi, Albert E [mailto:[EMAIL PROTECTED]
Sent: Monday, September 13, 2004 3:47 PM
To: Soliman, Hesham
Cc: [EMAIL PROTECTED]
Subject: RE: AH and flow
options. That would drive the protected
QoS packets along a specified, protected route that a hacker would presumably not
know, and therefore would have a harder time hacking.
Bert
-Original Message-
From: Soliman, Hesham [mailto:[EMAIL PROTECTED]
Ok, please see RFC 3697
I agree with the drawback you see and it's not ideal.
But I also think the whole flow label story was inconsistent
and we finally have concensus on how we want to use it.
= this is something we should not reproach the ipsec WG for...
= I wasn't reproaching the IPsec WG. Please
I agree with Brian. I'd like to see it protected.
Hesham
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
Brian Haberman
Sent: Friday, September 10, 2004 6:50 AM
To: Francis Dupont
Cc: [EMAIL PROTECTED]
Subject: Re: AH and flow label
Speaking as an IPv6
of those was published in the flow movement draft. So
if the above is too abstract please see draft-soliman-mobileip-flow-move
for an example.
Hesham
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Friday, September 10, 2004 11:12 AM
To: Soliman, Hesham
Cc
I have a silly question below.
(B
(B
(B I now feel I get understanding the point...to make it sure,
(B let me try
(B to rephrase that.
(B
(B Assume we have a "stateful" DHCPv6 server (that implements RFC3315)
(B running. The server should support both
(B
Title: Comments for rc2461bis
Thanks
for your comments. I'll prepare new issues/responses
as
needed and get back to each one separately.
Hesham
-Original Message-From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]On Behalf Of Elwyn DaviesSent:
Wednesday, August 04, 2004 12:10
(B I think the high-order question is whether mixed-mode
(B implementations exist
(B or whether folks are working on building such things. If not
(B we can limit
(B any text in 2461bis to what's needed for folks to not be confused by
(B the footnote in rfc 2460 about per-interface
(B It seems like in 2461bis-00.txt that the introduction of IsRouter in
(B 6.2.1 is inconsistent with the text in 6.2.2 about
(B AdvSendAdvertisements.
(B
(B RFC 2461 reads as if a node "advertises" itself as a router
(B (by sending RAs
(B and setting the R-flag in NAs any time
Folks,
This issue is now resolved.
Hesham
- Original Message -
From: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Tuesday, July 20, 2004 12:54 AM
Subject: [psg.com #256] Eliminate random delay in RS transmission
Issue:
---
This issue was raised in order
Thanks for the catch, I missed it. I'll update it in my
version for the next submission.
Hesham
-Original Message-
From: Suresh Krishnan [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 21, 2004 8:26 AM
To: Soliman Hesham; [EMAIL PROTECTED]
Subject: On-link assumption refuses
(B Per RFC 2461 the per router list is per interface.
(B There is an issue for the implementations (probably all
(B implementations)
(B which have a per-node default router list, but from the perspective
(B of the RFC 2461 specification it has already punted on all
(B aspects of
To: Soliman Hesham
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [psg.com #257] Eliminate random delay in RA transmission
Hi Hesham,
Soliman Hesham wrote:
Very sorry for the confusion. This text belongs
to a different issue. Eliminating the random
delay is NOT rejected
we should ignore the
(Brestriction
(Bon prefix lengths in the RA, which is likely to be the norm.
(B
(BHesham
(B
(B -Original Message-
(B From: [EMAIL PROTECTED]
(B [mailto:[EMAIL PROTECTED]
(B Sent: Thursday, June 17, 2004 10:25 AM
(B To: Soliman Hesham
(B Cc: [EMAIL
Issue description:
RFC 2461 is not clear on whether it is possible for
a node to act as a router on one or more interfaces
and a host on other interface(s). The distinction
between the two functions is not clearly done on
a per interface basis.
Suggestion: We need to explicitly state that
Thanks, I'll update the text and reference accordingly.
Hesham
-Original Message-
From: Erik Nordmark [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 16, 2004 3:17 AM
To: Soliman Hesham
Cc: James Kempf; [EMAIL PROTECTED]
Subject: RE: [rfc2461bis] Security issues
.
If there are no comments on the text this issue will be closed.
Hesham
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of
Soliman Hesham
Sent: Monday, June 14, 2004 10:13 AM
To: [EMAIL PROTECTED]
Subject: [rfc2461bis] Receiving a prefix option with prefix
length 64
(B (I'd personally avoid using the magic number of 64, but anyway)
(B
(B= Why? It's a reality, at least for 2462.
(B
(B
(B In that case, the host can configure the on-link prefix but cannot
(B configure an address by the stateless autoconfiguration mechanism.
(B So, in this case, if
Folks,
I'm formally addressing the issues left for 2461bis.
All the issues were either resolved or agreed on in
the meeting. The next series of emails are to inform
the list about the resolutions that we already agreed
on and see if there are any comments before I close the
issues.
The
This issue was discussed on the list and in the
last meeting.
There were two sub issues:
1. How does a host configure an address?
2. Inconsistency with ADDRARCH
We agreed that (1) is out of scope for 2461bis
and is more relevant for address configuration
mechanisms.
(2) was discussed in the
there is no multicast
capability but ND works fine.
Hesham
The discussion of IPsec in Section 11.2 looks fine.
jak
- Original Message -
From: Soliman Hesham [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, June 14, 2004 2:48 AM
Subject
ok thanks, I'll put this text in 4.2.
(B
(BHesham
(B
(B -Original Message-
(B From: [EMAIL PROTECTED]
(B [mailto:[EMAIL PROTECTED]
(B Sent: Monday, June 14, 2004 11:39 PM
(B To: Soliman Hesham
(B Cc: [EMAIL PROTECTED]
(B Subject: Re: [rfc2461bis] Clarify the use of the M
Some answers below.
(B
(B So far, many people seem to have (somehow) agreed on what Christian
(B said (attached below): the M/O flags should just be hints of
(B availability of the corresponding services (or protocols) rather than
(B a trigger to invoke the protocols under a certain level
(B
(B = Stateless is a MUST according to the Node requirements.
(B Now, if an
(B implementation
(B decided to use DHCP when the flags are set, then there are
(B two cases to
(B consider:
(B
(B do you mean the case when the flags are NOT set? (I talked about the
(B case
(B The facts are:
(B
(B1. there is code that sets the MO bits. (router implementations)
(B2. there are at least two implementations that read and
(B act on the O
(B bit. These two implementations both invoke stateless DHCPv6 as
(B the action.
(B
(B= So based on
I thought that statement referred to one implementation
only, which is confirmed by Jinmei's response to my email
Hesham
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 27, 2004 12:14 PM
To: Soliman Hesham
Cc: IETF IPv6 Mailing List
Alain
(B
(BYour point about security is valid but is relevant to securing RAs
(Bin general, and is not specific to the M/O bits. If you want to be sure
(Bthey're
(Bsecure just use SEND.
(B
(BHesham
(B
(B
(B -Original Message-
(B From: [EMAIL PROTECTED] [mailto:[EMAIL
(BAs a general comment, IMHO we're wasting cycles on this
(Bdiscussion and I agree with Iljitsch's email on this.
(BSpecific comments below
(B
(B
(B Some people commented that we needed to clarify what's bad with the
(B M/O flags if we want to deprecate (or remove) them. That's a fair
(B
(B One thing we may have to care, however, is that the lack of
(B implementation might be a barrier of recycling the spec as a
(B DS, since
(B we'd need to show interoperable implementations.
(B
(B= Good point. It would be good to get some clarification on whether
(Bthis is an
Thus the 16 byte hash is stuck in the data part.
If a unsuspecting host gets this packet it expects
data in the portion where the hash now is in place.
First of all, the hash is in the TCP header (I think you're
confused by
the description of the hash calculation), and second
(B
(B FWIW, I really think that there is no point in going round
(B and round again
(B in this discussion when there is no harm done by keeping them.
(B Removing them is not backward compatible for 2461 anyway.
(B So I recommend we leave them as defined.
(B
(B I see your
-
From: Soliman Hesham [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 14, 2004 11:57 AM
To: Subramonia Pillai - CTD, Chennai; [EMAIL PROTECTED]
Subject: RE: RFC 2461 : Neighbor Discovery
I am running IPV6CP for PPP links. I will come to know
the link local
address from
Hi Ralph,
I suggest dropping stateful from the description because
of the potential
for confusion inherent in providing a stateful protocol for *other*
configurations with stateless DHCPv6 [RFC 3736].
= I don't find the words stateful and stateless confusing
at all in this context. I
RFC 3316
intentionally doesn't address transition issues. These issues are
addressed in the
3GPP scenarios and analysis drafts in v6ops.
Hesham
-Original Message-From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]On Behalf Of JayabharathiSent:
Tuesday, April 13, 2004 8:08
1 - 100 of 126 matches
Mail list logo
