[ppml] [address-policy-wg] Re: article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot)

bmanning at karoshi.com bmanning at karoshi.com
Tue May 15 15:29:00 EDT 2007


On Tue, May 15, 2007 at 12:47:09PM +0100, Nick Hilliard wrote:
> bmanning at karoshi.com wrote:
> >	er... perhaps I misread.  you stated; "you can stop it from 
> >	being useful PI space, which is all you need to do." 
> >	i understand this as you (party Q) being able to effect any
> >	communications between myself (party R) and Gert (party S)...
> >	the single time this is effective is when party Q is in the
> >	transit path btwn R & S. 
> 
> "you" == RIRs/whoever publishing these blocks in a list of prefixes which 
> should not be seen on the public ipv6 internet, due to community mandate.

	i have problems w/ the term "public [I,i]nternet"  - could you
	please define it?

> - do you want to base your bilateral communications and possibly your 
> business on an something which is frankly unsupported as designed and 
> could stop working at any stage if operator Q were to implement 
> uncontroversial prefix filters?

	are you suggesting that party Q is the only option for communications
	btwn parties R & S?

> -  do you want to go beyond communications between R and S?

	sure... 
 
> Prove the point, Bill.  Go ahead and advertise 10/8 and use it in anger on 
> the public ipv4 internet.  When you've got some good figures which 
> indicate how useful it is, let us know.

	not a chance.  i will note that there are a whole bunch of folks
	who do use 10.0.0.0/8 "in anger" on the internet - i see many packets
	w/ this netblock as a source address.

> >>The point is, if a block is carved out and marked specifically as being 
> >>non-routable on the public v6 internet, it will have degraded 
> >>connectivity to some degree or other.
> >
> >	do i care? 
> 
> Given your position on announcing 3ffe::/24 and 3ffe:800::/24 until fairly 
> recently, evidently not :-)

	marked by whom?   (and wrt 3ffe:: space...  folks are still using it
	and so i still annouce it.  it remains useful for them. :)


> > does that effect the usefulness of a given prefix
> >	if some ISP someplace filters out (refuses to listen) to the 
> >	announcements? i posit that:
> >		a) i have zero influence on your operational behaviour
> >		   when i have zero business relationship w/ you
> >		b) you have the ability to set whatever policies you like
> >		   for packet acceptance into your network and packet 
> >		   egress from your network.
> 
> No argument there.  But we're talking about different things. So far, 
> you're talking about connectivity between exactly two specific parties. 
> I'm not.

	so your talking about multicast?  last i checked, nearly all traffic
	was unicast; e.g. end to end, e.g. between exactly two specific parties.

> 
> >>On a related issue, I'd be interested to know what the reachability 
> >>degradation was like for the last of the 3ffe:: space after 6/6/6?  You 
> >>didn't happen to do any measurements on it?
> >
> >	your general qustion (prefix reachability) is based on (imho again)
> >	a flawed premise...  if i may, could you clarify the two endpoints 
> >	for
> >	such a reachability study?  
> 
> I was thinking more of X = time, Y = % of ipv6 space reachable from 
> ${3ffe}, where 100% at a particular timepoint would be # of reachable 
> prefixes from some place known to be relatively well connected (cue flames 
> for fuzzy specification).  Given your reaction to the question, it sounds 
> like you haven't done looked into this, which is a minor pity.

	but that is the wrong question.  how in the world do you ensure reachability
	across thousands of ASNs, each of which is willing/able to set their own
	policies about prefix acceptance?  I'm almost persuaded that I don't WANT
	reachability to all that v6 space...  too many places to hid spambots.
	(and yes, the fuzzy specification is hard to code to... :)

> Nick,
> bill's friend(tm)

	thats a new one... :)  care to take out a partnership in "Bills Bait & Sushi"	... there are franchise ops available.





More information about the ARIN-PPML mailing list