This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot)
- Previous message (by thread): [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot)
- Next message (by thread): [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Nick Hilliard
nick at inex.ie
Tue May 15 13:47:09 CEST 2007
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. Well, we can talk about individual scenarios but let's not, because there's no problem cooking up situations where ULA-central could have some conceivable merit, in terms of regular reachability between two arbitrary parties on the public v6 internet, although I can't really think of any case where it would be more useful than, say regular PI or PA. Before abandoning this thought, consider: - 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? - do you want to go beyond communications between R and S? 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. >> 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 :-) > 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. >> 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. Nick, bill's friend(tm)
- Previous message (by thread): [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot)
- Next message (by thread): [address-policy-wg] Re: [ppml] article about IPv6 vs firewalls vs NAT in arstechnica (seen on slashdot)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]