1.
No mention of v6 aware devices that haven't been configured for v6. One example
is acls on most routers have to be duplicated for v6. Firewall rules too. So it
isn't just a "can it support issue" but also a is it configured to examine v6
or other tunneled traffic.
Only in some exceptional cases (such as military operations networks)
could this approach to mitigating the aforementioned security
implications be thought of as a longer-term strategy.
I am not sure that is true. Some enterprise may very well be able to use just
v4 for quite a while especially internally. They might have to offer services
on v6 but via some hosting or other DMZ methods they may be able to keep their
internal network v4 for many more years.
3.6
The corresponding addresses can be easily obtained from a UNIX
host by issuing the command 'dig teredo.ipv6.microsoft.com a'
(without quotes).
dig isn't a "standard" unix tool. nslookup or host is in nearly all cases but
not all unix systems have dig installed by default. (nslookup is deprecated for
host but still fairly common if not universal).
How about nslookup since that is also on windows and other platforms?
4.
This:
This is likely to cause IPv6-capable hosts to attempt to
reach an ever-increasing number of popular destinations via IPv6,
even if this IPv6 connectivity is provided relies on a transition
technology over an IPv4-only network.
Should be this:
This is likely to cause IPv6-capable hosts to attempt to
reach an ever-increasing number of popular destinations via IPv6,
even if this IPv6 connectivity as provided relies on a transition
technology over an IPv4-only network.
Shouldn't this be NXD instead of dropping the requests. That way the client can
see it is getting errors not just blackholeing the aaaa requests?
For this reason, networks attempting to prevent IPv6 traffic from
traversing their devices should consider configuring their local
recursive DNS servers to ignore queries for AAAA DNS records, or even
consider filtering AAAA records at the network ingress point to
prevent end hosts from attempting their own DNS resolution.
That could also be done on a forwarder right not just a local recursive dns
server?
A firewall could signal the packet drop by means of an ICMPv6
error message (or TCP [RFC0793] RST segment if appropriate), such
that the source node can e.g. quickly react as described in
[RFC5461].
If there is no v6 connectivity I wouldn't expect icmpv6 to work and the queries
will usually be udp so a tcp resest is not valid.
I think therefore that NXD from dns server or icmpv4 from a middle box is
better. And I would change firewall to middle box since there are IPSes, UTM
devices, portals etc... that could be dropping the v6 queries.
(coffee != sleep) & (!coffee == sleep)
[email protected]
From: [email protected] [[email protected]] on behalf of Warren
Kumari [[email protected]]
Sent: Tuesday, January 22, 2013 1:17 PM
To: [email protected]; opsec chairs
Cc: Warren Kumari
Subject: Re: [OPSEC] WGLC on draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02
On Jan 10, 2013, at 11:28 AM, Warren Kumari <[email protected]> wrote:
> Hello OpSec!
>
> This starts a working group last call for
> draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02 -- "Security Implications
> of IPv6 on IPv4 Networks"
>
> The draft is available at
> http://tools.ietf.org/html/draft-ietf-opsec-ipv6-implications-on-ipv4-nets-02
> and
> https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-implications-on-ipv4-nets/
>
>
> Please review this draft to see if you think it is ready for publication.
> Send comments to the list.
>
> The WGLC will end on 25th January 2013.
This is a reminder to please provide feedback on this draft -- so far I do not
think we have enough feedback to call consensus.
Thanks to the folk we do have feedback from; Wes, Simon and Rama...
W
>
> --Warren, speaking as OpSec WG co-chair
>
>
> --
> I had no shoes and wept. Then I met a man who had no feet. So I said, "Hey
> man, got any shoes you're not using?"
>
>
> _______________________________________________
> OPSEC mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/opsec
>
--
The duke had a mind that ticked like a clock and, like a clock, it regularly
went cuckoo.
-- (Terry Pratchett, Wyrd Sisters)
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
