Subject: [v6ops] Fwd: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians?

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 11 Jul 2012 16:48:29 +0000

FYI, in case you had not seen it.

> From: Chris Welti <[email-masked]>
> Date: July 11, 2012 9:41:22 AM PDT
> To: <[email-masked]>
> Subject: RIPE-555 fundamentaly changes the way how we can filter IPv6 & IPv4 martians?
> 
> Dear IPv6 (and IPv4) network operators
> 
> RIPE has recently published RIPE-555 (Address space managed by the RIPE NCC), which
> replaces RIPE-510.
> 
> With RIPE-510 (http://www.ripe.net/ripe/docs/ripe-510), it was quite clear that
> all IPv6 address allocations smaller than a /32 (longer prefixes) were coming out of
> just a few special ranges:
> a) Internet Exchange Points: up to /64 out of 2001:7f8::/32
> b) Root Name Servers: up to /64 out of 2001:7f8::/29
> c) Anycasting TLD nameservers: /48 out of 2001:678::/29
> d) IPv6 PI address space: up to /64 out of 2001:678::/29
> 
> Now, the new document RIPE-555 (http://www.ripe.net/ripe/docs/ripe-555), drops all
> these special ranges except for IPv6 PI space.
> 
> The section Longest Prefix Tables, which always included a list of IPv4 & IPv6 prefix
> ranges and their longest allocated or assigned prefix in that range has been
> drastically reduced to just read as follows:
> 
> "The smallest prefix assigned by the RIPE NCC from any IPv4 range is a /29.
> The smallest prefix assigned by the RIPE NCC from any IPv6 range is a /48."
> 
> Additionally the section "Routing decisions" has been adjusted to just say:
> "Routing decisions are the responsibility of network operators".
> The sentence "Network operators taking routing decisions based on prefix length
> are requested and encouraged to route at least blocks of sizes corresponding to
> the longest prefix and larger"
> 
> In the past we have used RIPE-510 and its predecessors as a basis for our martian
> filters, where we deny prefixes that are longer than the minimum allocation sizes
> for a particular address range allocated/assigned by RIPE.
> 
> To me as an operator this raises the question on how I should now filter martians for
> the RIPE region?
> Since I can not rely on the fact that longer prefix lengths just happen in
> certain well defined ranges (minimum allocation per address range) anymore,
> I see only three possibilites:
> 
> 1) Generate a prefix-list out of
> ftp://ftp.ripe.net/pub/stats/ripencc/delegated-ripencc-extended-latest
> which includes all valid allocated/assigned IPv4 and IPv6 prefixes. Then only accept
> those prefixes. That list would contain hundreds of thousands of entries and would have
> to be built at least daily, so newly allocated prefixes can be properly accepted.
> 
> 2) Just filter out prefixes that are longer than /48 for v6 and longer than /29
> for v4 and keep all the rest.
> 
> 3) Still filter the way we did before and risk that new "valid" longer prefix allocations
> are not accepted.
> 
> Option 1 is not really feasible due to the huge size of the prefix-list
> 
> Option 2 means that basically I'm opening up the possibility for accidential (leaks)
> or purposeful (traffic engineering) leaks of potentially 65535 /48 v6 prefixes per /32,
> and there are a lot of possible /32s :)
> Even though it's less for v4 it's still a couple of millions of /29 v4 prefixes
> That could result in a lot of addresses in the routing table!
> 
> Option 3 also does not sound like a good idea, as that would lead to holes in the routing
> table.
> 
> Similar concerns have also been raised by my colleague Alex on the [ncc-services-wg] list
> but so far nobody else has chimed in.
> 
> So how and on what basis do you create your martian filters?
> Or is this a non-issue for you?
> 
> Best regards,
> Chris / AS559
> 
> SWITCH
> Serving Swiss Universities
> --------------------------
> Chris Welti, Network Engineer
> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
> phone +41 44 268 15 30, fax +41 44 268 15 68
> [email-masked]
> http://www.switch.ch

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 11 Jul 2012 19:30:24 +0200 (CEST)

>> d) IPv6 PI address space: up to /64 out of 2001:678::/29

Just as FYI, I have been in contact with RIPC NCC staff. Some 
clarifications might be in order:

Root name servers are /32s now. IXP networks might still be affected by a 
simplified filtering policy of allowing /48 out of 2001:678::/29 and /32 
out of rest of RIPE space, but personally I don't think IXP networks 
should be world reachable, but that's a different discussion I guess.

Not touching the IPv4 part of the message...

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Turchanyi Geza <[email-masked]>
Date: Wed, 11 Jul 2012 19:57:48 +0200

> > RIPE has recently published RIPE-555 (Address space managed by the RIPE
----

> > the longest prefix and larger"

---

There were several people, including me, that openly argued against some
new RIPE policies that neglect the consecquences at the routing level,
however, there is a noisy minority acting at the RIPE policy working group,
overlooking reasonable arguments.

Perhaps we should return to these questions against.

Many thanks Chris, for your comments!

Géza

---

From: Gert Doering <[email-masked]>
Date: Wed, 11 Jul 2012 20:25:07 +0200

Hi,

> overlooking reasonable arguments.

*sigh*.  This really shouldn't be here, but I can't let it stand as it is.

<RIPE politics>
We had broad support in the RIPE address policy working group to change 
some requirements on IPv6 PI assignments (namely removing the "multihoming 
requirements", which were ill-defined to begin with), with a "noisy 
minority", mostly consisting of Geza, objecting against this.

Now going around and claiming that this was a "noisy minority acting at
the RIPE policy working group" is twisting reality somewhat - it was
"significantly more voices supporting the proposal than objecting",
and that's "rough consensus" - and the arguments were FUD-based, not
"reasonable".

All of this happened openly on the RIPE address policy working group
mailing list, which has a public archive, so everyone can make up their
own mind of the situation.
</>

OTOH, the address policy WG had nothing to do with the change of RIPE-510 
to RIPE-555, and I'm still considering whether I see this as a matter-of-fact
declaration (as soon as IPv4 runs out, every sort of minimum allocation
size for individual /8s is moot, as people will want all the scraps and
bits left over), or as a problem.  

For IPv6, I'm not not exactly happy with the way it is written now, 
implying that /48s could be assigned from anywhere in the address space.  
But then, upstreams really should filter their customers by IRR or RPKI, 
and not "by prefix ranges", as someone malevolent could do enough harm 
by announcing a million /32s which would pass anyone's "/32s permitted 
from RIR /12 ranges" filters just fine...

Gert Doering
        -- address policy WG chair *and* network operator
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Jul 2012 19:36:13 +0100

But Gert, wearing your "network operator" hat, aren't you worried
about the long-term impact on your routing costs of what is effectively
a free-for-all policy on long prefixes?

I mean, that is why people invented CIDR and aggregation in the first
place.

   Brian

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Wed, 11 Jul 2012 18:55:53 +0000

On Jul 11, 2012, at 10:57 AM, Turchanyi Geza wrote:

> There were several people, including me, that openly argued against some new RIPE policies that neglect the consecquences at the routing level, however, there is a noisy minority acting at the RIPE policy working group, overlooking reasonable arguments.

There have been calls in the past for the IETF to make recommendations to the RIRs on such policy. One of the proposals, if memory serves, was to recommend that service providers filter prefixes longer than /48, and another was that they filter prefixes longer than were allocated by the RIR in question or the IANA. The general comment was to shout the suggestion down: "that's for the RIR communities to comment on, not the IETF".

If I understand the dialog here (and no, I'm not involved in RIPE Policy), it sounds like there might be value in comments on the architectural implications of policy decisions on routing.

If I were to make a filtering proposal, I might look at the RPKI work. I could imagine an RPKI database maintained by an RIR having a key for each allocated prefix and each aggregated prefix (e.g., I could imagine Europe and the Americas routing to "APNIC prefixes" as an aggregated class, and only to more specifics within or close to the Asia Pacific region), and a recommendation from v6ops to the effect that an ISP should filter to prefixes that are in the RPKI database (and attested to by it) barring specific business requirements; deaggregation by a business partner acceptable to a given network might be an example of a business requirement, as would acceptance of the announcement of a specific ULA. I could also imagine the RIR offering a service to a network that wants to deaggregate, that would allow it to file signed keys for the more specific prefixes it wants to announce.

I could also imagine the operators in the room saying "that's why we don't want advice from the IETF" :-)

Question for the accumulated folks "in the room": Is the architectural implications of routing and filtering policy an appropriate topic to invite a draft concerning? If so, who might constitute an appropriate design team?

Documents relevant to RPKI:

https://tools.ietf.org/html/rfc6382
6382 Unique Origin Autonomous System Numbers (ASNs) per Node for
     Globally Anycasted Services. D. McPherson, R. Donnelly, F. Scalzo.
     October 2011. (Format: TXT=25224 bytes) (Also BCP0169) (Status: BEST
     CURRENT PRACTICE)

https://tools.ietf.org/html/rfc6472
6472 Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP. W.
     Kumari, K. Sriram. December 2011. (Format: TXT=10673 bytes) (Also
     BCP0172) (Status: BEST CURRENT PRACTICE)

https://tools.ietf.org/html/rfc6480
6480 An Infrastructure to Support Secure Internet Routing. M.
     Lepinski, S. Kent. February 2012. (Format: TXT=62127 bytes) (Status:
     INFORMATIONAL)

https://tools.ietf.org/html/rfc6481
6481 A Profile for Resource Certificate Repository Structure. G.
     Huston, R. Loomans, G. Michaelson. February 2012. (Format: TXT=36117
     bytes) (Status: PROPOSED STANDARD)

https://tools.ietf.org/html/rfc6482
6482 A Profile for Route Origin Authorizations (ROAs). M. Lepinski, S.
     Kent, D. Kong. February 2012. (Format: TXT=15745 bytes) (Status:
     PROPOSED STANDARD)

https://tools.ietf.org/html/rfc6483
6483 Validation of Route Origination Using the Resource Certificate
     Public Key Infrastructure (PKI) and Route Origin Authorizations
     (ROAs). G. Huston, G. Michaelson. February 2012. (Format: TXT=19811
     bytes) (Status: INFORMATIONAL)

https://tools.ietf.org/html/rfc6484
6484 Certificate Policy (CP) for the Resource Public Key
     Infrastructure (RPKI). S. Kent, D. Kong, K. Seo, R. Watro. February
     2012. (Format: TXT=77855 bytes) (Also BCP0173) (Status: BEST CURRENT
     PRACTICE)

https://tools.ietf.org/html/rfc6485
6485 The Profile for Algorithms and Key Sizes for Use in the Resource
     Public Key Infrastructure (RPKI). G. Huston. February 2012. (Format:
     TXT=11377 bytes) (Status: PROPOSED STANDARD)

https://tools.ietf.org/html/rfc6486
6486 Manifests for the Resource Public Key Infrastructure (RPKI). R.
     Austein, G. Huston, S. Kent, M. Lepinski. February 2012. (Format:
     TXT=42913 bytes) (Status: PROPOSED STANDARD)

https://tools.ietf.org/html/rfc6487
6487 A Profile for X.509 PKIX Resource Certificates. G. Huston, G.
     Michaelson, R. Loomans. February 2012. (Format: TXT=69150 bytes)
     (Status: PROPOSED STANDARD)

https://tools.ietf.org/html/rfc6488
6488 Signed Object Template for the Resource Public Key Infrastructure
     (RPKI). M. Lepinski, A. Chi, S. Kent. February 2012. (Format:
     TXT=25130 bytes) (Status: PROPOSED STANDARD)

https://tools.ietf.org/html/rfc6489
6489 Certification Authority (CA) Key Rollover in the Resource Public
     Key Infrastructure (RPKI). G. Huston, G. Michaelson, S. Kent.
     February 2012. (Format: TXT=23060 bytes) (Also BCP0174) (Status: BEST
     CURRENT PRACTICE)

https://tools.ietf.org/html/rfc6490
6490 Resource Public Key Infrastructure (RPKI) Trust Anchor Locator.
     G. Huston, S. Weiler, G. Michaelson, S. Kent. February 2012. (Format:
     TXT=15004 bytes) (Status: PROPOSED STANDARD)

https://tools.ietf.org/html/rfc6491
6491 Resource Public Key Infrastructure (RPKI) Objects Issued by IANA.
     T. Manderson, L. Vegoda, S. Kent. February 2012. (Format: TXT=23662
     bytes) (Status: PROPOSED STANDARD)

https://tools.ietf.org/html/rfc6492
6492 A Protocol for Provisioning Resource Certificates. G. Huston, R.
     Loomans, B. Ellacott, R. Austein. February 2012. (Format: TXT=65896
     bytes) (Status: PROPOSED STANDARD)

https://tools.ietf.org/html/rfc6493
6493 The Resource Public Key Infrastructure (RPKI) Ghostbusters
     Record. R. Bush. February 2012. (Format: TXT=15491 bytes) (Status:
     PROPOSED STANDARD)

https://tools.ietf.org/html/rfc6494
6494 Certificate Profile and Certificate Management for SEcure
     Neighbor Discovery (SEND). R. Gagliano, S. Krishnan, A. Kukec.
     February 2012. (Format: TXT=26425 bytes) (Updates RFC3971) (Status:
     PROPOSED STANDARD)

http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-ltamgmt
http://tools.ietf.org/html/draft-ietf-sidr-rpki-ltamgmt
  "Local Trust Anchor Management for the Resource Public Key
  Infrastructure", Stephen Kent, Mark Reynolds, 9-Jul-12

http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr
http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr
  "The RPKI/Router Protocol", Randy Bush, Rob Austein, 2-Feb-12

  "Definitions of Managed Objects for the RPKI-Router Protocol", Randy
  Bush, Bert Wijnen, Keyur Patel, Michael Baer, 26-Mar-12

  "RPKI Router Implementation Report", Randy Bush, Rob Austein, Keyur
  Patel, Hannes Gredler, Matthias Waehlisch, 27-Mar-12

http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr
http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr
  "The RPKI/Router Protocol", Randy Bush, Rob Austein, 2-Feb-12

  "Definitions of Managed Objects for the RPKI-Router Protocol", Randy
  Bush, Bert Wijnen, Keyur Patel, Michael Baer, 26-Mar-12

  "RPKI Router Implementation Report", Randy Bush, Rob Austein, Keyur
  Patel, Hannes Gredler, Matthias Waehlisch, 27-Mar-12

http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-impl
http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-impl
  "RPKI Router Implementation Report", Randy Bush, Rob Austein, Keyur
  Patel, Hannes Gredler, Matthias Waehlisch, 27-Mar-12

http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-impl
http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-impl
  "RPKI Router Implementation Report", Randy Bush, Rob Austein, Keyur
  Patel, Hannes Gredler, Matthias Waehlisch, 27-Mar-12

http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-protocol-mib
http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-protocol-mib
  "Definitions of Managed Objects for the RPKI-Router Protocol", Randy
  Bush, Bert Wijnen, Keyur Patel, Michael Baer, 26-Mar-12

http://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-protocol-mib
http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-protocol-mib
  "Definitions of Managed Objects for the RPKI-Router Protocol", Randy
  Bush, Bert Wijnen, Keyur Patel, Michael Baer, 26-Mar-12

http://datatracker.ietf.org/doc/draft-ymbk-rpki-grandparenting
http://tools.ietf.org/html/draft-ymbk-rpki-grandparenting
  "Responsible Grandparenting in the RPKI", Randy Bush, 29-Jun-12

---

From: David Farmer <[email-masked]>
Date: Wed, 11 Jul 2012 14:24:42 -0500

> There have been calls in the past for the IETF to make recommendations to the RIRs on such policy. One of the proposals, if memory serves, was to recommend that service providers filter prefixes lo…

I think the real problem is that the IETF is leaving it up to the RIRs. 
  The RIRs claim no charter or ability to control routing policy only 
allocation policy.  Many of the same people who shout down the IETF 
involving itself in the issue, also shout down the RIRs involving 
themselves in the issue.

So as it stands no one seems to claim responsibility for routing policy 
other than the operators themselves.

> If I understand the dialog here (and no, I'm not involved in RIPE Policy), it sounds like there might be value in comments on the architectural implications of policy decisions on routing.

Probably more important than that are the architectural implications of 
only having the individual network operators responsible for routing policy.

> I could also imagine the operators in the room saying "that's why we don't want advice from the IETF" :-)

Or from the RIRs either. :-)

> Question for the accumulated folks "in the room": Is the architectural implications of routing and filtering policy an appropriate topic to invite a draft concerning? If so, who might constitute an…

Please add to that where ongoing coordination, recommendation, or 
standardization (if we go that far) of routing and filtering policy 
belongs?  IETF, RIRs, NOGs, someplace else?

As full disclosure: I am involved in RIR policy processes as a member of 
the ARIN Advisory Council.  Randy Bush would refer to me a Policy Wonk I 
believe.  I figure I should just own it, rather than fight it. :-) 
Trying to fight Randy is frequently a loosing battle. :-)

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Gert Doering <[email-masked]>
Date: Wed, 11 Jul 2012 22:09:46 +0200

Hi,

> I mean, that is why people invented CIDR and aggregation in the first

Which statement are you basing this "free-for-all policy" on, exactly?

RIPE-510 never was a "the community has agreed on aggregation" document,
but a summary about which prefix sizes the RIPE NCC has handed out from
which /8s - and, effectively, RIPE-555 is the same: documenting the
minimum assignment and allocation sizes the RIPE NCC has given out.

The RIPE NCC's job is not to tell operators what they can or can not
route - that's job of the *operator community* to agree upon, and 
from what I hear, they seem to be willing to accept /48 PI from their
customers, /32 or larger (less bits) from other ISPs, and to a certain
extent, permit deaggregation of /32s.

RIPE-532 is the document from the *community* that covers what the
RIPE routing working group was able to form consensus on regarding
aggregation - it strongly recommends aggregating where possible, but
takes reality into account and does not disallow deaggregation where
needed.

Now, it can be constructed that a liberal address assignment policy
constructs a "free for all" regarding DFZ pollution with end-site
prefixes - and to a certain extent, I shared this fear in the past.  
Experience from IPv4, where we always had a very liberal PI policy,
teaches us that it's still not "free" (a DSL or cable operator will
not route your PI prefix for 20 EUR/month, to start with), and that
PI space is not actually the largest identifiable source of routes 
in the IPv4 DFZ (deaggregated PA is).

Given all that, the IPv6 address policy can not answer the question
"who is permitted to have a slot in the global routing system, and
what should the obligations be?" - all we do is "deal out numbers",
and the operators will have to agree on the price for a routing table
slot, either for "a block of numbers labeled PI" or "a block of numbers
labeled part-of-someones PA".

Especially rules like "the receipient of a PI prefix must be multihomed!",
do not make sense if you can get a nice and shiny /32 PA instead, by just
paying higher yearly fees (and becoming a LIR).  Address policy should 
not be "if you pay more, you can get more addresses with less strings
attached".

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Wed, 11 Jul 2012 22:14:22 +0200

Hi,

> other than the operators themselves.

Since they also have to foot the bill, that sounds somewhat reasonable 
to me.  No?

Gert Doering
        -- RIPE policy wonk, Operator, Vendor "XL" price victim
-- 
have you enabled IPv6 on something today...?

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 11 Jul 2012 22:07:44 +0100

> other than the operators themselves.

Geoff Huston gave a talk about this at the last RIPE meeting:

https://ripe64.ripe.net/programme/meeting-plan/routing-wg/

Would recommend watching the webcast: as with all Geoff's talks, it was as
entertaining as it was informative.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 11 Jul 2012 22:19:51 +0100

Gert wrote a good summary of this:

> https://www.ripe.net/ripe/mail/archives/address-policy-wg/2011-December/006600.html

The discussion about the proposal was lengthy and wide-ranging, and
included extensive discussion on routing table issues.

Nick

---

From: David Farmer <[email-masked]>
Date: Wed, 11 Jul 2012 19:45:58 -0500

> entertaining as it was informative.

Thanks for the reference.  Geoff's talks are always interesting.

To summarize;  There are no routing police.  However, we all seem to be 
more or less well behaved.  So, being a router policeman would be a very 
boring job. :)  Therefore, at least right now, we don't need any routing 
police.

I, agree.

 > Hi,
...
 > Since they also have to foot the bill, that sounds somewhat reasonable

I think it is perfectly reasonable.  However, frequently people seem to 
decry the lack of routing police around here.  And, when asked about it 
many people seem to pass the buck to someone else.  My comments were 
mostly in reaction to "that's for the RIR communities to comment on, not 
the IETF", rather than trying to suggest that we need routing police.

I don't think we need create the routing police.  However, since 
everyone seems to pass the buck on the issue, its not even clear who 
could form and swear in a posse if we ever actually needed one.  Without 
someone who has that clear authority, then we are only left with 
vigilantes.  And vigilantes are usually as dangerous to the community as 
the bad guys, and usually far more dangerous than the police are.

So, I guess I would suggest we settle the issue of who has the authority 
to form and swear in a posse, both as a protection against vigilantes 
and in the, I hope small, chance we ever actually need a posse some day. 
  Because, if that day ever comes, that's not the day to figure out who 
has the authority to form the posse.

---

From: Randy Bush <[email-masked]>
Date: Thu, 12 Jul 2012 13:52:53 +0900

> Is the architectural implications of routing and filtering policy an
> appropriate topic to invite a draft concerning?

other than incorrect filters breaking connectivity, there are no
architectural implications, only scaling issues.

randy

---

From: Turchanyi Geza <[email-masked]>
Date: Thu, 12 Jul 2012 08:27:15 +0200

Randy,

> architectural implications, only scaling issues.
and we could add: these scaling issues could create a need of drastical
upgrade of our router's linecards very soon. Many service providers won't
be able to finance this.

On the name of this "minority",

Géza

---

From: Gert Doering <[email-masked]>
Date: Thu, 12 Jul 2012 09:18:43 +0200

Hi,

> On the name of this "minority",

I call this FUD again, given that people who actually *study* routing 
table and assignment behaviour have not seen this imminent end of the
IPv6 Internet anywhere near.  

In particular, the policy change that you claim to be instrumented by 
a "minority" is very clearly *not* visible in the data - see here: 

  http://www.space.net/~gert/RIPE/weekly/2012/28/ 

in the "Allocations by Class and RIR Region" diagram, the dotted red line.

(For the casual reader: Geza is still ranting about our "careless" change
to the IPv6 PI assignment policy - if there's anything that's going to 
kill us, it's "not going to IPv6 quick enough to avoid the IPv4 explosion",
not "being too liberal in giving out IPv6 number blocks")

Gert Doering
        -- NetMaster

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Jul 2012 08:24:01 +0100

Gert,

> Since they also have to foot the bill, that sounds somewhat reasonable 

No. It's known as the tragedy of the commons. That's where we seem to be headed,
until something equivalent to the BGP crisis of 1993/1994 occurs for IPv6.
As Randy said, it's a scaling issue.

    Brian

---

From: Randy Bush <[email-masked]>
Date: Thu, 12 Jul 2012 16:24:42 +0900

> IPv6 Internet anywhere near.  

first, fred asked about *architectural* issues.  i repeat, there are
none.

then geza played sore loser, recycling a discussion he lost.  i happened
to agree with him at the time, but we lost, end.

but geza was not saying the sky was falling.  he was just saying that he
was gonna be forced to pay fred for bigger line cards.

this is not an ietf issue.  nothing to see.  move along.

randy

---

From: Gert Doering <[email-masked]>
Date: Thu, 12 Jul 2012 09:55:24 +0200

Hi,

> As Randy said, it's a scaling issue.

OK, I bite.  So who should be able to decide what prefixes an operator 
should be carrying in their routers?

The IETF has demonstrated a very clear non-understanding of operational
realities out there with the "TLA" model - you can't just arbitrary decide
"*you* are big/rich/nice/... enough to be permitted to the 8192 TLA club,
and *you* are not, so go and change your business model" (which, incidently,
the IETF didn't even try, it just put out the TLA model and didn't care
for the implementation).

The RIRs exist because their communities think they do a reasonable job, 
so they should better do what their communities and paying members 
want - which doesn't particularily qualify them to *set up* rules for
the DFZ either.  The RIRs could be tasked to monitor the DFZ, run more
education, and chase violators - but they don't really have a reasonably
big stick to *sanction* someone who is announcing arbitrary garbage.

The operators are the ones who have the big stick, called "not accepting 
routes that they deem unsuitable" - and they are the ones who have to
give money to Fred if the scaling issue hits, so they (should) have an
interest in caring.

Gert Doering
        -- NetMaster

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 12 Jul 2012 10:56:30 +0100

> As Randy said, it's a scaling issue.

the bgp crisis of 1993/1994 related to address exhaustion due to a bad
allocation strategy.  It was worked around initially by CIDR and later NAT.
 But it wasn't related to forwarding table size: you could still hold a
full table in a Cisco 2500 at the time.

Nick

---

From: Turchanyi Geza <[email-masked]>
Date: Thu, 12 Jul 2012 12:54:44 +0200

Gert,

you were right when you proposed -- that time, temporaly, just in the
initial phase of IPv6 addresss allocation -- suspending the TLA concept, in
order to facilitate the IPv6 address allocation to start. May be it was in
2002, I do not remember exactly, however, I remember for the debat and for
your arguments.

However, the TLA concept was not bad and my guess is that we must come back
to it or something very similar in the (not too far) future.

The other question who has the stick in hands is wrong: It is the regulator.

If self regulation of the Internet happen to not working, it will be done
by politically controlled boards..

Good luck,

Géza

On Thu, Jul 12, 2012 at 9:55 AM, Gert Doering <[email-masked]> wrote:

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: Gert Doering <[email-masked]>
Date: Thu, 12 Jul 2012 13:18:03 +0200

Hi,

> to it or something very similar in the (not too far) future.

The TLA concept was nice in theory, but not applicable to reality.

Unless you are able to draw a clear line "this network gets a TLA, and
that network does not get a TLA" that is clear enough so it can actually
be implemented, and that will not destroy the existing tight peering mesh
of the Internet, it is not useful.

Now, geographical aggregation is a concept that might actually have worked,
but it was too foreign for operators to understand, so lacked uptake.

> by politically controlled boards..

"Self destruction by fear of the future" is also a sign of failing
self regulation.

Gert Doering
        -- NetMaster

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 12 Jul 2012 12:27:39 +0100

On 12/07/2012 11:54, Turchanyi Geza wrote:
> However, the TLA concept was not bad

TLAs are an utterly broken concept unless you like the idea of top-down
incumbent-style networking frameworks.  The strength of the Internet is its
distributed nature which allows anyone to provide services at any level
without regard to existing anti-competitive interests.  Any attempt to warp
this into a top-down model should be killed in a fire.

</rant>

Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Jul 2012 13:18:44 +0100

> full table in a Cisco 2500 at the time.

But only just. If the growth had continued as it was going at the start of
1994, that would soon have been untrue. Bothe BGP4 and CIDR were needed to
allow router memory size to keep up with reality.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Jul 2012 13:20:16 +0100

> should be carrying in their routers?

That's the $64B question, indeed. I agree with you about TLAs, by the way.

   Brian

---

From: Randy Bush <[email-masked]>
Date: Thu, 12 Jul 2012 21:48:52 +0900

dunno about you folk, but in '92 it took us a 4000 to hold a table

but this is not nanog.  what are we trying to learn here?

randy

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 12 Jul 2012 13:52:12 +0100

> allow router memory size to keep up with reality.

There were several problems at the time, most of which were caused by non
CIDR allocation and poor bgp3->bgp4 migration policies.  I.e. people were
announcing 256 x /24 instead of 1 x /16 because either their routers didn't
handle CIDR properly or else because they weren't being clued in enough to
manually sort out the aggregation issues.  The CIDR report helped a lot in
this regard.

Later on, we observed a general trend towards a pretty constant level of
deaggregation.

The primary problem of 1993/1994 was that if the addressing allocation
strategies weren't changed, it was realised that complete v4 exhaustion
would have occurred within 3-4 years.  The aggregation and fib size issue
were secondary concerns, even though there was a brief acute problem with
fib size.

FIB size (+ churn) wasn't an issue then any more than it is now.  By which
I mean it's a constant issue in the back-ground which can generally be
dealt with every several years with normal equipment upgrades.  I'm not
upset that my PFC3A sups aren't capable of handling 1M prefixes any more
than I'm upset that my c2500 border router couldn't hold a full table after
1994.  It needed to upgraded to a c4500 anyway because it was handling too
much traffic for a 2500.  Similarly the pfc3as needed to be upgraded to
larger models because I needed mpls and netflow + more scale.

No doubt, there will be a crisis in a couple of years when we reach the
limits of a 1M ipv4 prefix tcam engine (an engine size which has been
current since 2005 - 7 years ago), and then people will need to upgrade
line cards and chassis control engines to the latest and greatest.  Or we
can engineer our way out of this by using clever RIB and FIB optimisation
techniques.  But by the time this kit becomes obsolete, we will have had
10-12 years where it was current, which a) is well beyond any reasonable
depreciation write-down period and b) will have provided 10-12 years for
vendors to develop engines past 1M x v4 prefix engines to lookup engines
with much larger capability.

Nick

---

From: Sascha Lenz <[email-masked]>
Date: Thu, 12 Jul 2012 14:59:51 +0200

Hi all,

[...]
> with much larger capability.

if i would be less old(-fashioned), i would say : "+1" or "Like!" about that, i think....

-- 
Mit freundlichen Grüßen / Kind Regards

Sascha Lenz [SLZ-RIPE]
Senior System- & Network Architect

---

From: Gert Doering <[email-masked]>
Date: Thu, 12 Jul 2012 15:10:00 +0200

Hi,

> dunno about you folk, but in '92 it took us a 4000 to hold a table

We managed with a 2500 in '94, but we had far less internal routes :-)

> but this is not nanog.  what are we trying to learn here?

What I can hear between the lines is that we're still searching for
an answer to

  1. who should be permitted to announce a prefix globally?
    1a. and who decides these rules?
  2. who controls that nothing else is announced?
  3. who can sanction non-conforming behaviour?

I think 2+3 can be solved by technical means *iff* enough people think 
there is value in controlling announcements (one option is RPKI, another 
option is tightly filtering downstream announcements based on IRR data, 
coupled with proper IRR DB security - I'm not qualified to say which is 
"better").

1 + 1a are hard, and I have no answer.

(And of course, this discussion has not very much to do with RIPE-555,
except that some folks assumed that RIPE-510 gave useful guidance on
"1", which had never been its primary purpose)

Gert Doering
        -- NetMaster

---

From: Sascha Lenz <[email-masked]>
Date: Thu, 12 Jul 2012 15:19:45 +0200

Hi all,

> "1", which had never been its primary purpose)

I don't have an answer for 1+1a either, but i guess there never will be,
by design of the global internet.

But your last comment is the important one here: Those kind of RIR documents,
including ripe-510/555 seem to be .. "misused" (for the lack of better wording) for
a long time now. But it was inevitable that such approaches are misguided.
Time told us many times (-> reachability issues with "new" (v4-)/8s being used nowadays etc.).

RPKI-assisted filtering may be an approach for the future, for example. But not sure about that personally (so far).

Sascha Lenz [SLZ-RIPE]

---

From: Havard Eidnes <[email-masked]>
Date: Thu, 12 Jul 2012 15:42:39 +0200 (CEST)

> 1 + 1a are hard, and I have no answer.

I'm only talking about IPv6 here...

On 1, I thought at least that the practice of punching a hole in
a PA allocation (announcing a longer prefix from the PA
allocation from another ASN) and simultaneously that noone is
announcing the covering PA prefix would at least be frowned upon,
and that loss of connectivity to certain networks would be
suitable treatment for such policy violations.

On 1a, each operator is in the end in control of what prefixes he
will allow into the routing table on his routers.

It is my opinion that the removal of the publication of
information by the RIRs which might make it feasible to implement
a sanction against the hole-punchers-with-no-covering-prefix is
... not constructive, and not consistent with the role of the
RIRs in our ecosystem.

> "1", which had never been its primary purpose)

?!?

I thought the whole point of this discussion was exactly that,
and that documenting the minimum assignment sizes did indeed give
some useful guidance which might be of use by a network operator.

Regards,

- Håvard

---

From: Gert Doering <[email-masked]>
Date: Thu, 12 Jul 2012 16:23:54 +0200

Hi,

> >   3. who can sanction non-conforming behaviour?
[..]
> will allow into the routing table on his routers.

Which has been called the "tragedy of the commons" here...  (but that's
not my major point, I want to answer the next paragraph).

> ... not constructive, and not consistent with the role of the

Well, the RIPE NCC publishes very detailed information (in the stats
file which is referenced) on what they actually gave out - so you
still have the information there, in much more detailed form than
before.  

OTOH, I can understand the wish to document the ranges where "special 
case" prefixes (not /32, and not PI either) are coming from.  These have 
not actually changed from RIPE-510 (for IPv6), and I think from the 
discussions it seems to be clear that there is value in bringing back 
the list.

> some useful guidance which might be of use by a network operator.

OK, you have a point here - my choice of words was a bit unlucky.

I still think that people are reading too much into the change from 510
to 555, as the document never had the authority to tell people "this is 
a good prefix and this is a bad prefix" (which I intended to say with
the reference to "1" above).

It *did* give guidance on whether something small you see in your BGP tables
was likely given out as part of a larger aggregate, or "as is", so you
could use it to filter "bad deaggregates".

OTOH, the assumption that a deaggregate must have a covering prefix
"or it's your own fault" just doesn't hold true for IPv6, given that
people used to have multiple IPv4 allocations to be used for 
"different networks", and in IPv6, they just have one (because it's
big enough) but still have to number "different networks" from it - and
depending on their network structure, there might not be any sort of
interconnection, so announcing the aggregate is not necessarily useful.

(It has been said that "one routing table slot is one routing table slot",
and entities that operate multiple non-connected networks should just get
multiple blocks from their corresponding RIR - indeed that makes filtering
according to size easier, but we've not yet been able to form a policy
in the RIPE region that permits handing out an extra allocation while
the first one is not full yet...)

Gert Doering
        -- NetMaster

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Jul 2012 17:56:15 +0100

So, I'm wondering what v6ops (or some other IETF WG) can do
to increase the technical incentives to aggregate IPv6 prefixes,
and decrease the incentives to disaggregate them.

If the answer is "nothing" we might as well keep quiet.

Regards
   Brian

---

From: Gert Doering <[email-masked]>
Date: Thu, 12 Jul 2012 19:57:34 +0200

Hi,

> If the answer is "nothing" we might as well keep quiet.

I see a few reasons for deaggregation (as in "there are more-specific
routes out of a single block given out by a RIR"), and have a few ideas 
what could be done:

 - operator mistake
    -> easy cure: upstream filtering
       tricky bit: get all upstreams to agree that this is useful to have
       -> marketing / name&shame effort...?

    -> different fix: RPKI, so networks "further away" can see this is
       unintended, without having to maintain potentially 

 - "protects me against hijack" - we've not seen this in IPv6, and I
   don't seriously expect that argument when we're talking about 65536
   /48s in a /32.

 - multiple distinct networks that are not connected
    -> naive cure: relax allocation policy to permit multiple allocations
       for distinct networks - ARIN has this, RIPE does not, no idea
       about the others.  Doesn't change the number of routes out there,
       but permits "filtering according to RIR allocations"

 - traffic engineering reasons
    -> in many cases this can be done by announcing the more-specifics
       with limited reach - but as far as I understand, the IETF work on
       BGP extentions to limit prefix propagation died?   Additionally,
       there should always be an aggregate, so filtering these further
       away is "harmless"

 - customer-multihoming out of upstream PA space ("hole punching")
    -> this is a tricky one.  
       naive cure: make them use PI, so it's not a deaggregate - nothing
                   achieved in regards to scaling or routing table slots, 
                   but "filtering according to RIR allocations works!"
       real cure: provide multihoming solution with multiple upstream 
                  networks that works *better* than end-site-with-PI, at 
                  lower cost.

So - what can IETF do?

 - make "multihoming with dual-/48" *work*, so one of the incentives for
   end-site multihoming with a globally visible route goes away

 - educate, to avoid "needless" deaggregation (mistakes, local TE)

(I'm sure I have missed a few things, so please add to the lists)

Gert Doering
        -- NetMaster

---

From: Tim Chown <[email-masked]>
Date: Thu, 12 Jul 2012 22:38:33 +0100

Gert,

A perfect advertisement for the 6renum WG drafts, which are in need of review:

https://datatracker.ietf.org/doc/draft-ietf-6renum-enterprise

https://datatracker.ietf.org/doc/draft-liu-6renum-gap-analysis

https://datatracker.ietf.org/doc/draft-carpenter-6renum-static-problem

You can join the renum list here: https://www.ietf.org/mailman/listinfo/renum

Tim

---

From: Randy Bush <[email-masked]>
Date: Fri, 13 Jul 2012 12:35:42 +0900

> So, I'm wondering what v6ops (or some other IETF WG) can do to
> increase the technical incentives to aggregate IPv6 prefixes, and
> decrease the incentives to disaggregate them.

how well has this gone with ipv4?  and why do you expect ipv6 to be
much different?

at least the mess seems somewhat constant, see pierre francois's
paper,  

    Luca Cittadini, Wolfgang Mühlbauer, Steve Uhlig, Randy Bush,
    Pierre Francois, Olaf Maennel, "Evolution of Internet Address
    Space Deaggregation: Myths and Reality", in IEEE Journal on
    Selected Areas in Communications, Vol. 28, No. 8, October 2010.

randy

---

From: Joel jaeggli <[email-masked]>
Date: Thu, 12 Jul 2012 21:45:15 -0700

> If the answer is "nothing" we might as well keep quiet.

Consider the previous  technical incentive to aggregate, e.g. cidr. the
swamp did not destroy the internet. It worked and the routing table
grows more slowly than the replacement cycle for hardware necessary to
carry it.

Over on the social science side,

The sum of individual decisions to only transitively express routes of a
certain length and not longer actually works, much like flu shots the
whole population doesn't have to immunized for the cure to work, just
enough so that the bad actors are at the margins.

jjaeggli@XX-XX-XX# show policy-options policy-statement no-small-prefixes
from {
    route-filter 0.0.0.0/0 prefix-length-range /25-/32 reject;
}

The potential for  bad actors in v6 might potentially result in more
complex expressions of what normative behavior is.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 13 Jul 2012 07:52:13 +0200 (CEST)

>   end-site multihoming with a globally visible route goes away

Yes, please.

Let's put it this way, an IPv6 Internet with 100-200k routes (in 10 years 
or so) would converge much quicker than a 10x higher prefix sized one. 
Currently state of the art routers seem to be able to program their 
FIB at a rate of approximately 10k entries per second, and this hasn't 
changed drastically the past 10-15 years.

I would much rather use Moores law to converge the Internet quicker and 
heat less air (=lower power consumption) and spend less money (usually 
more table sizes = increased cost) when it comes to the core, than to 
continue this mess with customer PI. Also, the more end networks that 
speak BGP, the more chances for misconfiguration and the more global route 
churn we'll see.

I am not really interested in my core router caring what ISP an enterprise 
customer on the other side of the world chose to use today as opposed to 
yesterday. I would also like to be able to multihome my residential 
household (I already have two connections into it) without using one of 
them to tunnel to the ISP that is my primary (which I can only do because 
I have a router there to tunnel to).

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 13 Jul 2012 08:30:08 +0100

> how well has this gone with ipv4?  and why do you expect ipv6 to be

The only way it could be different is if we succeed in persuading
sites to use multiple PA prefixes simultaneously (see Tim Chown's
message and numerous attempts to find a good multihoming solution).

Answering my own question, which wasn't intended to be rhetorical,
I doubt if there is anything that v6ops iteself can do.

>     Selected Areas in Communications, Vol. 28, No. 8, October 2010.

An excellent paper (that happens to be consistent with my own CCR paper
too). In fact that whole issue of JSAC is excellent.

    Brian

---

From: Vesna Manojlovic <[email-masked]>
Date: Fri, 20 Jul 2012 17:28:22 +0200

Dear colleagues,

> some useful guidance which might be of use by a network operator.

After considering your feedback about RIPE-510 & RIPE555,
RIPEstat developers have created another visual interpretation of
RIR "delegations" data: an interactive widget in which you can query 
for any address space prefix (0/0, 2000::/3 or 5/8, for example) and 
receive a prefix size distribution as an output:
https://stat.ripe.net/widget/rir-prefix-size-distribution

You can use the resulting output to determine a cutting-off point for 
the filtering based on the minimum allocation size: for example, if the 
213/8 block has only XX % prefixes smaller then /24, you might decide 
that it is safe to not accept those prefixes. Or you can go for the /25 
or /23 instead.

A data call API is also available for the scripting and creating your 
own favorite filters.

We are interested in your feedback:
- do you find this useful?
- how can we improve it, so that it suits your needs even better?

We already have multiple ideas for the additional features in the next 
release of the widget, but we are very much looking forward to hear from 
you and make a new widget or improve this one based on your needs!

More information is available in the RIPE Labs article:
https://labs.ripe.net/Members/becha/rir-prefix-size-distribution-in-ripestat

Regards,
Vesna

--
Vesna Manojlovic                                 [email-masked]
Senior Community Builder                           +31205354444
for Measurements Tools          RIPE NCC        http://ripe.net

---

From: Turchanyi Geza <[email-masked]>
Date: Fri, 20 Jul 2012 18:23:03 +0200

Hello Vesna,

Many thanks for your tool and comments!

I would be intesrested in stats of (merely) not routed but allocated
addresses...

Thanks,

Géza

On Fri, Jul 20, 2012 at 5:28 PM, Vesna Manojlovic <[email-masked]> wrote:

> RIR "delegations" data: an interactive widget in which you can query for
> any address space prefix (0/0, 2000::/3 or 5/8, for example) and receive a
> prefix size distribution as an output:
> https://stat.ripe.net/widget/**rir-prefix-size-distribution<https://stat.ripe.net/widget/rir-prefix-size-distribution>
>
> You can use the resulting output to determine a cutting-off point for the
> filtering based on the minimum allocation size: for example, if the 213/8
> block has only XX % prefixes smaller then /24, you might decide that it is
> safe to not accept those prefixes. Or you can go for the /25 or /23 instead.
>
> A data call API is also available for the scripting and creating your own
> favorite filters.
>
> https://labs.ripe.net/Members/**becha/rir-prefix-size-**
> distribution-in-ripestat<https://labs.ripe.net/Members/becha/rir-prefix-size-distribution-in-ripestat>
>
> Regards,
> Vesna
>
> --
> ______________________________**_________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/v6ops<https://www.ietf.org/mailman/listinfo/v6ops>
>

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 20 Jul 2012 18:51:33 +0200

> I would be intesrested in stats of (merely) not routed but allocated

Check http://www.sixxs.net/tools/grh/ and the reports it generates.
There are a lot of more specifics out there and also a lot of prefixes
which do not route the allocated size... (and then those network admins
wonder why it does not work)

Greets,
 Jeroen

---

From: Gert Doering <[email-masked]>
Date: Tue, 24 Jul 2012 16:28:36 +0200

Hi,

coming back to this:

> >   end-site multihoming with a globally visible route goes away

It actually works quite well today - except for proper source address
selection *failover* in the face of failing connections.  Sort of 
"happy eyeballs .bis"...

most simple example:
  home network has two ISPs, A and B, both assigning a /48, both offering
    "access to the Internet", so both are valid as "default route"
  host on LAN has two IPv6 addresses, "A" and "B"
  router(s) do source-based routing, packets with source address "A" 
    goes to ISP "A", packets with source address "B" goes to ISP "B"
    (this is a strong MUST as ISPs are encouraged to do BCP38 filtering)
  user types "www.google.com" into browser
  source address selection selects "use source address A"
  ISP A has "issues", and the connection to Google never succeeds
  browser falls over to IPv4...

what is missing here:
  ISP A has "issues", and the connection to Google never succeeds
  connection is re-tried with source address *B*, packets leave via ISP B,
     and reach Google

as far as I could determine, no operating systems today will ever re-try
a failed connection with a different source address, and they are all
fully RFC conforming, as there is no RFC telling them they should do that.

Now, the interesting question is "how to go forward with this"?  There's
Ole's draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat, which addresses
most of the issues, and points to lots of other drafts about source address
selection, DHCPv6 policy distribution, etc. - but after reading through
all that, I came to the conclusion that "this is mostly intended for managed
environments" - which is not what "your generic barbershop customer" wants.

Gert Doering
        -- NetMaster

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 24 Jul 2012 16:48:46 +0200

> selection *failover* in the face of failing connections.  Sort of 

I am still wondering if ISPs and content providers like it that a host
will be then connecting, likely in parallel, from + to multiple addresses.

Thus lets say that a webserver has 4 addresses (2 IPv4, 2 IPv6) and the
user has 2 ISPs and thus gets 2 addresses locally, that would mean that
a HE implementation might build 4 connections in paralell, closing 3 of
them that are 'too slow', while the HE.bis implementation might cause 8
of them dropping 7. Multiply that by a million users and instead of 1
mpps you suddenly have 8 mpps....

Oh and another is that A6/DNAME was maybe not that a bad idea, though a
bit of scripting can definitely solve that too (and it is still to be
seen that ISPs will be delegating reverse DNS to end-sites).

Even if code did that, which would be great, the problem is then still
long-lived connections[*] and inbound connections. Though, these should
be addressed with Mobile IPv6, LISP or HE which retries both inbound
addresses, which might be suboptimal according to some, then again, you
get what you pay for.

Greets,
 Jeroen

(* = who is still looking for the ultimate screen/tmux/byobu: have a
bunch of shell windows with unlimited scrollback that always stay
connected/reconnect even if local IP address changes or one gets
disconnected; the 'too many shells open and too much moving issue')

---

From: Gert Doering <[email-masked]>
Date: Tue, 24 Jul 2012 17:38:19 +0200

Hi,

> will be then connecting, likely in parallel, from + to multiple addresses.

I don't know what the "best" result would be.  Maybe "try one combination
and fall over after 500ms" or "5s" or whatever, plus "cache the result"
(obviously).

"Do all combinations in parallel in the same fraction of a second" is
obviously not a very nice approach - and HE implementations don't do
that for multiple IPv6 destination addresses today either (Apple will
do 1 v4 + 1 v6 at the same time, the rest does "with slight delay").

> mpps you suddenly have 8 mpps....

Yes.  This certainly needs to be taken into account.

Nevertheless, source address failover needs to be done, otherwise 
we'll be back to "ULA inside, two NPT66 boxes to the respective ISPs"
(and I've already heard from vendors that their customers are asking
for that, because "the other thing is too complicated" *sigh*).

> seen that ISPs will be delegating reverse DNS to end-sites).

Slightly different can of worms, but DNS also needs to be fixed if
you want to be able to connect from the outside to internal hosts
in "SoHo networks", without resorting to some sort of registrar
service ("back to my mac").

> addresses, which might be suboptimal according to some, then again, you

Fixing things for outbound connections would already go quite some 
distance for the *largest number* of leafs - "home users" and "smallest
shops" that are really 99% just consuming, and not running servers
(except for maybe some remote-maintenance-service connection to
my Mom's PC, but those can be fixed by inside-out VPN setup, DynDNS,
external registrar services, etc.)

> disconnected; the 'too many shells open and too much moving issue')

You and I are not what causes the scaling problem at the edge :-)

Gert Doering
        -- NetMaster

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Jul 2012 17:19:31 +0100

> will be then connecting, likely in parallel, from + to multiple addresses.

I don't really care what they *like* if I am the user. In any case, it was
precisely to allow session continuity in such a case that we invented
shim6, which is still waiting for its future to arrive. It's also why MPTCP
is interesting, and it's why we have draft-ietf-mif-happy-eyeballs-extension.

Eventually, one or more of these solutions will become widespread. I'm not
sure we need to do anything except wait.

(Incidentally, I see that draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat
is stuck in the RFC queue waiting for normative references.)

    Brian

> .

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 24 Jul 2012 18:54:46 +0200

> is interesting, and it's why we have draft-ietf-mif-happy-eyeballs-extension.

And the protocol I always forget that does most of the things (only
disconnect and resume later it does not support) I want but which is not
universally available: SCTP

> sure we need to do anything except wait.

A proper overview in eg Wikipedia, or heck a "IETF FAQ" page would maybe
be an idea: "How do I solve the problem where I have two prefixes at
home and want to failover between them".

Greets,
 Jeroen

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 24 Jul 2012 19:25:48 +0200

[Mark Andrews: could I entice you to update your HE-code mentioned below
or do you accept patches to it? :) ]

> and fall over after 500ms" or "5s" or whatever, plus "cache the result"

Apple does it mostly okay in Lion, the only problem I have with it is
that there is no 'off' button for disabling the failover from IPv6 to
IPv4 or at least making it not quibble over 20ms latency difference
(currently solved in my home net by slowing down IPv4 packets in the
router when the source address is a Mac OS X box ;).

> do 1 v4 + 1 v6 at the same time, the rest does "with slight delay").

That sounds about nice indeed.

> for that, because "the other thing is too complicated" *sigh*).

I unfortunately am not a mass-customer ISP who can demand features from
vendors, /me looks at the Comcasts around the world though.

I do think having a Happy Eyeballs Bis with this in there will be a good
thing to have for Operating Systems.

One argument for router/NAT-box vendors is that it will be retrofitted
in the OS and that they do not have to do much for it.

As mentioned at the top Mark has the code worked out for destination
address selection:
https://www.isc.org/community/blog/201101/how-to-connect-to-a-multi-homed-server-over-tcp

> service ("back to my mac").

There are enough DynDNS services which can resolve this and I am sure
that if there is a 'site multihoming with multiple prefixes' RFC that
these services will enable their users to register multiple addresses or
easily swap out a /48 for another or add/remove one etc prefixing all
the hosts in a session ala A6.

> external registrar services, etc.)

Indeed.

> You and I are not what causes the scaling problem at the edge :-)

Well... I did not register my private AS + PIv6 prefix yet ;)
(and won't happen either as I don't see the value of it)

Greets,
 Jeroen