You're looking at the internet of today.
Think about 10, 15, 20 years out when everything you buy at the grocery store
has an IP address and most audio amplifiers act as routers to head-end the
other entertainment devices in the cluster.
Think about a time when HDMI is supplanted by
On Jun 2, 2013, at 11:21 PM, Owen DeLong
o...@delong.commailto:o...@delong.com wrote:
Yes. A fine engineering solution for demonstration purposes, but not a good
solution for us to recommend for deployment in the long term. Because it
commits wide prefixes to sub-delegations, it wastes
On Jun 2, 2013, at 11:24 PM, Owen DeLong
o...@delong.commailto:o...@delong.com wrote:
No, there is no use case where this is better than doing the delegations from
the router that received the initial delegation (since we're apparently just
arguing by vigorous assertion).
Is your opinion. I
On Jun 2, 2013, at 11:26 PM, Owen DeLong
o...@delong.commailto:o...@delong.com wrote:
My point is that it should be up to the person running the home net (or other
end site) to decide what is better for their site and that we should not be
making the choice for them.
So, to recap, RIR policies
Folks,
This version of the I-D is meant to address feedback from Alissa Cooper,
Dave Thaler, and Tom Petch.
For the most part, these are the changes:
* A new appendix has been added, detailing the types of attacks we want
to mitigate.
* I've added some text noting that an attacker has a
On Jun 3, 2013, at 7:27 AM, Ted Lemon ted.le...@nominum.com wrote:
On Jun 2, 2013, at 11:21 PM, Owen DeLong o...@delong.com wrote:
Yes. A fine engineering solution for demonstration purposes, but not a
good solution for us to recommend for deployment in the long term.
Because it
On Jun 3, 2013, at 7:32 AM, Ted Lemon ted.le...@nominum.com wrote:
On Jun 2, 2013, at 11:24 PM, Owen DeLong o...@delong.com wrote:
No, there is no use case where this is better than doing the delegations
from the router that received the initial delegation (since we're
apparently just
If I am reading this correctly, in the end this is riven by the fact
that existing boxes can easily filter on addresses (although it will
take a lot of filters), but can not apply ACLs to DSCPs or extension
headers?
It seems like what we need is a draft that clearly explains why trying
to
Hi,
On 31.05.2013 11:46, Ray Hunter wrote:
But why are people coming up with these schemes for encoding semantics
in the address prefixes in the first place? That's what I'd like to
understand first and foremost: what lack of functionality is
motivating/forcing these people to adopt such
On Jun 3, 2013, at 9:46 AM, Owen DeLong
o...@delong.commailto:o...@delong.com wrote:
I believe that making bits available for greater flexibility in consumer
networking is a good use of bits.
I believe that stealing bits from the consumer for purposes of allowing the
provider to overload the
On Jun 3, 2013, at 9:22 AM, Ted Lemon ted.le...@nominum.com wrote:
On Jun 3, 2013, at 9:46 AM, Owen DeLong o...@delong.com wrote:
I believe that making bits available for greater flexibility in consumer
networking is a good use of bits.
I believe that stealing bits from the consumer for
-Original Message-
From: v6ops-boun...@ietf.org [mailto:v6ops-boun...@ietf.org] On Behalf Of
Joel M.
Halpern
Sent: Monday, June 03, 2013 4:07 PM
To: Sheng Jiang
Cc: v6...@ietf.org; draft-jiang-v6ops-semantic-pre...@tools.ietf.org;
ipv6@ietf.org
Subject: Re: [v6ops] Could IPv6
Hi, Shane,
Actually, we do assume the SP deploys unicast filters to drop incoming
packets with illegitimate source IP address/prefix. After then, the packets
become trusted.
It is the filter who makes sure the prefix right. The filter should link
back to other states of the user, like user
I have to say the hierarchical assignment is a such great way to waste
address space or prefix bit. I cannot real see much benefits or use cases
of it. Why may home site 3 subordinate routers? How many subnets or devices
may a /48 prefix serve in this model?
Cheers,
Sheng
On 3 June 2013 00:39,
On 2June2013Sunday, at 16:47, Sander Steffann wrote:
On 03/06/2013 11:06, manning bill wrote:
/48's are a horrible policy - one should only advertise what one is actually
using.
Now *that* would cause a nice fragmented DFZ...
Sander
I'm going to inject a route. One route. why do
On 2June2013Sunday, at 16:47, Sander Steffann wrote:
On 03/06/2013 11:06, manning bill wrote:
/48's are a horrible policy - one should only advertise what one is
actually using.
Now *that* would cause a nice fragmented DFZ...
Sander
I'm going to inject a route. One route. why do
On 3June2013Monday, at 8:51, Sander Steffann wrote:
On 2June2013Sunday, at 16:47, Sander Steffann wrote:
On 03/06/2013 11:06, manning bill wrote:
/48's are a horrible policy - one should only advertise what one is
actually using.
Now *that* would cause a nice fragmented DFZ...
Sander
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
manning bill
Pragmatically, much of the IPv6 protocol/application development has
ignored half the 128bit space and treats IPv6 as a 64bit address platform.
Exactly.
It's time to
The IESG has approved the following document:
- 'Security Implications of IPv6 Fragmentation with IPv6 Neighbor
Discovery'
(draft-ietf-6man-nd-extension-headers-05.txt) as Proposed Standard
This document is the product of the IPv6 Maintenance Working Group.
The IESG contact persons are
On 04/06/2013 03:44, manning bill wrote:
On 2June2013Sunday, at 16:47, Sander Steffann wrote:
On 03/06/2013 11:06, manning bill wrote:
/48's are a horrible policy - one should only advertise what one is
actually using.
Now *that* would cause a nice fragmented DFZ...
Sander
I'm going
- Original Message -
From: Brian E Carpenter brian.e.carpen...@gmail.com
To: manning bill bmann...@isi.edu
Cc: ipv6@ietf.org; v6...@ietf.org WG v6...@ietf.org
Sent: Tuesday, 4 June 2013 6:27 AM
Subject: Re: [v6ops] Could IPv6 address be more than
That's completely true; many switch chips cannot route on longer than /64
prefixes, so attempting to do so starts to either heat up the software slow
path, or consume ACL entries, or is simply not supported at all. While
this is arguably a bug, it is also pretty much ubiquitous in the current
On 6/3/13 3:59 PM, Andrew McGregor wrote:
That's completely true; many switch chips cannot route on longer than
/64 prefixes, so attempting to do so starts to either heat up the
software slow path, or consume ACL entries, or is simply not supported
at all. While this is arguably a bug, it is
Ok maybe I'm overstating it a bit... but there are a lot of those chips out
there, and they are painful.
On Tue, Jun 4, 2013 at 9:08 AM, joel jaeggli joe...@bogus.com wrote:
On 6/3/13 3:59 PM, Andrew McGregor wrote:
That's completely true; many switch chips cannot route on longer than /64
This looks a typical double standard for me. You are willing to allow
homenet (the network operator in this case is subscribers) to play semantic
in their networks with the bits from 48 to 63, while you disallow ISPs to
set the semantic bits in their networks with the bits from 20 to 48 or 56.
You
Exactly. I agree we should not block the possibility for the future.
However, I don't agree we should block the current requirements to make the
way for the uncertainties of future. We should first serve the needs today,
then we the better current network will become a better fundamental for our
Hi, Roland,
Thanks for your comments. Yes, the authors will restructure this draft -
making it more an analysis draft rather than a proposal. The pitfalls will
be an very important part for a neutral analysis.
Cheers,
Sheng
On 3 June 2013 22:09, Bless, Roland (TM) roland.bl...@kit.edu wrote:
They are stealing from the consumer's flexibility to
provide (questionable) functionality to the provider.
What's the problem if the consumer get /48 as you want, and providers play
their 28 bits (bit 20~47)?
For me, the consumer flexibility looks more uncertain although I don't have
much
On Mon, Jun 3, 2013 at 11:59 PM, Vízdal Aleš ales.viz...@t-mobile.czwrote:
If I am reading this correctly, in the end this is riven by the fact
that existing boxes
can easily filter on addresses (although it will take a lot of filters),
but can not apply
ACLs to DSCPs or extension
On Tue, Jun 4, 2013 at 10:29 AM, Sheng Jiang shengji...@gmail.com wrote:
They are stealing from the consumer's flexibility to
provide (questionable) functionality to the provider.
What's the problem if the consumer get /48 as you want, and providers play
their 28 bits (bit 20~47)?
The
Read the recent p2p /64 thread of ipv6-ops cluenet mailing list
=
Mistyped and autocorrected on a clunky virtual keyboard
On 4. jun. 2013, at 01:08, joel jaeggli joe...@bogus.com wrote:
On 6/3/13 3:59 PM, Andrew McGregor wrote:
That's completely true; many switch chips cannot route on
Just to remind people, RIR policy is community driven. If the operations
people feel they need a policy for IPv6 allocations and assignments which
takes accounts of semantic bits, they can derive consensus driven policies
to do it. Its not done in the IETF. There might be an issue with how it
On Jun 3, 2013, at 17:59 , Sheng Jiang shengji...@gmail.com wrote:
This looks a typical double standard for me. You are willing to allow homenet
(the network operator in this case is subscribers) to play semantic in their
networks with the bits from 48 to 63, while you disallow ISPs to set
Semantic addresses is beyond the access control. For example, you can
compare the security semantic bits of source and destination addresses. If
they belong to different security domain, and you have a policy they should
not communicate each other, you could drop the packet.
Sheng
On 4 June
On 6/3/13 7:11 PM, Ivan Pepelnjak wrote:
Read the recent p2p /64 thread of ipv6-ops cluenet mailing list
You are refering to:
http://lists.cluenet.de/pipermail/ipv6-ops/2013-June/thread.html
I stand by my statement...
The inability to properly apply ACLs on the 3750 for routes longer than
35 matches
Mail list logo
