Subject: [v6ops] comments about draft-ietf-v6ops-enterprise-incremental-ipv6-01

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Sun, 16 Sep 2012 13:05:11 +0300

Generally i like the phased approach of this draft.

We have done similar phases in our own corporate network, although
not all sub-phases apply to us.

Here are my general comments...

3.6 should be moved in the beginning. Project (not program)
planning should be the first thing to do.

Security parts got me a little bit confused. There are things are
are repeated many times, although applicable at all of them.

Maybe put them under a general security section and just add
differences per phase.

Also it would be better if the security section was in the same
position at every phase (i.e. last or first).

I didn't see any reference (or better warning) on operational
costs vs needs. Introduction includes 1-2 sentences, but i don't
find them always applicable.

This may be an easy job for some networks, but in same cases it
will take time and effort...without having a good reason.

I understand that this might push back the willing of an
enterprise to move to IPv6, but every case should be examined
under a general umbrella.

An administrator might be considering IPv6 on his own, but this
doesn't necessarily apply to the whole enterprise.

I got the impressions throughout the text that translation is
preferred vs tunneling, something i agree with in most cases, and
especially in isp environments.

But there are many enterprises, where the tunneling approach might
be a better/easier/cheaper solution.

Lastly, until IPv6 is fully implemented into the enterprise, a
recommendation should be made about the expansion/maintenance of
IPv4 network/systems in such a way that the IPv6 deployment is
taken into account.

And some specific comments....

The most common drivers are due
to the fact that when Internet service providers, including mobile
wireless carriers, run out of IPv4 addresses, they will provide
native IPv6 and non-native IPv4.

I don't think most enterprises will fall under this type
(non-native IPv4) of connectivity.

ISPs are mostly facing issues with residential services in terms
of address availability.

The non-native IPv4 service may be
NAT64, NAT444, Dual-stack Lite, or other transition technology, but
whether tunneled or translated, the native traffic will be perform
better and more reliably than non-native.

This assumption poses questions whether all those
translation/tunneling solutions by IETF are worth considering.

Maybe add a probability factor there.

A specific case of congruence is the IPv6 ULA [RFC4193] and IPv4
private addressing [RFC1918] that do not provide any security by
'magic'. In both case, the edge router must apply strict data plane
and routing policy to block those private addresses to leave and
enter the network. This filtering can be done by the enterprise or
by the ISP.

IPv6 addresses can be spoofed as easily as IPv4 addresses and there
are packets with bogons IPv6 addresses (see [CYMRU]). The anti-bogon
filtering must be done in the data and routing planes. It can be
done by the enterprise or by the ISP.

case = > cases

edge router => border routers

Might want to rephrase "data" as "forwarding" or "routing" as
"control" in order to use common wording.

Some recommendations are expressed like "can be done by the
enterprise or by the ISP". I think it should be noted that the
enterprise should always try to do these, regardless of the ISP.
Ok, it might not be always easy for the enterprise to do these
(due to expertise, costs, etc), but i don't think the enterprise
should solely depend on the ISP doing these.

An alternative is to try to prevent the use
of privacy extension addresses is to send the Router Advertisement
with the M-bit set (to force the use of DHCPv6 to get an address) and
with all advertized prefixes without the A-bit set (to prevent the
use of stateless auto-configuration); this technique requires that
all hosts support stateful DHCPv6.

I think it's better to remove the M-bit reference and just refer
DHCPv6.

If i remember right, there was a talk about the M/O bits being
controversial lately

Another DoS
vulnerabilities are related to NDP cache exhaustion
([I-D.gashinsky-v6ops-v6nd-problems]) and they can be mitigated by
careful tuning of the NDP cache. In 2012, there are already several
vendors offering those features on their switches.

RFC 6583 proposes various options for mitigation of NDP issues; i
think a general reference should be made instead.

The enterprise administrator will want to evaluate whether the
enterprise will request address space from its ISP (or Local Internet
Registry (LIR)), or whether to request address space from the local
Internet Registry (whether a Regional Internet Registry such as
AfriNIC, APNIC, ARIN, LACNIC, or RIPE-NCC, or a National Internet
Registry, operated in some countries).

Probably it should be rewritten as

The enterprise administrator will want to evaluate whether the
enterprise will request address space from a LIR (Local Internet
Registry, such as an ISP), a RIR (Regional Internet Registry, such as
AfriNIC, APNIC, ARIN, LACNIC, or RIPE-NCC) or a NIR (National Internet Registry, operated in some countries).

Each location, no matter how small, should get at least a /48.

Does this apply to every enterprise?

Maybe add a reference to RFC6177 & RFC 5375?

All user access networks MUST be a /64. Point-to-point links without
MAC addresses (this is where Neighbor Discovery Protocol does not
run) SHOULD be a /127 (see also [RFC6164]).

Why a reference on mac-addresses? Can't ethernet p2p links use
/127?

Also, for any part of the network where
DNS (or reverse DNS) zones may be delegated, it is important to
delegate addresses on nibble boundaries (this is on a multiple of 4
bits), to ensure propose name delegation.

propose => proposed?

Maybe want to explain this a little bit more?

** Add some comment about setting MTU to 1280 to avoid tunnel pMTUd
black holes? **

Personally, i don't like the idea of setting the MTU to the
minimum. It's better to describe the issues and the importance of
ICMP/pMTUd and leave the MTU minimization as a last resort.

The security policies must be congruent for IPv4
and IPv6 (else the attacker will use the less protected protocol
stack) except that ICMPv6 messages must be allowed through and to the
filtering device (see [RFC4890]):

except that ICMPv6 messages => except that some ICMPv6 messages

The peering router must also implement anti-spoofing technique based
on [RFC2827].

What's a peering router in the enterprise? There is only a single
reference of it. Are you referring to border routers?

This includes the use of IP flow export
[RFC5102] to detect abnormal traffic pattern (such as port scanning,
SYN-flooding)

IP flow export => IP Flow Information eXport (IPFIX)

While
technology and process transformations are taking place is it
critical that people training takes place as well.

is it critical => it is critical

malevolent person has now two attack vectors: IPv4 and IPv6. This
simply means that all routers and hosts operating in a dual-stack
environment with both protocol families enabled (even if by default)
must have a congruent security policy for both protocol version.

version => versions

There may be a registration
fee for requesting provider-independent (PI) space from and NIR/RIR,

and => a

In the case of PI, the organization will need to support BGP based
connectivity for the most part since the address space is assigned
direction from the Regional Registry to the local network.

direction => directly

Native IPv6
connectivity is preferred since it provides the most rebuts form of
connectivity.

rebuts => robust ?

--
Tassos

---

From: KK <[email-masked]>
Date: Sun, 23 Sep 2012 17:17:08 -0700

Tassos,

Thank you very much for your detailed feedback and apologies for the
delayed response.

There are many good points that you raise here. We will go through these
individually and come back to you with further clarifications as we
incorporate your suggested changes in the next rev.

Regards,
KK

On Sun, Sep 16, 2012 at 3:05 AM, Tassos Chatzithomaoglou <
[email-masked]> wrote:

> We have done similar phases in our own corporate network, although not all
> sub-phases apply to us.
>
> 3.6 should be moved in the beginning. Project (not program) planning
> should be the first thing to do.
>
> Security parts got me a little bit confused. There are things are are
> repeated many times, although applicable at all of them.
> Maybe put them under a general security section and just add differences
> per phase.
> Also it would be better if the security section was in the same position
> at every phase (i.e. last or first).
>
> I didn't see any reference (or better warning) on operational costs vs
> needs. Introduction includes 1-2 sentences, but i don't find them always
> applicable.
> This may be an easy job for some networks, but in same cases it will take
> time and effort...without having a good reason.
> I understand that this might push back the willing of an enterprise to
> move to IPv6, but every case should be examined under a general umbrella.
> An administrator might be considering IPv6 on his own, but this doesn't
> necessarily apply to the whole enterprise.
>
> I got the impressions throughout the text that translation is preferred vs
> tunneling, something i agree with in most cases, and especially in isp
> environments.
> But there are many enterprises, where the tunneling approach might be a
> better/easier/cheaper solution.
>
> recommendation should be made about the expansion/maintenance of IPv4
> network/systems in such a way that the IPv6 deployment is taken into
> account.
>
>
>  I don't think most enterprises will fall under this type (non-native
> IPv4) of connectivity.
> ISPs are mostly facing issues with residential services in terms of
> address availability.
>
>
>  This assumption poses questions whether all those translation/tunneling
> solutions by IETF are worth considering.
>    A specific case of congruence is the IPv6 ULA [RFC4193 <http://tools.ietf.org/html/rfc4193>] and IPv4
>    private addressing [RFC1918 <http://tools.ietf.org/html/rfc1918>] that do not provide any security by
>    are packets with bogons IPv6 addresses (see [CYMRU <http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6-01#ref-CYMRU>]).  The anti-bogon
> Might want to rephrase "data" as "forwarding" or "routing" as "control" in
> order to use common wording.
>
> Some recommendations are expressed like "can be done by the enterprise or
> by the ISP". I think it should be noted that the enterprise should always
> try to do these, regardless of the ISP. Ok, it might not be always easy for
> the enterprise to do these (due to expertise, costs, etc), but i don't
> think the enterprise should solely depend on the ISP doing these.
>
>  I think it's better to remove the M-bit reference and just refer DHCPv6.
>    ([I-D.gashinsky-v6ops-v6nd-problems <http://tools.ietf.org/html/draft-ietf-v6ops-enterprise-incremental-ipv6-01#ref-I-D.gashinsky-v6ops-v6nd-problems>]) and they can be mitigated by
>  RFC 6583 proposes various options for mitigation of NDP issues; i think a
> general reference should be made instead.
>
>
>    run) SHOULD be a /127 (see also [RFC6164 <http://tools.ietf.org/html/rfc6164>]).
>
>
> Why a reference on mac-addresses? Can't ethernet p2p links use /127?
>
>
>
> Personally, i don't like the idea of setting the MTU to the minimum. It's
> better to describe the issues and the importance of ICMP/pMTUd and leave
> the MTU minimization as a last resort.
>
>    filtering device (see [RFC4890 <http://tools.ietf.org/html/rfc4890>]):
>
>
>    on [RFC2827 <http://tools.ietf.org/html/rfc2827>].
>
>
>    [RFC5102 <http://tools.ietf.org/html/rfc5102>] to detect abnormal traffic pattern (such as port scanning,
>    SYN-flooding)
>
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>