> On Sun, 21 Oct 2007 13:22:08 +0200
> Jeroen Massar <[EMAIL PROTECTED]> wrote:
>
>> Hi,
>>
>> I just noticed
>> http://www.nanog.org/mtg-0710/presentations/Dickson-lightning.pdf
>> and found some serious flaws and most likely misunderstandings in the
>> way that some things are presented in there.
> Hi,
>
> I just noticed
> http://www.nanog.org/mtg-0710/presentations/Dickson-lightning.pdf
> and found some serious flaws and most likely misunderstandings in the
> way that some things are presented in there. It was already publicly
> presented at the NANOG meeting, so lets discuss ;)
>
>
>
> =
> On Thu, 04 Oct 2007 19:40:50 -0400
> Brian Dickson <[EMAIL PROTECTED]> wrote:
>
>> (Please excuse minor formatting issues and the occasional spelling
>> mistake - this is version 00 of the draft.)
>>
>> This I-D is the one you've all been waiting for, after the "16 bits
>> between friends" thread
>> The following is meant to be used for demonstration purposes.
>> It is meant for any and all to make reference to in discussions where
>> "16 bits" may come into play.
>
> ip address allocation has nothing to with the physical object sizes.
> for instance, you can have 2 separate ip
> I'm not quite sure what point you're making.
>
> If it's the size of the network part or the host part of an IPv6
> address, as I recall the logic, the original stated requirement was
> that an ipng address should be able to represent 10^12 networks (42
> bits) and 10^15 hosts (52 bits). Consider
> Brian D,
>
> You seem to be assuming that PI will be the dominant mode.
Not at all. I am assuming that prefixes in the DFZ won't be deaggregated
to any significant degree. All PA are aggregated, in theory at least,
under PI prefixes.
I am in fact only assuming PI prefixes as numerous as ASNs.
A
Iljitsch wrote:
> On 29-aug-2007, at 16:23, Thomas Narten wrote:
>>> (I suppose it's a bit late in the game to go back to MAC-48 as II?)
>
>> Yes. The difficulty is figuring out how to move to something different
>> in a backwards-compatable way. I.e., we'd need a transition strategy.
>
> But what
> Jun-ichiro itojun Hagino writes:
>> again, it is about rather serious security problem, which risked
>> the DNS root name servers. it's quite serious and really urgent.
>> the RFC publication should have finished way earlier.
>
> Of course security problems are important. However
> On Aug 27, 2007, at 9:29 AM, Tim Enos wrote:
>
>> Good point. This would be true even in the face of a company on the
>> JP side and a company on the US side (of the JP-US link) agreed
>> together to accept source-routed traffic from each other.
>>
>> Just having the RH0 traffic transit the inter
> On Mon, Aug 20, 2007 at 01:43:19PM -0700, Bob Hinden wrote:
>> 1) Deprecate RH0 as specified in .
>
> I support this option, because it seems to me that the existing draft
> makes the correct point: another rh[n] could be introduced to add the
> desired features without exposing the same vulnerab
(I realize this list might not represent the bulk of the deployed IPv6
networks... nonetheless, I'm curious.)
This is an informal survey of what is deployed in terms of IPv6 networks.
Do you use autoconf only, static assignments only, or a mix?
Any additional info about what, why, etc., would be
I was attempting to get to the bottom of what is, to me, a mystery:
Why does IPv6 use EUI-64 for Interface Identifiers, instead of MAC-48?
The previous version of the RFCs used MAC-48. There seems to have been,
at some point, some discussion regarding the difference between EUI-48 and
MAC-48, as
> On Tue, 3 Jul 2007, Paul Vixie wrote:
>>> The general idea is that the bulk of address assignments used should
>>> be,
>>> one would expect and hope, PA, and aggregated, into large assignments
>>> of PI blocks (ideally one per ASN) in the DFZ. The scalability of the
>>> DFZ depends on this, in fa
I think we should avoid any "straw man" arguments, as those tend not to
actually help advance the subject matter.
Just because one way of accomplishing a particular networking objective,
involves particularly unpleasant choices, does not mean that the technology
involved is at fault. It is also po
>> > With the current draft, that is correct. With Paul's proposed changes
>> of
>> > 27 Jun, they definitely aggregate at the LIR and RIR levels, making it
>> > much harder to defend the position that they won't end up in the DFZ.
>
> the aggregation present in that version was unintentional. if
Paul Vixie wrote:
> the competing visions as i understand them are "random-prefix ULA-C makes
> it
> impossible to postprocess one's log files on computers outside the
> connectivity realm where they were gathered, makes recourse against
> spammers
> and ddos-for-hire crews even harder, and moves t
>> >> If those numbers fit within reasonable guesses about sustainable
>> >> DFZ growth, no problem.
>>
>> > they don't fit, but they don't have to fit, because they're not going
>> in.
>>
>> How is this going to work? Are you assuming NATv6?
>
> no. i'm assuming that the days when the DFZ was t
> Date: Fri, 29 Jun 2007 20:23:54 +
> From: Paul Vixie <[EMAIL PROTECTED]>
> Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt
> To: ipv6@ietf.org
> Message-ID: <[EMAIL PROTECTED]>
>
>> Additionally, I believe that there exist RIR policies which are
>> resulting
>> in some pressure tow
> Date: Fri, 29 Jun 2007 15:57:29 +
> From: Paul Vixie <[EMAIL PROTECTED]>
> Subject: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt
> To: ipv6@ietf.org
> Message-ID: <[EMAIL PROTECTED]>
>
>> So, IMHO it would be premature to turn over address
>> delegation authority at this time.
>
> then l
(Yes, it's my first post, but I thought it would be good to establish early
on a track record of keeping on-topic and moving things in a positive
direction...)
I've read the draft, and the CanSecWest slides that it references.
The network nodes I've worked on have deployed filters to prevent RH0
a
20 matches
Mail list logo
