Jarno,
However, as you well know, we have very loose semantics for the flow
label still. Admittedly, an encapsulator/decapsulator pair can
agree on their own semantics for the flow label, but it would be
preferable for the encapsulation method to describe flow label
semantics (consistent with RFC 3967).
Brian
On 2007-12-12 19:08, [EMAIL PROTECTED] wrote:
Few points on this:
- The issue with having to sum all the data in the packet is moot, since
you do not have to do this with UDP-Lite
- There is no way you can require L2 error detection from all links
between the tunnel endpoints. You can maybe hope. Also L2 errors are not
the only possible source of bit errors.
- For the intended load-balancing effect you should be able to use the
flow label field of the encapsulating IPv6 header. Routers ought to be
able to take that into the hash in addition of the IP addresses.
- If your router can't take the IPv6 flow label into the hash you could
still use multiple addresses per (IPv6) ETR
But I have to agree that I can't see why checksumless IPv6/UDP
encapsulation would be any more dangerous than IPv6 encapsulation
without UDP. But for the purpose being discussed here UDP is really not
needed at all, since you have the flow label in the IPv6 header anyway.
Regards,
Jarno
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of ext Dino Farinacci
Sent: 12 December, 2007 02:24
To: Brian E Carpenter
Cc: Marshall Eubanks; Iljitsch van Beijnum; Stephen Sprunk;
Routing Research Group list
Subject: Re: [RRG] The use of UDP in LISP
Dino Farinacci has suggested this text :
o When a IPv6 router is using a UDP header as part of a tunnel
encapsulation, it MAY compute a UDP checksum. The IPv6
router on the
other side of the tunnel receives a UDP checksum of
non-zero it MUST
compute the checksum according to [UDP-spec]. When an IPv6 router
uses a UDP header for tunnel encapsulation and sets the
UDP checksum
field to 0, the IPv6 router on the other side of the
tunnel MUST not
compute the checksum on the received packet. This procedure allows
tunnel routers to behave the same for tunnel encapsulating
IPv4 and
IPv6 packets.
At the least AMT and LISP would require this, and I suspect that
there will be others.
I don't actually understand the "require". If you'd written "People
Required in the sense if you want to get the protocols into product.
coding AMT and LISP would find this convenient" I'd understand it,
And it isn't the code, it is the gates. ;-)
but surely the tunnel end-points will know whether they are
generating
or receiving IPv4 or IPv6 packets?
Yes, but what is your point?
I also don't understand why it would be considered safe, in the
absence of a header checksum - are you deeming that the tunnel must
have error detection at layer 2?
Yes. As well as the low probably of bit-error rates, matching
sockets and mis-routing, all that would have to work in unison
to have a real problem.
Dino
--
to unsubscribe send a message to [EMAIL PROTECTED] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
--
to unsubscribe send a message to [EMAIL PROTECTED] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
