Subject: [v6ops] new draft: draft-hilliard-v6ops-ipv6-discard-prefix-00.txt

From: <[email-masked]>
Date: Tue, 5 Jul 2011 06:55:00 -0700 (PDT)

A new draft has been posted, at http://tools.ietf.org/html/draft-hilliard-v6ops-ipv6-discard-prefix. Please take a look at it and comment.

---

From: Mark Smith <[email-masked]>
Date: Wed, 6 Jul 2011 00:26:19 +0930

Hi,

> A new draft has been posted, at http://tools.ietf.org/html/draft-hilliard-v6ops-ipv6-discard-prefix. Please take a look at it and comment.

I'm for this.

I'm not sure about a /32, as it is very large considering the purpose.
Perhaps the /32 could be generally reserved for purposes similar to
this, and then the first /48 from with in it used for this specific
purpose. Even a /48 seems excessive for this specific purpose, but in
IPv6 that's pretty "small" and cheap.

Also a bit more explanation of why the following are SHOULD NOT's
rather than MUST NOT's might be useful. Is it to allow for the case
where the third party AS is performing DoS traffic analysis? That's the
only possibility I can think of right now.

"   The assignment SHOULD NOT be announced to
   third party autonomous systems and IPv6 traffic with an destination
   address within this prefix SHOULD NOT be forwarded to third party
   autonomous systems."

Regards,
Mark.

---

From: Fred Baker <[email-masked]>
Date: Tue, 5 Jul 2011 12:37:51 -0700

> I'm not sure about a /32, as it is very large considering the purpose.

Hmm. Dumb question. We're looking for a way to implement something akin to

	ipv6 route <address> Null0
	ipv6 route <prefix> <address>

with the latter being distributed in a routing protocol.

In IPv4, we use 127.0.0.0/8 as a localhost prefix, and specifically 127.0.0.1/32 as localhost. This was variously implemented; some used the prefix and some the address. In IPv6, we flipped the coin, and it came up ::1 as localhost.

Is there any substantive reason to not define ::2 as "discard"? It could be implemented as simply as

	ipv6 route ::2/128 Null0
	ipv6 route <prefix> ::2

on existing systems, and in future systems could be programmed in the same way ::1 is.

---

From: Mark Smith <[email-masked]>
Date: Wed, 6 Jul 2011 09:43:04 +0930

Hi Fred,

On Tue, 5 Jul 2011 12:37:51 -0700

> on existing systems, and in future systems could be programmed in the same way ::1 is.

I think having a standard preconfigured and generic discard address
would be useful, and ::2 would be a pretty good choice.

One thought I'd had was that this may not suit people who also would
want to implement one or more DoS traffic analysis sink hole routers. I
hadn't investigated how that was done too thoroughly (i.e. read
RFC3882 properly), I'd thought the routing trick they would be using was
to inject the sink hole router's host route into the routing domain as
well, taking advantage of recursive route resolution to draw the
traffic towards the sink router announcing the discard host route.

I've done something similar in the past to cover an interim period
where the sink static route wasn't present on all routers. The routers
that have the discard host route anycast it into the routing domain, so
that DoS traffic was forwarded towards the closest one by the routers
that didn't have it, when they received a iBGP route with the NEXT_HOP
set to the anycast discard address.

So in addition to having ::2 as a well known and preconfigured discard
address, I think there still could be some reasons to have a reserved
prefix with a number of addresses that can be used as discard host
routes.

As a side note relating to the 127/8 verses ::1 choice, I've come
across an occasion where having a loopback prefix rather than an
individual address available was useful. It was so long ago that I
can't remember exactly what I was doing, however I do remember that it
was inspired by ntpd's trick of having reference clocks listen on
addresses within 127/8 e.g. -

http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver8.html

http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver6.html

So if there is enough value in that sort of thing, perhaps ::/64 could
be reserved for loopback addresses, and 0:0:0:2::/64 reserved for
these discard addresses, with 0:0:0:2::1/128 being a well known and
preconfigured one.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Wed, 6 Jul 2011 11:25:11 +0930

On Wed, 6 Jul 2011 09:43:04 +0930

> Hi Fred,
<snip>
> be reserved for loopback addresses,

of course with ::/128 still being the unspecified address.

> and 0:0:0:2::/64 reserved for
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Erik Kline <[email-masked]>
Date: Wed, 6 Jul 2011 11:08:22 +0900

> http://www.eecis.udel.edu/~mills/ntp/html/drivers/driver6.html

<!-- begin "further digression -->
I have had similar need at times, and mentioned it once before on
v6ops I think.  Basically, when writing unittests for systems it's
*really* handy to be able to bind each component to its own 127.0.0.x
address and pretend you have a locally routed network.  And, as you
point out, even in regular operational scenarios it can be handy.

There's a node-local multicast prefix, iirc, but only a single /128
for unicast.  :/

---

From: Mark Andrews <[email-masked]>
Date: Wed, 06 Jul 2011 12:28:10 +1000

> There's a node-local multicast prefix, iirc, but only a single /128

We ended up using a ULA prefix for our testing.

lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
	inet6 ::1 prefixlen 128 
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
	inet 127.0.0.1 netmask 0xff000000 
	inet 10.53.0.1 netmask 0xff000000 
	inet6 fd92:7065:b8e:ffff::1 prefixlen 64 
	inet 10.53.0.2 netmask 0xff000000 
	inet6 fd92:7065:b8e:ffff::2 prefixlen 64 
	inet 10.53.0.3 netmask 0xff000000 
	inet6 fd92:7065:b8e:ffff::3 prefixlen 64 
	inet 10.53.0.4 netmask 0xff000000 
	inet6 fd92:7065:b8e:ffff::4 prefixlen 64 
	inet 10.53.0.5 netmask 0xff000000 
	inet6 fd92:7065:b8e:ffff::5 prefixlen 64 
	inet 10.53.0.6 netmask 0xff000000 
	inet6 fd92:7065:b8e:ffff::6 prefixlen 64 
	inet 10.53.0.7 netmask 0xff000000 
	inet6 fd92:7065:b8e:ffff::7 prefixlen 64 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: George Michaelson <[email-masked]>
Date: Wed, 6 Jul 2011 12:12:50 +1000

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 06 Jul 2011 22:17:10 +0100

>> I'm not sure about a /32, as it is very large considering the purpose.
[...]
> Is there any substantive reason to not define ::2 as "discard"? It could be implemented as simply as

Stepping back a little, I think we're talking about two slightly different
things here.  The ID suggests that we reserve a prefix for generic use as
something to faciliate traffic discard (i.e. something which you could
inject into a routing protocol), whereas defining ::2 as discard is all
about creating a local-only discard address, similar in scope to the cisco
Null0 interface (i.e. something that you wouldn't necessarily inject into a
routing protocol).  These are two separate things, and the ID is very
specifically talking about one, not the other.

In terms of the exact size of prefix that might be useful from the point of
view of the ID, the options are either /128 or more than /128. If people
feel that a single discard address is all that's required (I don't), then
::2 will suffice, and the functionality of the two separate things noted
above will collapse into a single issue.

If it's more than /128, then the choice between /32 or /48 is a matter of
bikeshed politics.

Incidentally, I'm not at all averse to the idea of defining ::2 as a
local-only discard address.

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 06 Jul 2011 22:24:38 +0100

> only possibility I can think of right now.

As far as I'm aware, Informational IDs cannot use "MUST" (I am but an egg,
so if someone can correct me here, please do so).

More than that, I don't want to proscribe the practice - just to say that
it's probably not a good idea, and if you're doing it, you're probably
doing something wrong.

Nick

---

From: "William F. Maton Sotomayor" <[email-masked]>
Date: Wed, 6 Jul 2011 18:25:27 -0400 (EDT)

> A new draft has been posted, at http://tools.ietf.org/html/draft-hilliard-v6ops-ipv6-discard-prefix. Please take a look at it and comment.

I support this ducment.  I too am concerned about burning an entire /32, 
but what's a million addresses?   In all seriousness, perhaps something 
shorter could be used, or maybe the /32 might be a boundary better 
understood over a /48.  In any case, the principle counts.  As a RTBH 
operator for AS25689, I have been forced to go off and deploy this as well 
for IPv6 pest-control reasons (FTP IPv6-enabled client executing dozens of 
connections per second against the FTP server here.  I became ... annoyed).

In my implementation I have been using the IPv6 documentation prefix, 
2001:0DB8::/32, which I admit may be bad practice and make me out to be a 
bad boy, e pur si muove.  (Or, it works for me.)

So on the control router I do:

! Go down Route 66
ipv6 route 2001:DB8::/32 Null0 tag 66

and a route-map:

route-map static-to-bgpv6 permit 5
  match tag 66
  set ipv6 next-hop 2001:DB8::1
  set local-preference 2500
  set origin igp
  set community no-export
!

The edge routers are then programmed to do the spankings:

ipv6 route 2001:DB8::1/128 Null0

(I've left out the usual bits on the BGP peer configuration to prevent 
accidental leaks, etc.)

Thanks,

wfms

---

From: Mark Smith <[email-masked]>
Date: Thu, 7 Jul 2011 10:55:17 +0930

Hi Nick,

On Wed, 06 Jul 2011 22:17:10 +0100

> specifically talking about one, not the other.

Sure, although this could be an opportunity to address both similar
requirements in the same ID.

> If it's more than /128, then the choice between /32 or /48 is a matter of

Where your thoughts to have it come from within 2000::/3, which is
perhaps why you chose /32? I think it probably should come from outside
of it similar to ULAs, ::1 etc., because I don't think a discard
function is dependent on the Internet's global unicast addressing. Once
it's outside of 2000::/3, I'd think the chosen size can chosen based on
expected use, rather than trying to reasonably fit in with an existing
allocation scheme.

Regards,
Mark.

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 07 Jul 2011 13:14:43 +0100

> requirements in the same ID.

I would see ::2 as more appropriate for standards-track.
hilliard-v6ops-ipv6-discard-prefix is very definitely informational.

> expected use, rather than trying to reasonably fit in with an existing

The exact size is not important at this stage.  There is plenty of ipv6
address space out there, and it's just about irrelevant as to whether this
prefix would be /64, /48, /32 or anything in-between.  Please let's park
this issue for the moment, because it's distracting attention away from
more substantive issues in the draft.

Regarding 2000::/3, as it would be a special purpose prefix, it would
probably be better not to take it from Internet unicast space, as it's not
general purpose internet unicast address space.

Nick

---

From: Mark Smith <[email-masked]>
Date: Thu, 7 Jul 2011 22:21:00 +0930

On Thu, 07 Jul 2011 13:14:43 +0100

<snip>

> more substantive issues in the draft.

ok. It's not obvious to me what they are though. Once the address space
issue was sorted out, I'd see no reason for it not to be published.

> general purpose internet unicast address space.

I think we're agreeing on that, I was just curious where you came up
with /32, and though perhaps it was because it is the minimum RIR
allocation, which implied it coming out of 2000::/3.

Regards,
Mark.

---

From: Daniel Roesen <[email-masked]>
Date: Thu, 7 Jul 2011 16:47:03 +0200

On Thu, Jul 07, 2011 at 01:14:43PM +0100, Nick Hilliard wrote:
> prefix would be /64, /48, /32 or anything in-between.

/64s are far less likely to leak into the DFZ. As such, I'd favor
to settle on /64 if size doesn't matter for other reasons.

> general purpose internet unicast address space.

ACK.

Best regards,
Daniel

-- 
CLUE-RIPE -- Jabber: [email-masked] -- dr@IRCnet -- PGP: 0xA85C8AA0

---

From: Fred Baker <[email-masked]>
Date: Thu, 7 Jul 2011 12:33:40 -0700

On Jul 7, 2011, at 12:20 PM, David Malone wrote:

> One possible security point arising from making a well-known
> allocation for traffic discard, is that there will then be a
> well-known traffic sink address available on the network. This means
> that attackers that want (say) to fill a link and then have the
> traffic vanish as quickly as possible can just generate traffic and
> send it to the well-known discard address.
> 
> I'm not sure this is a big deal, but it might be worth discussing?
> It might also influence the choice of assigning a single address
> vs. a prefix, where network operators can blackhole randomly chosen
> addresses, rather than the whole prefix.

I agree that we should discuss the solution and its ramifications. We can obviously continue on the list, but I expect to also do this face to face.

I suspect that the security concern is a minor one; a network with uRPF or some other form of ingress filtering configured would not accept a packet sourced from ::2, and the only way I see it getting sent as a destination address *to* a network involves a pretty obvious mechanism like direct injection into a tunnel. So if the event occurs, it should be visible.

---

From: David Malone <[email-masked]>
Date: Thu, 7 Jul 2011 20:20:02 +0100

David.

---

From: Sander Steffann <[email-masked]>
Date: Sat, 9 Jul 2011 00:03:36 +0200

Hi,

> send it to the well-known discard address.

On the other hand: if there is a well-known discard address that is in wide-spread use then the traffic will disappear at the first router that supports it. If usage is wide-spread enough this might be before it even goes onto the link :-)

- Sander

---

From: Roger Jørgensen <[email-masked]>
Date: Sat, 9 Jul 2011 11:03:15 +0200

> expected use, rather than trying to reasonably fit in with an existing

I see two problem with what have been suggested so far.

::2 may not a good choice, it is alike ::1 and everything else. Why
not use ::f instead? It's clearly on a edge sort of very different
from ::1

It should be a ::/32 and should be taken from the very end of the same
2000::/3 we are currently using. To pick it from outside the current
used address may sound like a good idea, and may be tempting to make
it stand out from current addresses. But I'm more afraid that will
polute our next go on IPv6.

I suggest we use ::f and we use a /32 from the very end of our current
2000::/3 range. That make both stand very out from all of our current
addresses. And if we use something else than /32 on our next go (not
from 2000::/3) we can very easy change the prefix.

-- 

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 11 Jul 2011 16:39:36 +0100

> send it to the well-known discard address.

It's certainly possible that this could happen, which is why the draft
says: "IPv6 traffic with an destination address within this prefix SHOULD
NOT be forwarded to third party autonomous systems", which deals with
inter-AS traffic forwarding.

As for local traffic forwarding, this is generally much easier to deal
with, because as a service provider you will usually have a contractual
relationship with your downstreams, and if they start doing silly stuff
like this, they just end up trashing their own connectivity or ending
themselves up with large bills.  Of course, the traffic flow could be
malicious in nature, in which case you wouldn't want either of these, but
billing issues are an order of magnitude up the protocol stack from this ID.

In any case, netflow is usually implemented to detect large bursts of
traffic like this, so it's probably not that much different from other DoS
attacks in this respect.  You has your DoS, you takes out your netflow
stats, then you figures out what's going on.

Nick

---

From: David Malone <[email-masked]>
Date: Mon, 11 Jul 2011 16:47:08 +0100

> stats, then you figures out what's going on.

Sounds reasonable. I think you have your security considerations
section right there.

	David.

---

From: Doug Barton <[email-masked]>
Date: Thu, 14 Jul 2011 20:11:59 -0700

On 07/09/2011 02:03, Roger Jørgensen wrote:
> I suggest we use ::f

I like the idea of using an alpha, but how about ::d (for discard)?

> and we use a /32 from the very end of our current
> addresses.

I agree that 3fff:ffff::/32 is a good idea for this purpose. 3ff* is
more or less useless for general purposes anyway given the historical
Teredo usage.

I don't like the idea of using a prefix from a block outside 2000::/3,
since we have been operating under the assumption that if we screw
something up in this /3 that we can start over in one of the others. I'd
hate to cripple that premise.

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: Erik Kline <[email-masked]>
Date: Fri, 15 Jul 2011 15:41:30 +0900

> hate to cripple that premise.

What about something from up near the ULA space?

---

From: Roger Jørgensen <[email-masked]>
Date: Fri, 15 Jul 2011 10:46:18 +0200

> What about something from up near the ULA space?

as long as it's not from the un-used IPv6 space (outside currently
used space) anything is fine really.
And 3fff:ffff:: might be a good choice, combined with ::d for discard :)

-- 

Roger Jorgensen           |

---

From: Keith Moore <[email-masked]>
Date: Fri, 15 Jul 2011 09:01:17 -0400

> And 3fff:ffff:: might be a good choice, combined with ::d for discard :)

There's always {prefix}::dead:beef

Keith

---

From: Mark Smith <[email-masked]>
Date: Sat, 16 Jul 2011 03:23:35 +0930

On Thu, 14 Jul 2011 20:11:59 -0700

> I like the idea of using an alpha, but how about ::d (for discard)?

Possibly only if you speak English ... I think numbers are better for
this sort of thing.

It seems to me that there are only really 3 things that can be done
with a packet, forward it, discard it, or loop it (a special case of
forward). As ::1 represents loop, using :f or :d for discard would
suggest to me that :2 through :c or :e is reserved for some similar
purpose in the future, however I don't think there are any. So I'd
prefer ::2 to be used, because I don't think it implies reservation for
the future, and is adjacent to what is close to the semantic opposite
of discard.

> hate to cripple that premise.

The question is, if 2000::/3 becomes deprecated, does that imply
blackholing does too? I think it does, which is why I'd prefer the
space to be to be allocated from outside of it. IOW, it's address space
that represents a function (similar to ::1, fe80::/10, fc::/7 etc.), so
should be a functional allocation, rather than one from within the
global Internet address space (that may be changed in the future).

Regards,
Mark.

---

From: Doug Barton <[email-masked]>
Date: Fri, 15 Jul 2011 21:58:08 -0700

On 07/15/2011 10:53, Mark Smith wrote:
> Possibly only if you speak English ...

... or Spanish (descartar) :)  Although thinking about it, if we use
3fff:ffff::/32 for the network then ::f might make more sense.

> I think numbers are better for this sort of thing.

I wouldn't necessarily argue against using a number, and ::2 wouldn't
hurt anything. I just thought it would be interesting to use something
with at least some mnemonic value.

> the future, and is adjacent to what is close to the semantic opposite

Personally I think you might be overthinking this bit, but reasonable
minds can differ here.

> global Internet address space (that may be changed in the future).

Now I believe you're definitely overthinking it. If we screw up 2000::/3
so badly that we need to move on then we can define another range for
blackholing if we need to. Let's only foul one sandbox at a time.

Doug

--

---

From: Mark Smith <[email-masked]>
Date: Sat, 16 Jul 2011 18:45:09 +0930

On Fri, 15 Jul 2011 21:58:08 -0700

<snip>
> Now I believe you're definitely overthinking it. 

I don't think so. I'm consider the amount of additional operational work
involved to change a discard address in parallel with a unicast
prefix. There should be a tangible benefit from making operational
changes, yet having to renumber a discard address would provide none.

>If we screw up 2000::/3
> blackholing if we need to.

Replacing the global unicast address space should only involve
replacing the global unicast address space.

We've already moved from one global unicast address space to
another (3ffe::/16 -> 2000::/3). Fortunately that didn't also involve
renumbering ::1, fe80::/10, etc. because they were wisely chosen to be
outside of 3ffe::/16 and 2000::/3. 

> Let's only foul one sandbox at a time.
> 
> 

Lets not create unnecessary work either.

---

From: Roger Jørgensen <[email-masked]>
Date: Sat, 16 Jul 2011 11:40:36 +0200

<snip>
> outside of 3ffe::/16 and 2000::/3.

One way to think about it is something along these lines, if it is
something very linked with 2000::/3 (policy or otherwise, eui-64 can
be claimed to be so.....) then we should use that address space.
If it linked with IPv6 more than an address range (this seems to be
the case here) then we should use something outside our current IP
range (2000::/3).

And whenever we decide to try again and start using another range,
3000::/3 or so... guess when that time come we have other features
that only affect that range and not 2000::/3 but the discard might be
the same.

-- 

Roger Jorgensen           |

---

From: Mark Smith <[email-masked]>
Date: Sun, 17 Jul 2011 11:25:22 +0930

On Sat, 16 Jul 2011 11:16:31 +0100
Nick Hilliard <[email-masked]> wrote:

> On 16/07/2011 10:40, Roger Jørgensen wrote:
> > 3000::/3 or so...
> nit: 2000::/3 is 2000:: to 3fff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
> 
> I am very pleased at the colours that everyone is suggesting for my
> bikeshed.  Very elegant, all of them - thank you.
> 

If you believe there are more substantive issues, why haven't you
either already dealt with them in the ID, or started a topic of
conversation about them here?

As for who's bikeshed it is, it's all of ours if it becomes an RFC, not
just yours.

---

From: Doug Barton <[email-masked]>
Date: Sat, 16 Jul 2011 22:30:22 -0700

> replacing the global unicast address space.

Just to be clear, moving out of 2000::/3 would not be "replacing the GUA
space." 4291 says (essentially) that everything except ff00::/8 is
global unicast. The reason to move out of 2000::/3 would be that we
realize we've made some fundamentally bad architectural decisions and
need to hit reset.

If that happens the ideal situation would be that we have the maximum
number of alternatives, unhampered by placing a special-purpose prefix
in an otherwise green field.

> another (3ffe::/16 -> 2000::/3).

Um .... I'm not sure how to respond to that. The 6bone was purposely
carved out of the last bit of 2000::/3 with the idea of abandoning it
designed into the launch. But it's still one big, happy GUA family.

> Fortunately that didn't also involve

Certainly ::1 was designed (I believe wisely) never to change.
Personally (and I mean no offense by this) I've always been the tiniest
bit dubious about the use of the f* special purpose prefixes, but I
don't think at this point we have any reason to believe that harm will
come from it. :)

But let's review your scenario for a minute. Let's say that a discard
network is desirable (I'm not convinced on that point yet, but I'm
willing to be). Let's say further that we follow Roger's suggestion and
use the last /32 in 2000::/3 (3fff:ffff::/32, which I've already said I
think is a great idea since the 6bone and old-Teredo prefixes have
pretty much rendered 3ff* useless for general purposes). Now disaster
strikes and we need to start all over again by moving out of 2000::/3.
In this scenario the discard network will be in the old /3, so it will
be then what you're suggesting that we do now (the special-purpose
prefix will be outside the shiny new network).

Also, assuming that we do have to move out of 2000::/3, I don't see that
it's a foregone conclusion that we would have to assign a new discard
network in any case. If you do, perhaps you could explain your reasoning?

Doug

--