Robert Elz wrote:
> Yes, that would be fine, and that's just what Steve Blake suggested in
> a message sent a few minute after yours. Stable addressing is what's
> needed - the bit pattern that identifies it isn't important.
>
> But note the bit patterns sugg
Robert Elz wrote:
> And that is exactly why 1918 was written, and as the need hasn't changed
> in the slightest, exactly why site locals (or something equivalent) are
> needed now.
A simple proposal:
FEC0::/48 good enough for (most) home nets, SOHO, etc.
FEE<36-bit random#
Jim Bound wrote:
> with all due respect. rfc 1918 was a hack and never would pass the IESG
> today IMO they are doing a far better job these days causing us to detail
> our network views and development of protocols. 1918 has wrecked the
> Internet.
Ripping site-locals out of the specs will not
Jarno Rajahalme wrote:
> Steve Blake wrote:
> > RFC2475 was built on the assumption of bilateral agreements between
> > peering providers, because that was the only model that had a hope
> > of being deployed.
>
> Has this changed? Would there be hope for non-locally
Tony Hain wrote:
> Steve Blake wrote:
>
> > I agree with your conclusion, but I disagree with the assumptions
> > you are making about diffserv (for the sake of argument, say).
> I assume you are talking about the WG not the protocol. :)
Actually, the opposite. :)
>
Tony Hain wrote:
> At this point what we can't afford is redefining a field simply
> because the diffserv WG refused to create a set of end-to-end
> consistent bits. It is no surprise that people are finding it
> difficult to build hardware that will make consistent decisions
> when all the
> You're forcing the use of a subset of Diffserv on everybody.
>
> One MUST be able to use Diffserv with IPv6, at a not lesser extent than
> Intserv with IPv6.
>
> This is even more so, when it does not cost anything, or much, as you
> seemed to agree at one point.
IPv6 supports Diffserv tod
Thomas Eklund wrote:
> I also saw Steve Blakes comment that is not recommended to use TCP/UDP ports
> in the hash key for ECMP but the one of the biggest problem with the
> bundling is to send one TCP flow over different path since it might end up
> in packet re-ordering due the different delays
Derek Fawcus wrote:
> Specifically - I see it as a way of replacing the srcPort/dstPort tuple
> that routers peek at in the TCP/UDP header. Currently I only see this
> being used in one scenario, that is for load balancing across multiple
> paths.
>
> At the moment (for v4) if a lookup on the
Brian Carpenter wrote:
> Thomas Narten wrote:
> ...
> > In my view, deciding on the right useage of the bits requires first
> > understanding the problem that needs to be solved.
>
> I think that from the QOS viewpoint, we do understand the problem very well,
> hence the proposal to add a diffs
Brian Carpenter wrote:
> > Therefore it is pointless adding any semantics to the field, because
> > even if there, they can't (won't) be used.
>
> But there's a recursion here. If you choose to believe port and protocol
> numbers, then all cheaters have to do is encapsulate their low priority
>
Brian Carpenter wrote:
> The traffic class field is not enough. If you have to re-classify traffic at
> an administrative boundary, then by definition at that point the traffic class
> field is inadequate; you need more information. The advantage that IPv6 has
> is that even when the header is p
12 matches
Mail list logo
