I support Joseph's proposal and plan to add it to our implementation.
Regards,
Daniel.
--
__
Daniel Gavelle, Software Team Leader
Low Power RF Solutions (formerly Jennic Ltd.)
NXP Semiconductors Furnival Street,
Sheffield,
S1 4QT, UK
Tel: +44
The message from Joseph Reddy is important and makes sense.
I have a remark to that message as well: when the RH is built as you
suggest (BR inserts is own address in the RH (the one on which
interface? an ll address?)) it may be questionable about how the AH
authentication header is applied
Hi Joseph,
I presume that you are not using IP-in-IP tunneling. If you were using
IP-in-IP tunneling as the draft suggests, then the source address of the
inserting router is included in the outer IP header.
Your comment seems relevant to draft-hui-6man-rpl-headers-00, which describes
what
IMHO, IPv6 links that occur in the network (even tunnels)
should try to do better than 1280 if possible. Otherwise,
VPNs/tunnels that ride over the links may see a too-small
MTU resulting in IPv6 fragmentation. Granted, doing better
than 1280 may be difficult for some links.
Thanks - Fred
I think it should use the checksum field. It is generally a bad idea for one
layer to neglect its usual built-in error-checking duties because it assumes
another layer will handle it.
Let me draw an analogy from the crypto world, we don't use weak 56-bit DES as
our PGP keys because we assume
Hi,
I have a comment on the rpl-routing-header draft that was noticed during
interoperability testing conducted by the zigbee alliance.
In the most common usage of this header, the border router inserts a source
routing header with the full set of intermediate nodes before forwarding it
( resending as original post didn't go through... )
Hi,
I have a comment on the rpl-routing-header draft that was noticed during
interoperability testing conducted by the zigbee alliance.
In the most common usage of this header, the border router inserts a source
routing header with the full
I concur with Fred that IPv6 links over the network should have an MTU 1280 if
possible.
The fragmentation that could occur at say the head-end of a tunnel seems enough
of a contraindication in general for it having a 1280 MTU.
Efficient use of (up)links is clearly another consideration when
Many thanks to Suresh Krishnan for excellent minutes!
I'd really like to echo that. It's a pleasure to see minutes
that summarise discussions in good English, rather than just
record he said/she said.
Regards
Brian Carpenter
On Apr 20, 2011 1:04 PM, Bob Hinden bob.hin...@gmail.com wrote:
The minutes for the Prague IETF 6man working group meeting are now online
at:
http://www.ietf.org/proceedings/80/minutes/6man.txt
Many thanks to Suresh Krishnan for excellent minutes!
Bob and Brian
Scott Brim wanted some
10 matches
Mail list logo
