anyway.
--
Rémi Denis-Courmont
http://www.remlab.info/
http://fi.linkedin.com/in/remidenis
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
are eliminated.
The IETF Secretariat.
--
Rémi Denis-Courmont
http://www.remlab.net/
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
multiple interfaces in the
host?
No.
--
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman
protocol would handle it properly
anyway.
--
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman
that don't use SYN-cookies now-a-days?
IIRC, recent Linux kernel version have SYN-cookies disabled by default as
they were found to make things often worse rather than better.
--
Rémi Denis-Courmont
IETF IPv6 working group mailing
. I am not a network gear
vendor or operator myself.
--
Rémi Denis-Courmont
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
. And that's simply not going to
happen. So basically, HBH is only useful in the mythical walled garden
networks.
--
Rémi Denis-Courmont
http://www.remlab.net/
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests
, I encourage other people on the list to verify the attacks in
different scenarios.
I managed to reproduce it. Single-homed NATs have absolutely no excuse in
forwarding a packet with their own IP address as the source. But yeah -
there is a problem.
--
Rémi Denis-Courmont
that it *does* affect Linux-based in the sense that a non-privileged
local user could screw up (an unlikely scenario on a Teredo server, anyway).
I'm now trying to verify attack D.
--
Rémi Denis-Courmont
http://www.remlab.net
. The system will drop the packet, and
the application will mysteriously not receive anything.
Silent failures are the most harmful kind of failures to me.
And to me too, but I don't see any silent failure here.
--
Rémi Denis-Courmont
Nokia Devices RD, Maemo Software, Helsinki
translators are largely
deployed.
No. By doing this, people will experience odd failure modes and weird error
reports during the long transition period for IPv6 stacks to accept checksum-
less packets.
Harm very much expected.
--
Rémi Denis-Courmont
Nokia Devices RD, Maemo Software, Helsinki
Le mardi 4 août 2009 22:01:01 Margaret Wasserman, vous avez écrit :
On Jul 31, 2009, at 3:06 AM, Rémi Denis-Courmont wrote:
is basically UDP except the checksum would only covering the IPv6 and
transport header. Hmmph, this is just like UDP-Lite really but it
seems
like
Le mardi 4 août 2009 22:42:12 Margaret Wasserman, vous avez écrit :
On Aug 3, 2009, at 5:15 PM, Rémi Denis-Courmont wrote:
(1) UDP-Lite: Is there a reason why UDP-Lite isn't a reasonable
choice for LISP encapsulation? When we looked into this for CAPWAP
(another IP-in-UDP/IP tunneling
just like UDP-Lite with 8-bytes
coverage.
--
Rémi Denis-Courmont
Nokia Devices RD, Maemo Software, Helsinki
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
there is opposition to overloading UDP-Lite. Then the 64-translators
would convert it to normal UDP/IPv4... ?
--
Rémi Denis-Courmont
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman
network-side filtering as is
done for ARP instead, as it requires no host-side changes.
I don't think it deserves a SHOULD at this point.
--
Rémi Denis-Courmont
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative
implying that this is possible or impossible or anything
- but I think it belongs in the draft or in a companion draft thereto.
Also, it might be worth to have an socket API consideration appendix...
--
Rémi Denis-Courmont
IETF IPv6
of struct
addrinfo. But I can only hope that RFC3484 update won't render this
inadequate :-/ Who knows what people will want to put into source address
selection algorithms in the future?
--
Rémi Denis-Courmont
IETF IPv6
?
That is a matter of implementation and use cases. I think the 6man mailing
list is not the right venue to discuss this.
--
Rémi Denis-Courmont
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https
. I am not
very keen on the idea that we would update the spec in a way that will cause
plenty of dummy errors to be logged by legacy IPv6 stacks. FYI, at least the
Linux kernel falls in this case.
--
Rémi Denis-Courmont
IETF
a reasonable time
frame.
--
Rémi Denis-Courmont
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Secretariat.
--
Rémi Denis-Courmont
Maemo Software, Nokia Devices RD
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
, if it
has no screen, for instance a home router. This is quite common for
broadband fixed access.
Unless the RIR mandate a minimum delegated prefix size in adequate
scenarios, we may have a big problem.
--
Rémi Denis-Courmont
network standard?
(I heard some rumors thereabout)
--
Rémi Denis-Courmont
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Header seems to be in a similar situation. If I understand the
problem, only Dst header and HbH header are broken, no?
Regards,
--
Rémi Denis-Courmont
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests
? AFAIK,
Linux Netfilter would class the packet as INVALID in this case.
I don't suppose this nullifies the attack, but the example looks rather
like a bad one.
--
Rémi Denis-Courmont
IETF IPv6 working group mailing list
ipv6
allow the packet due to optimizations.
--
Rémi Denis-Courmont
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
or updated.
IMHO, the real problem is that the various documents that added/removed
special address ranges failed to appropriately UPDATE RFC3484... I'm
thinking about Teredo, ULA, site-local deprecation and ORCHID here, but I may
be missing some others.
--
Rémi Denis-Courmont
embedded C run-times.
These two issues are different, though they effectively have the same result:
favor IPv6 over IPv4, when IPv4 should be favored over IPv6 (IMHO).
--
Rémi Denis-Courmont
IETF IPv6 working group mailing list
intra-domain routing protocol
may be adaptable.
Given the current size and churn of the routing tables, is this at all
practical?
--
Rémi Denis-Courmont
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative
, this mailing list is about maintaining
the IPv6 protocol, not extending it (anymore).
--
Rémi Denis-Courmont
http://www.remlab.net/
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1
On Thursday 26 July 2007 22:01:33 Brian Haberman wrote:
Yup. What about maintenance of existing non-core specifications, by the
way?
Do you have an example of such a specification you are worried about?
Teredo's one that showed up at v6ops meeting.
--
Rémi Denis-Courmont
of existing non-core specifications, by the way?
--
Rémi Denis-Courmont
Nokia software specialist
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
had
no particular meaning on non ISATAP links.
Or perhaps, is the intent merely to avoid human confusion?
--
Rémi Denis-Courmont
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org
parsing RH0 at that level as well?
--
Rémi Denis-Courmont
http://www.remlab.net/
signature.asc
Description: This is a digitally signed message part.
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https
?
Thanks in advance.
--
Rémi Denis-Courmont
http://www.remlab.net/
signature.asc
Description: This is a digitally signed message part.
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1
they would
still have to parse skip through inner IP header in order to reach the
transport header.
Therefore, I think it is totally pointless, and it definitely is NOT
a fix.
--
Rémi Denis-Courmont
http://www.remlab.net/
signature.asc
Description: This is a digitally signed message part
On Thu, 14 Jun 2007 17:09:09 -0700, Thomas Narten [EMAIL PROTECTED]
wrote:
I'm slightly concerned that such advice flies in the face of
conventional advice given to those constructing firewall policy. It
is normal practice, I believe, for end-site firewall policy to be
deployed based on
Denis-Courmont
http://www.remlab.net/
signature.asc
Description: This is a digitally signed message part.
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
of their perimeter. There are seldom
responsible for new technology not working out of the box. It's a
truth, we'd rather adapt to, if we can.
My 2 eurocents,
--
Rémi Denis-Courmont
http://www.remlab.net/
IETF IPv6 working group
is setsockopt(IPV6_RTHDR) supposed to return for type 0?
--
Rémi Denis-Courmont
http://www.remlab.net/
pgptug7pyjSSI.pgp
Description: PGP signature
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1
have a semantic.
--
Rémi Denis-Courmont
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
have to setsockopt() in addition to getaddrinfo(), and
don't have to do source address selection twice (once in getaddrinfo
and once in connect).
But I understand that way beyond the scope of this document.
--
Rémi Denis-Courmont
http://www.remlab.net
where you just pass socket handles through different layers,
and simply cannot pass anything else without large changes).
--
Rémi Denis-Courmont
http://www.remlab.net/
pgpVMkVczhtKj.pgp
Description: PGP signature
IETF IPv6 working
for a rationale for as long,
and still haven't received any sane answer. I really don't understand
why you stick that hard to a broken design. In terms of spec work, it's
very easy to fix; in fact, it would most likely make the spec shorter.
--
Rémi Denis-Courmont
http://www.remlab.net/
pgpkhG28TGhGZ.pgp
Denis-Courmont
http://www.remlab.net/
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
merely moves the
problem away from DNS to Neighbor Discovery, but does not solve the
core issue at all, which is that some kind of multicast/broadcast is
needed for non-point-to-point IPv6 links.
--
Rémi Denis-Courmont
http://www.remlab.net
?
--
Rémi Denis-Courmont
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
to use a possible
value for that.
The IETF thought otherwise in may 2003.
Have you had a look at RFC3542 at all? (hint: §6.3 and §6.5)
--
Rémi Denis-Courmont
looking for a job
http://www.simphalempin.com/home/infos/CV-en.pdf
IETF
think that it is much nicer than partially breaking the ABI by
changing the size of structure.
--
Rémi Denis-Courmont
pgp2GogNCrRjc.pgp
Description: PGP signature
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative
,
--
Rémi Denis-Courmont,
looking for a job
http://www.simphalempin.com/home/infos/CV-en.pdf
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
getsockopt() before setsockopt().
Regards,
PS: sorry about the earlier sendmsg() note, I see it's addressed in an
appendix already.
--
Rémi Denis-Courmont
looking for a job
http://www.simphalempin.com/home/infos/CV-en.pdf
IETF
options to the existing ones (plus depleting the IP
protocols number might not be such a godd idea). But I guess I'm missing
something.
Regards,
--
Rémi Denis-Courmont
http://www.remlab.net/
IETF IPv6 working group mailing list
application scope independent. Is it a bug in linux kernal?
I don't think so.
--
Rémi Denis-Courmont
http://www.remlab.net/
pgpwmRlZYQZoZ.pgp
Description: PGP signature
IETF IPv6 working group mailing list
ipv6@ietf.org
rather than
host-wide, such as through a new flag for
getaddrinfo()'s “hints.ai_flags”.
--
Rémi Denis-Courmont
pgpVlZ47J4Ul9.pgp
Description: PGP signature
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative
they might be
caveats that I've not thought of.
--
Rémi Denis-Courmont
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Le Dimanche 14 Mai 2006 17:44, vous avez écrit :
El 13/05/2006, a las 12:14, Rémi Denis-Courmont escribió:
There are possibly more troublesome issues:
1/ how to handle UDP, which is also supported by getaddrinfo(), and
has more varied usages (not just socket() then connect
.
--
Rémi Denis-Courmont
http://www.simphalempin.com/home/
pgphSO0OyqELs.pgp
Description: PGP signature
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
MUST be defined
before connect()/bind(), but obviously after socket()? it is my
understanding that a wrapper as the one hereby suggested would hide
socket() AND connect() within a single API call.
--
Rémi Denis-Courmont
http://www.simphalempin.com/home/
pgpfQLYWjMY3W.pgp
Description: PGP
IPv6
address while its socket is bound to an ULA or while the host has no
global (or at least has no non-ULA-nor-link-local) addresses?
--
Rémi Denis-Courmont
http://www.simphalempin.com/home/
pgpBe0BzCpzGI.pgp
Description: PGP signature
... in fact, whenever one uses IPv6-mapped IPv4 addresses.
--
Rémi Denis-Courmont
http://www.simphalempin.com/home/
pgp69jHE77r72.pgp
Description: PGP signature
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative
61 matches
Mail list logo
