Subject: Re: [renum] New Version Notification for draft-jiang-6renum-enterprise-01.txt

From: Teco Boot <[email-masked]>
Date: Mon, 14 Nov 2011 00:18:27 +0100

Some comments made browsing this doc.

Page 7:
>       In principle, an enterprise network should choose only one address
>       configuration model and employ either ND or DHCPv6

Even if DHCPv6 is chosen, ND must be deployed. Please use SLAAC instead if ND.
IMHO the recommendation above is much to strong. It will occur, also stated just below it:
>       Combinations of address configuration models may coexist within a
>       single enterprise network.

Page 8:
>       Often, a small site depends on its ISP's DNS system rather than
>       maintaining its own. When renumbering, this requires
>       administrative coordination between the site and its ISP.
Is this in scope of enterprises?
Do you mean using the ISP DNS service to administer name-address relations with addresses associated with other ISPs?
IMHO an enterprise could use an DNS-SP. Such service shall not impose restrictions on registered addresses.

> - Security	

Only SeND and Secure DHCPv6 are suggested as remedy for session hijacking. What about attackers outside the link / DHCPv6-path?

Page 9:
>    It is not possible to reduce a prefix's lifetime to below two hours.

It is possible, e.g. using SeND.

>       Long-lifetime addresses may cause issues for renumbering events.
>       Particularly, some offline hosts may reconnect using these
>       addresses after renumbering events.

I don't get this.

Page 11:
>       - Border filtering
>       In a multihomed site, an egress router to ISP A could normally
>       filter packets with source addresses from other ISPs. The egress
>       router connecting to ISP A should be notified if the egress router
>       connecting to ISP B initiates a renumbering event in order to
>       properly update its filter function.

I don't get this. Isn't ingress filtering recommended? Do ISP A and B coordinate? IMHO an ISP should block packets with other ISPs PA addresses.
So the network has to forward packets with ISP_A source addresses to ISP_A, not ISP_B. And forward packets with ISP_B source addresses to ISP_B, not ISP_A.

>       However, the upper layer sessions may survive by
>       using session survivability technologies, such as SHIM6 [RFC5533].

I suggest adding MPTCP, because it deals with renumbering quite good. 

Teco.

Op 30 sep. 2011, om 08:37 heeft Leo Liu(bing) het volgende geschreven:

> Hi, all
> 
> The enterprise scenarios document has been updated, please comment.
> Thanks a lot.
> 
> http://tools.ietf.org/html/draft-jiang-6renum-enterprise-01
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Friday, September 30, 2011 2:29 PM
> To: Leo Liu(bing)
> Cc: [email-masked]; Leo Liu(bing); Sheng Jiang
> Subject: New Version Notification for draft-jiang-6renum-enterprise-01.txt
> 
> A new version of I-D, draft-jiang-6renum-enterprise-01.txt has been successfully submitted by Bing Liu and posted to the IETF repository.
> 
> Filename:	 draft-jiang-6renum-enterprise
> Revision:	 01
> Title:		 IPv6 Enterprise Network Renumbering Scenarios and Guidelines
> Creation date:	 2011-09-29
> WG ID:		 Individual Submission
> Number of pages: 16
> 
> Abstract:
>   This document analyzes enterprise renumbering events and describes
>   the best current practice among the existing renumbering mechanisms.
>   According to the different stages of renumbering events,
>   considerations and best current practices are described in three
>   categories: during network design, for preparation of renumbering,
>   and during a renumbering operation. A gap inventory is listed at the
>   end of this document.
> 
> 
> 
> 
> The IETF Secretariat
> _______________________________________________
> renum mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/renum

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Nov 2011 13:32:35 +1300

>> >       addresses after renumbering events.

Maybe this is referring to static manual addresses?  I agree it should
be more specific in describing the problem.

...
> So the network has to forward packets with ISP_A source addresses to ISP_A, not ISP_B. And forward packets with ISP_B source addresses to ISP_B, not ISP_A.

I think the text you quote is confused; it is not the enterprise's egress
routers that do the filtering, but the ISPs' ingress routers.

Then there's another discussion. A large enterprise running multiple PA prefixes
would surely tell *all* its ISPs about those prefixes, and expect them to
relax their ingress filters accordingly. A small enterprise probably couldn't
do that, so needs two things:

1. Address pair selection in the hosts that avoids this problem.
2. Egress router selection based on source address.

In any case the renumbering issue is how to inform all your ISPs of the
new prefix to be allowed in their ingress filters, and the old prefix
that is now to be blocked.

   Brian

---

From: Teco Boot <[email-masked]>
Date: Mon, 14 Nov 2011 02:41:13 +0100

> that is now to be blocked.

I don't see ISPs relax the PA ingress filters. I say routing shall better support multi-homing, it is needed for small enterprises (point 2 above). Large enterprises may have many PA prefixes, so needed there also.

RFC 3704 section 4.3 describes some options for directing packets to the correct ISP. It says "This is not a complicated procedure", but the approach looks clumsy to me. The problem should be tackled at the root, a fix in routing. Get this into gap-analysis document?

PS1: On solutions, not to mention BRDP-based routing: check draft-baker-fun-routing-class.
PS2: I understand it will take some time before this is fixed. But that is no excuse to postpone.

Teco.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Nov 2011 15:16:08 +1300

> I don't see ISPs relax the PA ingress filters. 

They will (and do) do it for large customers, just as they will
(and do) announce backup routes for large customers. You just need to
give them enough millions of currency units...

I agree with you for smaller enterprise customers; the only question
is how much of this belongs in the gap analysis for renumbering.
See draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat.

Regards
   Brian

---

From: Teco Boot <[email-masked]>
Date: Mon, 14 Nov 2011 04:33:36 +0100

> give them enough millions of currency units...

So a solution is needed for *poor* enterprises :-)

> See draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat.

I read this doc as it is applicable for small networks, not for enterprises. I'm fine referring to another doc that describes the gap. Extend draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat for (small or poor) enterprises having a multi-hop network running a routing protocol?

Teco