Looks very good, Vishwas.
You may consider softening this from a "MUST" to a "SHOULD", though,
given that hosts are at this stage not guaranteed to always produce
non-overlapping fragments.
- Christian
On May 28, 2009, Vishwas Manral wrote:
Hi Christian,
Ok. I think to make it more generic
On May 28, 2009, Vishwas Manral wrote:
The draft already contains the below:
"IPv6 nodes transmitting datagrams that need to be fragmented MUST
NOT
create overlapping fragments. IPv6 nodes that receive a fragment
that overlaps with a previously received fragment MUST cease the
reass
On May 27, 2009, Suresh Krishnan wrote:
Firewalls may or may not reassemble fragments, and I am not sure
what to
put in here. If you can suggest some text to put in this paragraph, I
will be glad to add it to the document.
Suresh -
My suggestion is not about fragment reassembly in firewall
Suresh -
As far as I know, there are no legitimate applications for overlapping
fragments (please send in a note if you see any). I am not aware of
any
stack that generates these either under normal conditions either.
In addition, there doesn't seem to be a reason, other than malicious,
for
Suresh and all -
I have read the document and support it being progressed as a Proposed
Standard. The document identifies a security vulnerability that ought
to be mitigated, and this document is a necessary step in doing so.
One comment: Is there data on how common overlapping fragments are i
andom delay between 0 and
> | MAX_RTR_SOLICITATION_DELAY as specified in [DISCOVERY].
>
> I'm happy to just recommend a "SHOULD NOT delay" in OptiDAD, as this
> was something I'd been assuming all along. Does anyone in here
> object?
Yes, I agree. This solution makes sense.
- Christia
with option (3), because it gives you the efficiency you
need for mobile nodes plus the robustness you need for both mobile and
stationary nodes. This comes at the cost of a little bit more overhead,
but such a trade-off is quite normal for optimizations like OptiDAD.
Regards,
- Christian
-
omit such delays if..." to "the Optimistic Node MUST omit such delays
if...", but I'd prefer the less strict version.
Regards,
- Christian
[1] "Comment on RFCs 2461bis and 2462bis", Discussion on the IPv6
mailing list, May 27, 2005, <http://www1.ietf.org/mail-a
ddress the MLD clauses mentioned in 2461/2.
> I'd welcome your suggestions!
As mentioned before, this is also addressed within the text above.
> Note that OptiDAD presents changes to 2461/2, not 2461bis/2462bis,
> because it's Standards Track and the -bis documents ain'
sion
on the IPv6 mailing list, May 27, 2005,
http://www1.ietf.org/mail-archive/web/ipv6/current/msg05084.html
[4] "DAD and MLD Interaction", Discussion on the DNA
mailing list, June 13, 2005,
http://webcamserver.eng.monash.edu.au/~warchive/dna/2005-06/msg00098.html
--
Christian Vogt, Ins
ll, the MNs will end up waiting anyway, namely for D2 or D3. At least
in the very, very likely case that they autoconfigure a new IPv6 address
after the handover.
I think Greg's opinion on this is different. I'm not sure why, though.
Ok, so let's settle this issue. Thanks
if many others
also want the change (and no one objects to that), I'll try to revise
the draft once again.
Yes, sorry for raising this so late.
And thanks for your detailed response!
Regards to all,
- Christian
--
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uk
I see, the ODAD draft does not mention or tackle the
delay for MLD Reports either. Maybe that should be changed, too. Nick?
--
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/
nning of section 6.2.6.
An aside with respect to the second paragraph: You may also want to
modify this paragraph through a s/Neighbor Discovery/address resolution/
in both section 7.2.4 and, as suggested, section 6.2.6.
- Christian
--
d
clarification 6.2.6 for the RS case)
Agreed. What would have to be added to (or modified in) section 6.2.6
is not too far from what is needed for section 7.2.3/7.2.4. So, we
might be able to reuse some text, making the modifications consistent.
- Christian
--
Christian Vogt, Institute of Telema
citly
mentions the state, because the usual address-resolution procedure is
used anyway and the state should therefore be clear.
- Christian
Greg Daley schrieb:
Hi Christian,
Christian Vogt wrote:
Hi Hesham,
hope this is not too late.
Not sure but the text may suggest to create NC state even if the RS
Hesham,
I just saw your email. So the comments in my last mail were probably
too late. Uhh, such is life... :-(
- Christian
--
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/
Soliman, Hesham schrieb:
Hi all,
I just submitted the (hopefully
s with a unicast Router Advertisement directed to the
> solicitation's sender.
>
> - It responds with a multicast Router Advertisement.
>
> Whether or not a Source Link-Layer Address option is provided in the
> solicitation, [...]
The rest is perfect, IMO.
Oh, just a nit: s/link
a RS with an unspecified source address.
According to RFC 2461bis, rate limitations may cause the router to not
immediately send a solicited multicast RA, but to wait for the next
periodic multicast RA.
(4) Rate limitations should be adjustable according to a particular
link-layer technology, ca
layers with acknowledgements,
like IEEE 802.11, where they are realiably transmitted.
- Christian
[1] draft-daley-ipv6-tsllao-01.txt
--
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/
"No great genius has ever existed witho
ATE, that
entry is put into state INCOMPLETE and address resolution begins as usual.
As far as I can see, the additional state is needed if a router actually
creates a NC entry upon receiving a RS without SLLAO. An alternative
would be not to create the NC entry. But this may not be appropriate
21 matches
Mail list logo
