Hey!
New message, please read <http://shoppingsignal.com/again.php?0fc3>
Iljitsch van Beijnum
Hey!
New message, please read <http://shoroqpress.com/running.php?b2>
Iljitsch van Beijnum
On 6 mrt. 2014, at 02:18, Joel Maslak jmas...@antelope.net wrote:
I have never heard the term valley free. Where does it come from?
This paper, which is a must-read for anyone interested in BGP:
Stable internet routing without global coordination
By Lixin Gao and Jennifer Rexford
Looking for 32-bit AS numbers, I get some strange results from routeviews:
route-viewssh ip bgp regexp _23456_
BGP table version is 2393809200, local router ID is 128.223.51.103
Status codes: s suppressed, d damped, h history, * valid, best, i - internal,
r RIB-failure, S Stale
On 12 Mar 2012, at 16:21 , Leigh Porter wrote:
Grass-roots, bottom-up policy process
+
Need for multihoming
+
Got tired of waiting
=
IPv6 PI
A perfect summation.
Except that it didn't happen in that order. When ARIN approved PI the shim6
effort was well underway, but it was too early
On 12 Mar 2012, at 21:15 , William Herrin wrote:
Not at all. You just build a second tier to the routing system.
It's so strange how people think a locator/identifier split will solve the
scalability problem. We already have two tiers: DNS names and IP addresses. So
that didn't solve
On 9 Mar 2012, at 10:02 , Jeff Wheeler wrote:
The way we are headed right now, it is likely that the IPv6 address
space being issued today will look like the swamp in a few short
years, and we will regret repeating this obvious mistake.
We had this discussion on the list exactly a year ago.
On 11 Mar 2012, at 20:15 , Joel jaeggli wrote:
The IETF and IRTF have looked at the routing scalability issue for a
long time. The IETF came up with shim6, which allows multihoming
without BGP. Unfortunately, ARIN started to allow IPv6 PI just in
time so nobody bothered to adopt shim6.
On 29 Dec 2011, at 0:16 , Doug Barton wrote:
On 12/28/2011 03:13, Iljitsch van Beijnum wrote:
However, this has two issues. First, with RAs there are no risks that
incorrect default information is propagated because the default
gateway itself broadcasts its presence.
Unless you have
On 29 Dec 2011, at 13:46 , Masataka Ohta wrote:
we must assume MTU of 1280B. But, as IPv6 extension headers can
be as lengthy as 1000B or 2000B, no applications are guaranteed
to work over IPv6.
As IP is an unreliable datagram service, there are no guarantees, period.
The presence of
Just to clear up a few misconceptions:
begin explanation current situation
Router advertisements are exactly what the name suggests, routers advertising
their presence. The first function of router advertisements is to tell hosts
where the routers are, so the hosts can install a
On 24 Dec 2011, at 6:32 , Glen Kent wrote:
I am trying to understand why standards say that using a subnet
prefix length other than a /64 will break many features of IPv6,
including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND)
[RFC3971], .. [reference RFC 5375]
For stateless
On 28 Dec 2011, at 13:26 , Ray Soucy wrote:
Granted that the notion of default router of IPv4 is no better
than that of IPv6.
Please present a reasonable alternative.
Obviously reducing down the entire DFZ to a single default route is a bad case
of premature optimization, which we all know
On 7 Nov 2011, at 17:45 , Deric Kwok wrote:
When I setup the server mtu as 9100. why I have to configure the
switch mtu 9300 to make it working?
What this extra 200 bytes is for what purpose? ls it standard?
To avoid problems you really want to set the MTU of all your IP devices on the
same
On 15 jun 2011, at 16:52, Tony Finch wrote:
Ethernet is not designed for huge LANs. If you want that you need
to make significant changes - http://www.cl.cam.ac.uk/~mas90/MOOSE/
Hm:
Our object is to design a communication system which can grow smoothly to
accommodate several buildings full
On 15 jun 2011, at 18:39, Leo Bicknell wrote:
Maybe I'm missing something, but the last update on this was RFC
5006 I think, which is marked as experimental, and I thought the
IETF still had a working group discussing it.
You missed the upgrade to proposed standard:
On 14 jun 2011, at 10:20, Mikael Abrahamsson wrote:
On the AMSIX peering LAN there is more than 100pps of ND traffic (at least
there was when we checked). Since they do not do IPv6 multicast intelligent
handling (MLD snooping I guess) certain highend (legacy) router platforms run
into
On 15 jun 2011, at 0:05, Owen DeLong wrote:
Yes, the right solution would be to at least separate the VLANs and clean up
this
mess. However, due to software packages that need to talk to each other over
common local broadcast across that boundary, this isn't possible in this
particular
On 15 jun 2011, at 7:33, Owen DeLong wrote:
Bottom line, I expect it's easier to get cooperation from OS vendors and BIOS
vendors to make changes
because experience has shown that they are more willing to do so than
vertical software vendors.
As such, yes, I'd like to see some harmless
On 13 jun 2011, at 19:25, Richard Zheng wrote:
The issue is redistribution from EBGP to OSPF works half way. OSPF database
has the external routes, but forwarding address is set to Router A. So the
routing loop occurs between A and B.
If the link to the customer is of a type that detects
On 11 jun 2011, at 16:39, David Conrad wrote:
There is no point in repeating all the IPv4 mistakes with IPv6, if that's
what you want, stay on IPv4.
As should be apparent by now, the vast majority of people don't want to move
to IPv6. They simply want access to the Internet. ISPs are
On 11 jun 2011, at 17:05, Owen DeLong wrote:
Your doctor doesn't just give you the medicine you ask for either.
You are not talking about a doctor/patient scenario here where the doctor is
an expert and the people asking for this have no
medical training. Here, we are talking about
On 12 jun 2011, at 12:35, Daniel Roesen wrote:
Could you point to any RFC which implies or explicitly states that
DHCPv6 MUST NOT be used in absence of RA with M and/or O=1?
But what's the alternative? Always run DHCPv6 even if there are no router
advertisements or router advertisements with
On 12 jun 2011, at 15:45, Leo Bicknell wrote:
Like I said before, that would pollute the network with many multicasts
which can seriously degrade wifi performance.
Huh? This is no worse than IPv4 where a host comes up and sends a
subnet-broadcast to get DHCP.
The IPv4 host does this once
On 12 jun 2011, at 20:46, Deric Kwok wrote:
1/ Can we use it in our current AS which is using ipv4?
Yes.
2/ Can arin not allow us to apply ipv4 for the future after we apply ipv6?
They're going to do that anyway once they run out, but it's not like you have
v6 so you don't need more v4.
On 11 jun 2011, at 4:03, Owen DeLong wrote:
You can call that bad network design if you want, but, there are real world
requirements and scenarios where that has to happen for a variety of reasons.
Those networks have working configurations in DHCPv4 and no ability to move
to IPv6
until
On 9 jun 2011, at 19:37, Nick Hilliard wrote:
DHCPv6 does not provide route information because this task is handled
by RA in IPv6.
Thankfully this silliness is in the process of being fixed,
So where do I point out the stupidity of trying to fix this non-brokenness?
along with prefix
On 9 jun 2011, at 19:41, Nick Hilliard wrote:
Iljitsch noted: IPv6 routing protocols also pretty much only use link
locals. This is not true in the general case.
So which routing protocols communicate using global addresses then?
As far as I know only BGP but BGP runs over TCP so it's
On 10 jun 2011, at 12:10, sth...@nethelp.no wrote:
So where do I point out the stupidity of trying to fix this non-brokenness?
Several large operators have said, repeatedly, that they want to use
DHCPv6 without RA. I disagree that this is stupid.
It is a mistake to want this, because having
On 10 jun 2011, at 12:20, Nick Hilliard wrote:
[nothing to support his earlier claim]
And it still carries link local next hop
addresses.
it's a bit more subtle than that - it depends on how the underlying router
operating system handles next-hop resolution and how you configure your BGP.
On 10 jun 2011, at 12:27, Iljitsch van Beijnum wrote:
RFC 4760:
An UPDATE message that carries the MP_REACH_NLRI MUST also carry the
ORIGIN and the AS_PATH attributes (both in EBGP and in IBGP
exchanges). Moreover, in IBGP exchanges such a message MUST also
carry the LOCAL_PREF
On 10 jun 2011, at 12:40, Tim Chown wrote:
But it's stupid to want to change DHCPv6 just now the last major OS is about
to start supporting it. That continues the current situation where anyone
who isn't happy with autoconfig-only can't make a configuration that works
will all major OSes.
On 10 jun 2011, at 14:26, Nick Hilliard wrote:
[...]
Of course none of this supports your original claim:
IPv6 routing protocols also pretty much only use link locals. This is not
true in the general case.
On 10 jun 2011, at 15:47, Leo Bicknell wrote:
I've seen the entire NANOG and IETF lans taken out because some
dork enabled microsoft connecting sharing to their cell card.
Ok, so now we've identified the problem.
How exactly does adding default gateway information to DHCPv6 solve this
On 10 jun 2011, at 16:12, Tim Chown wrote:
(And it's insane that Windows still exhibits this completely broken
behavior.)
We could derail into some broken MacOS X behaviour if you like ;)
Not saying that Apple is perfect, but at least their IPv6-related bugs don't
ruin the day for others
On 10 jun 2011, at 16:28, Leo Bicknell wrote:
Ok, so now we've identified the problem.
How exactly does adding default gateway information to DHCPv6 solve this
problem?
Please go back and re-read my original scenario and think about it.
I don't have to, as you restate pretty much all of
On 10 jun 2011, at 16:47, Leo Bicknell wrote:
So we agree on the problem. Now the only thing we have to do is come up with
a solution that everybody likes.
in DHCPv6 it was decided to not implment a field for the
default gateway or subnet mask, under the logic that the former was
learned
On 10 jun 2011, at 17:26, Leo Bicknell wrote:
1. No longer the fait sharing that comes from RA-learned gateway addresses
I proport that VRRPv6 is a superior solution to have redundant
gateways than using RA's to broadcast both and let the host choose.
It's not about redundancy, it's about
On 10 jun 2011, at 18:06, Leo Bicknell wrote:
However, many networks are much more closed deployments. Enterprises
have not deployed IPv6 internally yet. Many will not deploy it for
another 3-5 years, chosing instead to use web proxies at the edge
that speak IPv4 (RFC1918) internally and
On 10 jun 2011, at 23:30, Rhys Rhaven wrote:
And here I thought with IPv6, we would have learned from our mistakes,
fixed those problems. We've had 15 years to think about it. I was
looking forward to a future where ICMPv6 might even be used.
What are you talking about??
ICMPv6 does what
On 9 jun 2011, at 6:36, Karl Auer wrote:
Well, a modern switch should work fine, even if not directly IPv6 aware,
but it won't understand multicast and will generally flood multicast
frames to all interfaces. So definitely stipulate IPv6 capability, even
for switches
Are there any
On 9 jun 2011, at 10:32, Owen DeLong wrote:
You can actually use DHCPv6 to assign addresses to hosts dynamically
on longer than /64 networks.
The trouble is that DHCPv6 can't tell you the prefix length for your address,
so either set up the routers to advertise this prefix (but without the
On 9 jun 2011, at 14:19, sth...@nethelp.no wrote:
It is perfectly possible to use RA *only* for the default router, and
not announce any prefix at all. This implies a link-local next hop.
Router advertisements always use the router's link local address, you can't get
a router's global address
On 9 jun 2011, at 19:34, Ray Soucy wrote:
But you're correct that without MLD snooping IPv6 ND traffic is on par
with IPv4 broadcast traffic and not a major problem. It does mean,
however, that a large IPv6 multicast stream, like video or system
imaging, would be about as bad as doing so on
On 8 jun 2011, at 7:42, Christopher Palmer wrote:
I'm not an ISP - but I absolutely expect that IPv6 roll-outs have long
time-horizons and are fairly complex. So I hope folks are looking at IPv6
NOW, and not simply waiting for Google/Bing/Yahoo/Interwebz to enable
permanent content access
On 8 jun 2011, at 8:15, Andrew Koch wrote:
Speaking of www.nist.gov, I am getting the front page to load, but all
links are returning a 404 Not Found when browsing via v6
Right. They seem to have solved their PMTUD issues, though.
www.juniper.net is on IPv6
www.facebook.com has but doesn't load for me over IPv6, it does for others
though
www.level3.com works fine over v4 but shows a 404 over IPv6
www.simobil.si is temporarily unavailable over IPv6 but works fine over IPv4
On 8 jun 2011, at 2:02, Pete Carah wrote:
www.facebook.com (but not facebook.com) just turned on here too (after
google). another hex-speak spelling...
I'm using my iPhone as the IPv6-only canary. www.facebook.com now seems to
work, but it redirects to m.facebook.com which doesn't have IPv6.
On 8 jun 2011, at 2:31, TJ wrote:
... and Gmail, too ...
imap.gmail.com only has IPv4, though.
On 19 mei 2011, at 5:21, Owen DeLong wrote:
2) Are we tending to use different IPs for each service on a device?
No, the same Internet Protocol.
I believe he meant different IP addresses
No, that can't be, he would have said IP addresses.
and I highly recommend doing so.
If you do so,
On 18 mei 2011, at 16:44, Todd Snyder wrote:
1) Is there a general convention about addresses for DNS servers? NTP
servers? dhcp servers?
There are people who do stuff like blah::53 for DNS, or blah:193:77:81:20 for a
machine that has IPv4 address 193.177.81.20.
For the DNS, I always
On 17 mei 2011, at 17:55, Matthew Kaufman wrote:
firewall traversal
Smells like job security: first install a firewall, then traverse it anyway.
On 16 mei 2011, at 9:31, Owen DeLong wrote:
I believe that the BitTorrent clients
are smart enough to discard the IPv4 nodes reached through NAT64 and will,
instead, just
use the native IPv6 nodes. I don't see this as a problem and Im not sure why
you do.
Because that way the IPv4 and
On 15 mei 2011, at 6:29, Matthew Kaufman wrote:
And that would be the fault of NAT64, which for all of the
applications I mentioned (and more) made the seriously wrong
assumption that every IPv4 address is looked up in a DNS server.
This brings to mind the story of the physicist (but it
On 15 mei 2011, at 20:03, Jima wrote:
BitTorrent tends to be an evolving protocol, with lots of clients
competing for mindshare; I'm not certain that limitation will remain.
Two years ago the Pirate Bay got on IPv6 in a way that was
incompatible with existing clients that were IP version
On 14 mei 2011, at 18:47, Paul Vixie wrote:
folks who want
to run V6 only and still be on the internet will need proxies for
a long
while. folks who want to run V6 only *today* and not have any
proxies *today*
are sort of on their own -- the industry will not cater to market
non-forces.
On 13 mei 2011, at 2:39, Jimmy Hess wrote:
if the user starts obtaining
multiple non-aggregable /48s from different sources, or obtains an
additional PI allocation later, but
keeps using the original /48.
Simple: make a rule that you don't get more than one PI block, and if you want
a
On 13 mei 2011, at 7:52, Karl Auer wrote:
I'm working on a talk, and would be interested to know what people think
is good about tunnels as an IPv6 transition technology, and what people
think is bad about tunnels.
Without tunnels we'd have no IPv6 today. Even today many people, especially
On 13 mei 2011, at 18:42, Matthew Petach wrote:
The current RIR practice to reserve a /44 when a /44 is given out is a very
bad one. It assures unfilterability, because now you have random sizes from
/44 to /48 in the parts of the address space used for PI. And if say, 64k
/48s are given
On 12 mei 2011, at 12:06, Owen DeLong wrote:
IPv6 peering
is somewhat different from IPv4.
How is it different?
On 11 mei 2011, at 2:39, Karl Auer wrote:
On Wed, 2011-05-11 at 10:19 +1000, Mark Andrews wrote:
For the record Apple's current iChat (the OS (10.6.7) is completely
up to date) fails such a test. It will try IPv6 and not fallback
to IPv4. End users shouldn't be seeing these sorts of errors.
On 11 mei 2011, at 16:39, William Astle wrote:
I think the above two points illustrate precisely why so many networks
in North America simply cannot deploy IPv6 whether they want to or not.
We simply cannot obtain IPv6 transit from our upstreams. It's just not
available. And the old line
On 11 mei 2011, at 19:01, George Bonser wrote:
A couple of things you can do to check. First of all look for requests
to your DNS servers for records and note where those are coming
from.
Firefox has for a long time done both A and lookups even if the system
doesn't have IPv6. I
On 11 mei 2011, at 19:32, George Bonser wrote:
If the results of world IPv6 day are as we expect and only 0.1 - 0.2 %
or less of all people have problems, I think the best way forward would
be to have a second world IPv6 day where we again enable IPv6 industry-
wide but this time we don't
On 11 mei 2011, at 20:39, George Bonser wrote:
So what's the alternative? Never change anything?
Of course not. But the best course forward is going to be different for
different folks. What might work best for me might not (probably WILL
not) work best for everyone else. One has to look
On 9 mei 2011, at 21:40, Tony Hain wrote:
Publicly held corporations are responsible to their shareholders to get
eyeballs on their content. *That* is their job, not promoting cool new
network tech. When you have millions of users hitting your site every
day losing 1/2000 is a large chunk of
On 10 mei 2011, at 16:28, Dikkema, Michael (Business Technology) wrote:
Is it foolish to build a L3 ECMP connection between 2 iBGP routers with one
of the links having a 50% longer RTT?
No problem at all as long as you don't do per-packet load balancing but
something that makes sure a single
On 10 mei 2011, at 22:31, Warren Kumari wrote:
:: I applaud the first step, but I'm bothered by the fact that no second
step is planned.
Igor is right on both counts here -- 0.05% is definitely noticeable at these
sorts of scale,
Ok, removed my infamatory reply. But tell me how 0.05% is
On 15 apr 2011, at 12:21, Geoff Huston wrote:
The addresses were in flight to the recipient and got caught up in a set of
scripted processes that inappropriately assigned them into the debogon
project for a couple of days while some related administrative processes were
underway.
Our
On 14 apr 2011, at 8:33, Tore Anderson wrote:
Actually, they're already empty. Chinanet Fujian Province Network
allocated 498432 addresses today, spread out over 1102(!) individual
prefixes in the range /21-/24.
Where do you see this? On ftp.apnic.net I see delegated-apnic-20110414 which
On 14 apr 2011, at 13:50, Tore Anderson wrote:
This is address space that's now marked as delegated and removed from
the pile of unused address space for no obvious reason.
I believe they are using those prefixes for research.
and the delegated-extended file, it appears that these prefixes
On 14 apr 2011, at 13:02, Iljitsch van Beijnum wrote:
Based on that file, APNIC still has 17.57 million regular + 2.27 M legacy =
19.84 M total address space, so another 0.5 M wouldn't deplete what's left.
I just got the 15 apr file which has the info for 14 apr (sigh...) and indeed
1100
On 15 apr 2011, at 0:04, Skeeve Stevens wrote:
All… as of early this morning, APNIC is empty.
Why do you say that? Do you have information that contradicts my numbers?
On 22 feb 2011, at 20:44, goe...@anime.net wrote:
The admin-c, tech-c deny any responsibility for this netblock.
Have you talked to RIPE?
On 17 feb 2011, at 17:35, George Bonser wrote:
Considering v4 is likely to be around for another decade or two, getting
Class E into general use seems easy enough to do.
You really think people will be communicating over the public internet using
IPv4 in 2031?
It will take a long time before
On 17 feb 2011, at 18:57, John Curran wrote:
Actually, as I have noted before, the US DoD has contractually
agreed to return to ARIN unneeded IPv4 address space if/when
such becomes available, so that it may be used by the Internet
community.
How can they return stuff to ARIN that they got
On 18 feb 2011, at 9:24, Zed Usser wrote:
Basic Internet services will work (web browsing, email, Facebook,
Youtube,...), but:
- Less torrenting
- Less Netflix watching
- Less FTP downloads
- Less video streaming in general (webcams, etc.)
You forget:
- no IPv6 tunnels
Deploying NAT444
On 18 feb 2011, at 12:00, Patrick W. Gilmore wrote:
How can they return stuff to ARIN that they got from IANA in the first
place?
ARIN seems to be getting the very long end of the legacy stick.
But last time I checked, the United States is in the ARIN region. And ARIN
did not exist when
On 18 feb 2011, at 12:36, Tore Anderson wrote:
Each of those /8 is
administered by a RIR, but it's unclear (to me at least) whether
that means that RIR gets to give out that space in its region or not.
The unused space in the ERX blocks were divided evenly between the RIRs
a couple of years
On 18 feb 2011, at 12:59, Tore Anderson wrote:
Hit your Page Down button a couple of times, it's included right there
in the PDF.
I don't see anything that clears this up.
On 18 feb 2011, at 14:10, Arturo Servin wrote:
When you talk about unused legacy space are you talking about the
various space or to the legacy space that is currently assigned but the
holders just require part of it?
Legacy space (A) = all the /8s marked as legacy by IANA.
Used
On 11 feb 2011, at 17:51, William Herrin wrote:
We can't backport ULA into IPv4 private
addressing; there aren't enough addresses for the math to work. So we
either make such folks jump through all kinds of hoops to get their
networks to function, or we assign addresses that could otherwise
On 14 feb 2011, at 6:46, Frank Bulk wrote:
Requiring them to be on certain well known addresses is restrictive and
creates an unnecessary digression from IPv4 practice. It's comments like
this that raise the hair on admins' necks. At least mine.
I don't get this. Why spend cycles
On 10 feb 2011, at 0:26, David Freedman wrote:
Unless every packet you emit is ≤ the minimum MTU (1280), then, you need
to be able to receive TOOBIG messages.
Can you think of a packet type I will emit from my publically numbered
backbone interface which may solicit a TOOBIG that I'll have
On 10 feb 2011, at 1:52, Jeff McAdams wrote:
I've always worked in small to middle sized shops, and I have always found
that I've been able to yell and scream about IPv6 (and other features) loud
enough, and long enough that I get heard by someone in a decision making
position for product
On 10 feb 2011, at 22:34, Ryan Rawdon wrote:
What considerations should be made with respect to implementing egress
filtering based on source IPv6 addresses? Things like allowing traffic
sourced from fe80::/10 in said filters for on-link communication (for the
interface that the filter is
On 9 feb 2011, at 5:24, Vikas Sharma wrote:
I am looking for the recommendation for core interfaces IP addressing schema
for Ipv6. Some different views are (PE- P - PE, point to point link) as
below -
Is there a NANOG FAQ we can add this to?
1- Use Public Ipv6 with /122 and do not
On 9 feb 2011, at 10:48, sth...@nethelp.no wrote:
The all zeros address is the all routers anycast address so on most
non-Cisco routers you can't use it, ruling out /127. The top 128 addresses
in any subnet are also reserved anycast addresses although they don't do
much in practice. So the
On 9 feb 2011, at 11:16, sth...@nethelp.no wrote:
If you can get router ICMP handling changed such that the ICMP packet
generated by traceroute is sent from the loopback address, we might
be able to do without global scope addresses on router-to-router
interfaces. But until then...
I'm
On 9 feb 2011, at 18:30, David Freedman wrote:
(yes, even ICMP TOOBIG
can be filtered safely if you have designed things in a sane way)
NO.
Even if you run with 1280-byte MTUs everywhere so you'd think path MTU
discovery wouldn't be needed, this can still cause problems with IPv6-to-IPv4
On 9 feb 2011, at 19:30, Tony Hain wrote:
Making the mass change of enabling the servers at the point you expect
service to work is just asking for support calls...
Do that on june 8 like everyone else. :-)
http://isoc.org/wp/worldipv6day/
On 9 feb 2011, at 20:53, William Herrin wrote:
* Carrier NAT buys us enough years to build an IPv4 successor
You're kidding, right? How long did it take exactly to get where we are now
with IPv6? 18, 19 years? And yet there's still all kinds of stuff that isn't
really ready for prime time
On 9 feb 2011, at 20:21, Scott Helms wrote:
IPv6 for some ISPs will be extraordinarily painful because of legacy layer 2
gear (usually DSLAMs that drop any frame with IPv6 in the EtherType field),
inability to upgrade customer gear efficiently
[...]
For ISPs in this circumstance the
On 9 feb 2011, at 21:17, George Herbert wrote:
Once we're at 128-bit addresses then we can migrate to IPvA (7 - 9 are
already taken) without much trouble.
I know about IPv8 (sigh), and the Chinese abortive IPv9 claim, but
when did 7 happen?
RFC 1475, apparently:
On 9 feb 2011, at 21:23, George Bonser wrote:
While that is true, it is no worse than the situation right now. In the
US, the vast majority of users are already behind a NAT (I would say
over 90% of them are) so they are already experiencing this breakage.
There's a big difference between
On 9 feb 2011, at 21:26, William Herrin wrote:
You're kidding, right? How long did it take exactly to get where
we are now with IPv6? 18, 19 years?
Tech like carrier NAT theoretically yeilds address reclamation in
excess of 80%.
Most IPv4 space is unused anyway, but it's not being reclaimed
On 4 feb 2011, at 22:02, Dave Cardwell wrote:
Without wanting to get into whether NAT provides security to hosts
that exist on the inside. I am curious if the potential to overflow
ND caches with incomplete* entries exists on currently shipping CPE
hardware and if NAT helps prevent this?
On 7 feb 2011, at 17:15, Jay Ashworth wrote:
Ok, I had a hard time making up my mind whether a sarcastic or a
factual response was in order...
I see you decided to go with sarcastic.
Not sure if Owen noticed... :-)
I'm sure it's clear to you that no one's doing it now is not a valid
On 2 feb 2011, at 23:40, Lamar Owen wrote:
I can explain everything you need to know about how to run IPv6 BGP, RIP and
OSPF in an hour and a half. Did that at a RIPE meeting some years ago.
Setting up Apache to use IPv6 is one line of config. BIND two or three (not
counting IPv6 reverse
On 3 feb 2011, at 17:16, Jon Lewis wrote:
When someone breaks or shuts off that filter, traffic through the NAPT
firewall stops working. On the stateful firewall with public IPs on both
sides, everything works...including the traffic you didn't want.
People are going to want NAT66...and
1 - 100 of 176 matches
Mail list logo
