On Thu, 2012-07-19 at 19:30 -0500, Jimmy Hess wrote:
> > The ratio of the number of bits doesn't tell you anything about
> > whether the number was random or not.
>
> Sure it does. A ratio of 1s to 0s of a sufficient deviation, is a
> sufficient but not a necessarily condition, for establishing
On 7/19/12, Mark Andrews wrote:
> Actually you can't.
> fdaa:: has 20/20 0/1 bits but is entirely non random.
> fdf0:f0f0:f0f0 has 20/20 0/1 bits but is entirely non random.
[snip]
> The ratio of the number of bits doesn't tell you anything about whether
> the number was random
On (2012-07-19 14:29 -0400), valdis.kletni...@vt.edu wrote:
> OK? So even if you merge and re-merge, and go on a massive buying spree and
> accumulate a network where you have to interoperate 1,000 ULAs, you're *still*
> looking at a literally million-to-one shot. And if you only have a mess of
On Wed, 18 Jul 2012 21:07:35 +0300, Saku Ytti said:
> If collision occurs, if dispute occurs, provability that one party did not
> use BCP method can be useful to solve dispute and decide who renumbers.
Looking at actual numbers out of RFC4193:
The following table shows the probability of a c
On 19-Jul-12 07:47, Mark Andrews wrote:
> In message
> , Jimmy
> Hess writes:
>> When numbers are selected by choosing a random value; certain ratios of bits
>> set to "1" are more likely to occur than other ratios of bits set to "1".
>>
>> A random generator that is operating correctly, is much
On 18-Jul-12 22:57, Karl Auer wrote:
> I don't understand the professed need for provable randomness.
I think his concern is that if an SP generates a ULA prefix for a
customer, and that prefix happens to collide with someone else's ULA
prefix, the SP may wish to prove that it was a true collision
On 18-Jul-12 13:07, Saku Ytti wrote:
> On (2012-07-18 11:39 -0500), Stephen Sprunk wrote:
>> Those were not considered requirements for the algorithm in RFC 4193 since
>> there is no scenario /where RFC 4193 addresses are a valid solution in the
>> first place/ for which testability or provabilit
On Thu, 19 Jul 2012 07:40:31 -0700, Cameron Byrne said:
> 3. Most FUD around ULA comes from an over-reaction to ipv4 NAT sins,
> misunderstandings about how security policy works in the real world , and
> deficiencies in mathmatical education.
I'll add on that said security policies are *themselv
If i may summarize this thread as a method to conclude it.
1. Some people like GUA the most.
2. Smart network operators understand the facts and make decisions based on
facts (ULA exist, and it meets a need in some scenarios. NAT and lack of
addresses are not reasons to use ULA).
3. Most FUD aro
In message
, Jimmy Hess writes:
> On 7/18/12, Karl Auer wrote:
> > I don't understand the professed need for provable randomness. Without a
> > number *space* to provide context, randomness is inherently
> > non-provable. The whole point of the randomness of those 40 bits of ULA
> > infix is tha
On (2012-07-19 15:16 +1000), Karl Auer wrote:
> True. But you cannot tell, from a sample of one number, whether that
> number was chosen randomly. You can only test it statistically within a
> series. A particular number may be random in one sequence, non-random in
> another.
RFC2777 deals with t
On (2012-07-19 10:25 +1000), Mark Andrews wrote:
> The point of the algorithm was to have something which would do a
> reasonable job in a CPE router without a hardware source of randomness.
In that context it very much makes sense.
> It is a "SAMPLE" routinue. It is not "YOU MUST DO IT THIS
On Wed, 2012-07-18 at 23:40 -0500, Jimmy Hess wrote:
> When numbers are selected by choosing a random value; certain ratios
> of bits set to "1" are more likely to occur than other ratios of bits
> set to "1".
True. But you cannot tell, from a sample of one number, whether that
number was chosen
On 7/18/12, Karl Auer wrote:
> I don't understand the professed need for provable randomness. Without a
> number *space* to provide context, randomness is inherently
> non-provable. The whole point of the randomness of those 40 bits of ULA
> infix is that any number is as likely as any other numbe
In message
, Jimmy Hess writes:
> On 7/18/12, Mark Andrews wrote:
> [snip]
> > space, you meet the requirements. Toss a coin for each bit. Heads
> > =3D 1, tails =3D 0.
> Sure... and if someone says they just happened to toss a coin 128
> times, and got "0" all 128 times, therefore legitimat
On Wed, 2012-07-18 at 22:00 -0500, Jimmy Hess wrote:
> Sure... and if someone says they just happened to toss a coin 128
> times, and got "0" all 128 times, therefore legitimately assigned ULA
> ID is all zeros,I don't believe them.
Um - 40 times, not 128. The first 8 are set, the last 80 ar
On 7/18/12, Mark Andrews wrote:
[snip]
> space, you meet the requirements. Toss a coin for each bit. Heads
> = 1, tails = 0.
Sure... and if someone says they just happened to toss a coin 128
times, and got "0" all 128 times, therefore legitimately assigned ULA
ID is all zeros,I don't belie
In message <20120718180735.ga11...@pob.ytti.fi>, Saku Ytti writes:
> On (2012-07-18 11:39 -0500), Stephen Sprunk wrote:
> > On 18-Jul-12 08:48, Saku Ytti wrote:
>
> > Why would they do that? SPs should only be assigning (and routing) GUAs.
>
> Because SP might be tasked to provide network plan
On (2012-07-18 11:39 -0500), Stephen Sprunk wrote:
> On 18-Jul-12 08:48, Saku Ytti wrote:
> Why would they do that? SPs should only be assigning (and routing) GUAs.
Because SP might be tasked to provide network plan for customers L3 MPLS
VPN and customer might get INET from different SP and migh
On 18-Jul-12 08:48, Saku Ytti wrote:
> On (2012-07-18 08:37 -0500), Stephen Sprunk wrote:
>> There is no need for [RFC2777 verifiability], since your failure to use a
>> good source of randomness hurts nobody except yourself.
>
> I think you're making fact out of opinion. Maybe SP is generating UL
Sent from my iPad
On Jul 18, 2012, at 8:48 AM, Saku Ytti wrote:
> On (2012-07-18 08:37 -0500), Stephen Sprunk wrote:
>
>>> it should bepossible to incorporate RFC2777 verifiability to it.
>>
>> There is no need for that, since your failure to use a good source of
>> randomness hurts nobody e
On 07/18/2012 06:10 AM, valdis.kletni...@vt.edu wrote:
On Wed, 18 Jul 2012 10:04:05 +0300, Saku Ytti said:
However I'm not sure what would be good seed? ISO3166 alpha2 +
domestic_business_id + 0..n (for nth block you needed)
You want to roll in at some entropy by adding in the current date or
On (2012-07-18 08:47 -0500), Stephen Sprunk wrote:
> And, if they did, who cares? It's not like it hurts me for them to do
> so--unless I'm dumb enough to do the same thing, happened to get the
> same result /and/ happened to merge with them--all of which are still
> unlikely events.
In which ca
On (2012-07-18 08:37 -0500), Stephen Sprunk wrote:
> > it should bepossible to incorporate RFC2777 verifiability to it.
>
> There is no need for that, since your failure to use a good source of
> randomness hurts nobody except yourself.
I think you're making fact out of opinion. Maybe SP is gene
On 18-Jul-12 08:25, Saku Ytti wrote:
> On (2012-07-18 09:10 -0400), valdis.kletni...@vt.edu wrote:
>> You want to roll in at some entropy by adding in the current date or
>> something, so two "Joes' Burritos and Internet" in 2 different states don't
>> generate the same value. There's a reason t
On 18-Jul-12 02:04, Saku Ytti wrote:
> On (2012-07-18 00:34 +0200), Jeroen Massar wrote:
>>> Here's a calculator that will generate a random one for you:
>> does not follow RFC4193 in any way at all. A such do not use it.
> I'm not sure if RFC4193 is best way to generate random part,
It's not clai
On (2012-07-18 09:10 -0400), valdis.kletni...@vt.edu wrote:
> You want to roll in at some entropy by adding in the current date or
> something, so two "Joes' Burritos and Internet" in 2 different states don't
> generate the same value. There's a reason that 4193 recommends
> a 64bit timestamp and
On Wed, 18 Jul 2012 10:04:05 +0300, Saku Ytti said:
> However I'm not sure what would be good seed? ISO3166 alpha2 +
> domestic_business_id + 0..n (for nth block you needed)
You want to roll in at some entropy by adding in the current date or
something, so two "Joes' Burritos and Internet" in 2 d
On (2012-07-18 00:34 +0200), Jeroen Massar wrote:
> > Here's a calculator that will generate a random one for you:
>
> does not follow RFC4193 in any way at all. A such do not use it.
Another silly oneliner, not RFC4193.
ruby -e'p ("fd"+rand(2**40).to_s(16)).scan(/.{1,4}/).join(":")+"::/48"'
I'
In message <5005e87d.6060...@unfix.org>, Jeroen Massar writes:
> On 2012-07-18 00:21, Seth Mattinen wrote:
> [..]
> > Don't, because there's already a /10 defined for such things. It's
> > called ULA (unique local address) aka RFC 4193. ULAs are not globally
> > routable.
> >
> > Here's a calcula
On 7/17/12 3:57 PM, Jeroen Massar wrote:
>
> I am wondering what you meaning with 'squat', note that what I reference
> above is real full RFC4193 calculated ULA.
>
By "squat" I meant take a random chunk of IPv6 space and use it as
"private" address space. He said:
On 7/13/12 7:38 AM, -Hammer-
On 2012-07-18 00:57, Jeroen Massar wrote:
> On 2012-07-18 00:47, Seth Mattinen wrote:
> [..]
Here's a calculator that will generate a random one for you:
http://bitace.com/ipv6calc/
[..]
> Yes, it is a shame that the bitace thing references RFC4193 and then
> does not use it. Lets Bc
On 2012-07-18 00:47, Seth Mattinen wrote:
[..]
>>> Here's a calculator that will generate a random one for you:
>>>
>>> http://bitace.com/ipv6calc/
>>
>> A random one indeed, because the javascript for it is just:
[..]
>> does not follow RFC4193 in any way at all. A such do not use it.
>>
>> The or
On 7/17/12 3:34 PM, Jeroen Massar wrote:
> On 2012-07-18 00:21, Seth Mattinen wrote:
> [..]
>> Don't, because there's already a /10 defined for such things. It's
>> called ULA (unique local address) aka RFC 4193. ULAs are not globally
>> routable.
>>
>> Here's a calculator that will generate a rand
On 2012-07-18 00:21, Seth Mattinen wrote:
[..]
> Don't, because there's already a /10 defined for such things. It's
> called ULA (unique local address) aka RFC 4193. ULAs are not globally
> routable.
>
> Here's a calculator that will generate a random one for you:
>
> http://bitace.com/ipv6calc/
On 7/13/12 7:38 AM, -Hammer- wrote:
> OK. I'm pretty sure I'm gonna get some flak for this but I'll share this
> question and it's background anyway. Please be gentle.
>
> In the past, with IPv4, we have used reserved or "non-routable" space
> Internally in production for segments that won't be se
On 7/17/2012 5:47 AM, Saku Ytti wrote:
> I wonder who really believes there is no usage case for NAT66. Have these
> people seen non-trivial corporate networks?
>
> I'm sure many people in this list finance part of their lives with renumber
> projects costing MUSDs. For many companies just finding
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 7/17/2012 12:15 AM, Karl Auer wrote:
> But I do not have an encylopaedic knowledge of all the RFCs, so
> perhaps this has been superseded, obsoleted or updated...
This gets a lot easier if you use the tools site:
https://tools.ietf.org/html/rfc4
On Monday 16 July 2012 21:11:18 you wrote:
> The disadvantage to this is the high probability of packet duplication. For
> someone worried about ICMP spam on the subnet, I'm surprised you're not
> worried about what happens when 2 or more routers copy the same packet
> and route both copies on to t
With all due respect to Owen, I don't share the view that everyone
should be jumping into BGP or getting an allocation from ARIN, but
that's been a long-standing debate between us.
NPT allows you to get prefixes from multiple ISPs without having to
get an allocation to coordinate routing; or in th
There's are routing and switching people and there are security people.
And they look at things different. That, IMHO, is the root of the
emotion on this thread. No one is actually wrong except me for stirring
the pot as the OP. :)
-Hammer-
"I was a normal American nerd"
-Jack Herer
On 7/17/
I wonder who really believes there is no usage case for NAT66. Have these
people seen non-trivial corporate networks?
I'm sure many people in this list finance part of their lives with renumber
projects costing MUSDs. For many companies just finding out where addresses
have been punched in (your F
-Hammer-
"I was a normal American nerd"
-Jack Herer
On 7/16/2012 11:18 PM, Jimmy Hess wrote:
On 7/16/12, -Hammer- wrote:
hurdles. Example? HSRP IPv6 global addressing on Cisco ASR platform. If
HSRP is a legacy proprietary protocol; try VRRP. Stateless
autoconfig and router advertisement
I have almost one hundred FWs. Some physical. Some virtual. Various
vendors. Your point is spot on.
-Hammer-
"I was a normal American nerd"
-Jack Herer
On 7/16/2012 8:55 PM, Lee wrote:
On 7/16/12, Owen DeLong wrote:
Why would you want NAT66? ICK!!! One of the best benefits of IPv6 is being
On Jul 17, 2012, at 3:15, Karl Auer wrote:
> Reading it with a squint: The phrase "packets [...] will be delivered to
> one router on the subnet" does not specifically exclude the possibility
> that packets will be delivered to more than one router on the subnet.
> Still, I do think it would be
On 7/16/12, Grant Ridder wrote:
> If you are running an HA pair, why would you care which box it went back
> through?
You wouldn't. But if you've got an HA pair at site A and another HA
pair at site B..
Lee
>
> -Grant
>
> On Monday, July 16, 2012, Mark Andrews wrote:
>
>>
>> In message > squu
On 7/16/12, Mark Andrews wrote:
>
> In message
> , Lee
> writes:
>> On 7/16/12, Owen DeLong wrote:
>> >
>> > Why would you want NAT66? ICK!!! One of the best benefits of IPv6 is
>> > being
>> > able to eliminate NAT. NAT was a necessary evil for IPv4 address
>> > conservation. It has no good use
On Mon, 2012-07-16 at 23:36 -0700, Owen DeLong wrote:
> Reread the spec... [the subnet router anycast address] gets the packet
> to one or more of the routers and it may well lead to packet
> duplication. There may or may not be coordination between the
> routers. It isn't in the spec.
Which spec?
Op 17-7-2012 8:43, Owen DeLong schreef:
On Jul 16, 2012, at 10:36 PM, Seth Mos wrote:
Hi,
Op 16 jul 2012, om 18:34 heeft valdis.kletni...@vt.edu het volgende geschreven:
To highlight what the current NAT66 is useful for, it's a RFC for Network
Prefix translation. It has nothing do with obfus
On Mon, 2012-07-16 at 23:44 -0700, Owen DeLong wrote:
> The whole concept of gratuitous arp is strictly IPv4.
Isn't an unsolicited neighbour advertisement pretty much the same thing?
Regards, K.
--
~~~
Karl Auer (ka...@biplane.
On Jul 16, 2012, at 11:16 PM, Jimmy Hess wrote:
> On 7/17/12, Karl Auer wrote:
> [snip
>> I'm not sure I follow the logic there. If the anycast router changes the
>> packet will be resent to the new subnet anycast router eventually
>> (assuming some layer cares enough about the packet to resend
On Jul 16, 2012, at 10:36 PM, Seth Mos wrote:
> Hi,
>
> Op 16 jul 2012, om 18:34 heeft valdis.kletni...@vt.edu het volgende
> geschreven:
>
>> On Mon, 16 Jul 2012 11:09:28 -0500, -Hammer- said:
>>> ---That is clearly a matter of opinion. NAT64 and NAT66 wouldn't be
>>> there
>>> if there
On Jul 16, 2012, at 10:20 PM, valdis.kletni...@vt.edu wrote:
> On Mon, 16 Jul 2012 21:31:42 -0700, Owen DeLong said:
>> Think HA pairs in Pittsburgh, Dallas, and San Jose.
>>
>> Now imagine each has different upstream connectivity and the backbone
>> network connecting all the corporate sites li
On Jul 16, 2012, at 9:40 PM, Karl Auer wrote:
> On Mon, 2012-07-16 at 23:38 -0400, Matt Addison wrote:
>> Oliver wrote:
>>> Additionally, as an alternative to RAs, you can simply point default
>>> at the all-routers anycast address.
>>
>> Wouldn't this result in duplicate packets leaving your n
On 7/17/12, Karl Auer wrote:
[snip
> I'm not sure I follow the logic there. If the anycast router changes the
> packet will be resent to the new subnet anycast router eventually
> (assuming some layer cares enough about the packet to resend it). The
> "last known hardware address" doesn't matter a
Op 17 jul 2012, om 04:56 heeft Grant Ridder het volgende geschreven:
> If you are running an HA pair, why would you care which box it went back
> through?
Because it could be/is a stateful firewall and the backup will drop the
traffic. (FreeBSD CARP)
Cheers,
Seth
>
> -Grant
>
> On Monday,
Hi,
Op 16 jul 2012, om 18:34 heeft valdis.kletni...@vt.edu het volgende geschreven:
> On Mon, 16 Jul 2012 11:09:28 -0500, -Hammer- said:
>> ---That is clearly a matter of opinion. NAT64 and NAT66 wouldn't be there
>> if there weren't enough customers asking for it. Are all the customers naive
On Tue, 2012-07-17 at 00:10 -0500, Jimmy Hess wrote:
> Just to reaffirm that.Rfc 4291 states packets sent to the
> subnet-router anycast will be delivered to one router on the subnet.
> [...]
> But what about packets with a destination address on another network
> and trying to use the anycast
On Mon, 16 Jul 2012 21:31:42 -0700, Owen DeLong said:
> Think HA pairs in Pittsburgh, Dallas, and San Jose.
>
> Now imagine each has different upstream connectivity and the backbone
> network connecting all the corporate sites lives inside those firewalls.
>
> The real solution to this is to move t
On 7/16/12, Karl Auer wrote:
> I think Oliver meant the subnet router anycast address.
> Anycast gets you to one-of-many. The routers work out which of them is
Just to reaffirm that.Rfc 4291 states packets sent to the
subnet-router anycast will be delivered to one router on the subnet.
Tha
On Mon, 2012-07-16 at 23:38 -0400, Matt Addison wrote:
> Oliver wrote:
> > Additionally, as an alternative to RAs, you can simply point default
> > at the all-routers anycast address.
>
> Wouldn't this result in duplicate packets leaving your network if
> there were more than 1 router listening
Think HA pairs in Pittsburgh, Dallas, and San Jose.
Now imagine each has different upstream connectivity and the backbone
network connecting all the corporate sites lives inside those firewalls.
The real solution to this is to move the backbone outside of the firewalls
and connect the internal ne
You could try this:
If you give a /48 to each site, then assign the sites primary and backup
firewalls.
Aggregate the /48s into larger blocks by primary firewall.
Aggregate the primary firewall bocks into larger backup firewall aggregates.
Advertise the firewall-specific aggregates and the le
On Jul 16, 2012, at 7:35 PM, Karl Auer wrote:
> On Mon, 2012-07-16 at 22:04 -0400, Lee wrote:
>> Each site gets a /48. Even the ones with less than 200 people.
>> [...]
>> Which is *boring*. Nothing novel, no breaking out of "IPv4 think"
>> aside from massively wasting address space.
>
> It's
On Jul 16, 2012, at 6:55 PM, Lee wrote:
> On 7/16/12, Owen DeLong wrote:
>>
>> Why would you want NAT66? ICK!!! One of the best benefits of IPv6 is being
>> able to eliminate NAT. NAT was a necessary evil for IPv4 address
>> conservation. It has no good use in IPv6.
>
> NAT is good for getting
On 7/16/12, -Hammer- wrote:
> hurdles. Example? HSRP IPv6 global addressing on Cisco ASR platform. If
HSRP is a legacy proprietary protocol; try VRRP. Stateless
autoconfig and router advertisements can obviate (eliminate/reduce)
the need in many cases; albeit, with a longer failure recovery
On Jul 16, 2012, at 12:39 PM, Oliver wrote:
> On Monday 16 July 2012 18:26:08 Rajendra Chayapathi wrote:
>> On the HSRP/ND part , this all falls in the First Hop redundancy areana
>> and can be achieved via any of the following and each has its merits and
>> cons..
>>
>> 1) Using ND -- need to t
On Jul 16, 2012, at 15:40, Oliver
wrote:
> Additionally, as an alternative to RAs, you can simply point default at the
> all-routers anycast address.
Wouldn't this result in duplicate packets leaving your network if
there were more than 1 router listening to 'all routers' and you (at
the MAC lay
In message
, Grant
Ridder writes:
>
> If you are running an HA pair, why would you care which box it went back
> through?
>
> -Grant
It still doesn't change the arguement. You still need to have flow
based routers or you may choose the wrong egress point and if you
need NAT66 you have 4+ ups
If you are running an HA pair, why would you care which box it went back
through?
-Grant
On Monday, July 16, 2012, Mark Andrews wrote:
>
> In message squumzofs3_-yrihy8o4gt3w9+x6f...@mail.gmail.com >, Lee
> writes:
> > On 7/16/12, Owen DeLong > wrote:
> > >
> > > Why would you want NAT66? ICK!!
In message
, Lee
writes:
> On 7/16/12, Owen DeLong wrote:
> >
> > Why would you want NAT66? ICK!!! One of the best benefits of IPv6 is being
> > able to eliminate NAT. NAT was a necessary evil for IPv4 address
> > conservation. It has no good use in IPv6.
>
> NAT is good for getting the return
On Mon, 2012-07-16 at 22:04 -0400, Lee wrote:
> Each site gets a /48. Even the ones with less than 200 people.
> [...]
> Which is *boring*. Nothing novel, no breaking out of "IPv4 think"
> aside from massively wasting address space.
It's only a waste if you get nothing for it. By using /64 every
On 7/15/12, John Levine wrote:
>>I feel like I should be able to do something really nice with an
>>absurdly large address space. But lack of imagination or whatever.. I
>>haven't come up with anything that really appeals to me.
>
> Use a fresh IP for every HTTP request, email message, and IM. J
On 7/16/12, Owen DeLong wrote:
>
> Why would you want NAT66? ICK!!! One of the best benefits of IPv6 is being
> able to eliminate NAT. NAT was a necessary evil for IPv4 address
> conservation. It has no good use in IPv6.
NAT is good for getting the return traffic to the right firewall. How
else
True .. Your point of the ICMPv6 storm is on mark and is one of the
drawbacks for this solution.
On 7/16/12 12:39 PM, "Oliver"
wrote:
>On Monday 16 July 2012 18:26:08 Rajendra Chayapathi wrote:
>> On the HSRP/ND part , this all falls in the First Hop redundancy areana
>> and can be achieved via
On Monday 16 July 2012 18:26:08 Rajendra Chayapathi wrote:
> On the HSRP/ND part , this all falls in the First Hop redundancy areana
> and can be achieved via any of the following and each has its merits and
> cons..
>
> 1) Using ND -- need to tune the "IPv6 nd reachable time" to achieve the
> fas
On Jul 13, 2012, at 8:05 AM, TJ wrote:
> On Fri, Jul 13, 2012 at 10:38 AM, -Hammer- wrote:
>
>> OK. I'm pretty sure I'm gonna get some flak for this but I'll share this
>> question and it's background anyway. Please be gentle.
>>
>> In the past, with IPv4, we have used reserved or "non-routabl
On the HSRP/ND part , this all falls in the First Hop redundancy areana
and can be achieved via any of the following and each has its merits and
cons..
1) Using ND -- need to tune the "IPv6 nd reachable time" to achieve the
faster failover
2) Using any of the First hop redundancy protocol ( HSRP,
"""
Why would you want NAT66? ICK!!! One of the best benefits of IPv6 is
being able to eliminate NAT. NAT was a necessary evil for IPv4 address
conservation. It has no good use in IPv6.
"""
NAT still has its uses; virtualization and cloud infrastructure being
one of the most legitimate.
Certain k
I agree. Most are naive. Not all.
-Hammer-
"I was a normal American nerd"
-Jack Herer
On 7/16/2012 11:34 AM, valdis.kletni...@vt.edu wrote:
On Mon, 16 Jul 2012 11:09:28 -0500, -Hammer- said:
---That is clearly a matter of opinion. NAT64 and NAT66 wouldn't be there
if there weren't enough
On Mon, 16 Jul 2012 11:09:28 -0500, -Hammer- said:
> ---That is clearly a matter of opinion. NAT64 and NAT66 wouldn't be there
> if there weren't enough customers asking for it. Are all the customers naive?
> I doubt it. They have their reasons. I agree with your "purist" definition and
> did n
Inline -
-Hammer-
"I was a normal American nerd"
-Jack Herer
1) (This one is currently a personal issue) I am still building up a true IPv6
skillset. Yes, I understand it for the most part but now is the time to apply
it.
Frankly, IMHO, the best way to build up a truly useful IPv6 skill set
On Jul 16, 2012, at 8:11 AM, -Hammer- wrote:
> There are multiple issues here. I understand most folks on these threads are
> beyond me but I'm pretty sure I'm not the only person in this position.
>
> 1) (This one is currently a personal issue) I am still building up a true
> IPv6 skillset. Y
There are multiple issues here. I understand most folks on these threads
are beyond me but I'm pretty sure I'm not the only person in this position.
1) (This one is currently a personal issue) I am still building up a
true IPv6 skillset. Yes, I understand it for the most part but now is
the ti
>I feel like I should be able to do something really nice with an
>absurdly large address space. But lack of imagination or whatever.. I
>haven't come up with anything that really appeals to me.
Use a fresh IP for every HTTP request, email message, and IM. Just think of how
well you can do error
On 7/14/12, Robert E. Seastrom wrote:
>
> Actually, that's one of the most insightful meta-points I've seen on
> NANOG in a long time.
>
> There is a HUGE difference between IPv4 and IPv6 thinking. We've all
> been living in an austerity regime for so long that we've completely
> forgotten how to
On Sun, 15 Jul 2012 17:55:44 -0600, "Keith Medcalf" said:
> Are you saying that there are other operating systems brain-dead enough to
> just run any old arbitrary code from untrusted media?
As Vint Cerf pointed out, 140 million pwned boxes. How you think they got that
way, and what are the chance
On 7/15/12, Keith Medcalf wrote:
> Ifconfig does not work on Windows.
Who needs ifconfig with windows?
any user who can open a cmd session can run IPCONFIG /ALL
The same can be queried remotely using WMI
Select * From Win32_NetworkAdapterConfiguration WHERE IPEnabled=true
> Are you saying that
> Ifconfig does not work on Windows.
i am about as far from a windows expert as you can get. but i believe
it is ipconfig
> Are you saying that there are other operating systems brain-dead
> enough to just run any old arbitrary code from untrusted media?
>
> Sent from my Android phone
ROFL!
]
Received: Sunday, 15 Jul 2012, 9:45
To: Jimmy Hess [mysi...@gmail.com]
CC: [nanog@nanog.org]; Brandon Ross [br...@pobox.com]
Subject: Re: using "reserved" IPv6 space
On Sat, 14 Jul 2012 17:37:37 -0500, Jimmy Hess said:
> The good news is one 'ifconfig' just tells them what n
On 7/15/12 11:58 AM, Grzegorz Janoszka wrote:
> On 2012-07-15 15:30, Scott Morris wrote:
>>> There was also in the past fec0::/10. For BGP updates you should be safe
>>> to filter out FC00::/6.
>> Unless I've missed something, RFC4193 lays out FC00::/7, not the /6. So
>> while FE00::/7 may yet be
On Jul 15, 2012, at 8:58 AM, Grzegorz Janoszka wrote:
> On 2012-07-15 15:30, Scott Morris wrote:
>>> There was also in the past fec0::/10. For BGP updates you should be safe
>>> to filter out FC00::/6.
>> Unless I've missed something, RFC4193 lays out FC00::/7, not the /6. So
>> while FE00::/7 m
On 15 July 2012 16:58, Grzegorz Janoszka wrote:
> Allowing 2000::/3 is fine as well. Btw - what are the estimates - how
> long are we going to be within 2000::/3?
>
I expect it to be long enough that we can enjoy lots of discussions
about how to deal with broken route filtering and broken softwar
On 2012-07-15 15:30, Scott Morris wrote:
>> There was also in the past fec0::/10. For BGP updates you should be safe
>> to filter out FC00::/6.
> Unless I've missed something, RFC4193 lays out FC00::/7, not the /6. So
> while FE00::/7 may yet be unallocated, I don't think I'd set filters in
> that
On Sat, 14 Jul 2012 17:37:37 -0500, Jimmy Hess said:
> The good news is one 'ifconfig' just tells them what network
> address you're in.
> Unless the attacker can gain access to your host's NDP table or ARP
> table, they can't see what IPs are in use.
All it takes is one USB stick left out
On Sat, Jul 14, 2012 at 09:48:49PM -0400, Robert E. Seastrom wrote:
>
> Actually, that's one of the most insightful meta-points I've seen on
> NANOG in a long time.
>
> There is a HUGE difference between IPv4 and IPv6 thinking. We've all
> been living in an austerity regime for so long that we'v
On Jul 15, 2012 9:30 AM, "Scott Morris" wrote:
>
> On 7/15/12 5:38 AM, Grzegorz Janoszka wrote:
> > On 2012-07-15 00:45, Tony Hain wrote:
> >> There is no difference in the local filtering function, but *IF* all
transit
> >> providers put FC00::/7 in bogon space and filter it at every border,
ther
On 7/15/12 5:38 AM, Grzegorz Janoszka wrote:
> On 2012-07-15 00:45, Tony Hain wrote:
>> There is no difference in the local filtering function, but *IF* all transit
>> providers put FC00::/7 in bogon space and filter it at every border, there
>> is a clear benefit when someone fat-fingers the confi
On Jul 15, 2012, at 12:50 AM, Laurent GUERBY wrote:
> Hi,
>
> On Sat, 2012-07-14 at 17:02 -0700, Owen DeLong wrote:
>>> Hi,
>>>
>>> We use LLA to "virtualize" interconnection to our users:
>>> their network configuration is always static default via fe80::
>>> and we route their /56 prefix
On 2012-07-15 00:45, Tony Hain wrote:
> There is no difference in the local filtering function, but *IF* all transit
> providers put FC00::/7 in bogon space and filter it at every border, there
> is a clear benefit when someone fat-fingers the config script and announces
> what should be a locally
1 - 100 of 135 matches
Mail list logo
