On Jun 25, 2012, at 7:09 AM, Masataka Ohta wrote:
> (2012/06/25 18:00), Tim Franklin wrote:
>>> Even though it may be easy to make end systems and local
>>> LANs v6 capable, rest, the center part, of the Internet
>>> keep causing problems.
>>
>> Really? My impression is that it's very much the
On Jun 25, 2012, at 12:06 AM, Masataka Ohta wrote:
> Justin M. Streiner wrote:
>
>> I see periodic upticks in the growth of the global v6 routing table (a
>> little over 9k prefixes at the moment - the v4 global view is about 415k
>> prefixes right now), which I would reasonably attribute an u
Tim Franklin wrote:
> at least with v6 there's a really good chance that they'll
> only *ever* need to announce a single-prefix.
That's exactly why routing table is exploding today, at least
with v4.
Masataka Ohta
(2012/06/25 18:00), Tim Franklin wrote:
>> Even though it may be easy to make end systems and local
>> LANs v6 capable, rest, the center part, of the Internet
>> keep causing problems.
>
> Really? My impression is that it's very much the edge
> that's hard - CE routers, and in particular cheap,
> The only solution is, IMO, to let multihomed sites have
> multiple prefixes inherited from their upper ISPs, still
> keeping the sites' ability to control loads between incoming
> multiple links.
And for the basement multi-homers, RA / SLAAC makes this much easier to do with
v6. The larger-sca
> Even though it may be easy to make end systems and local
> LANs v6 capable, rest, the center part, of the Internet
> keep causing problems.
Really? My impression is that it's very much the edge that's hard - CE
routers, and in particular cheap, nasty, residential DSL and cable CE routers.
Lo
Justin M. Streiner wrote:
> I see periodic upticks in the growth of the global v6 routing table (a
> little over 9k prefixes at the moment - the v4 global view is about 415k
> prefixes right now), which I would reasonably attribute an upswing in
> networks getting initial assignments.
As I alr
On Fri, 22 Jun 2012, Masataka Ohta wrote:
Unlike IPv4 with natural boundary of /24, routing table
explosion of IPv6 is a serious scalability problem.
I really don't see where you're getting that from. The biggest consumers
of IPv4 space in the US tended to get initial IPv6 blocks from ARIN t
(2012/06/23 10:35), TJ wrote:
> Rate of deployment is more inclusive than just the 'center', that would be
> my guess.
But, the context, as you can see, is this:
:> Even though it may be easy to make end systems and local
:> LANs v6 capable, rest, the center part, of the Internet
:> keep causing
On 06/22/2012 08:35 PM, TJ wrote:
The center part of the internet is the easiest part of
modification for IPv6 and is probably somewhere near 99%
complete at this point.
What do you mean something 99% complete is rapidly accelerating?
Is it a theory for time traveling?
Rate of deployment is mo
> >>> The center part of the internet is the easiest part of
> >>> modification for IPv6 and is probably somewhere near 99%
> >>> complete at this point.
>
> What do you mean something 99% complete is rapidly accelerating?
>
> Is it a theory for time traveling?
Rate of deployment is more inclusive
On Jun 22, 2012, at 6:15 PM, Masataka Ohta wrote:
> Owen DeLong wrote:
>
>>> Even though it may be easy to make end systems and local
>>> LANs v6 capable, rest, the center part, of the Internet
>>> keep causing problems.
>
>> Those problems are getting solved more and more every day.
>>
>> The
Owen DeLong wrote:
>> Even though it may be easy to make end systems and local
>> LANs v6 capable, rest, the center part, of the Internet
>> keep causing problems.
> Those problems are getting solved more and more every day.
>
> The rate of IPv6 deployment is rapidly accelerating at this point.
>
> Even though it may be easy to make end systems and local
> LANs v6 capable, rest, the center part, of the Internet
> keep causing problems.
>
> Masataka Ohta
Those problems are getting solved more and more every day.
The rate of IPv6 deployment
TJ wrote:
>>> The center part of the internet is the easiest part of
>>> modification for IPv6 and is probably somewhere near 99%
>>> complete at this point.
> Am I saying we are all done, and that IPv6 is fully deployed? Of course
> not, lots of work to do in the enterprise and last-mile areas
On Fri, Jun 22, 2012 at 8:46 AM, Masataka Ohta <
mo...@necom830.hpcl.titech.ac.jp> wrote:
> > The center part of the internet is the easiest part of
> > modification for IPv6 and is probably somewhere near 99%
> > complete at this point.
>
> That is a fairy tale once believed by so many infants
Owen DeLong wrote privately to me, but as I think I need
public responses, I'm Ccing to nanog fairly quoting part
of his response:
>> Moreover, it is easy to have a transport protocol with
>> 32bit or 48bit port numbers with the end to end fashion
>> only by modifying end part of the Internet.
>
valdis.kletni...@vt.edu wrote:
>> Unlike IPv4 with natural boundary of /24, routing table
>> explosion of IPv6 is a serious scalability problem.
>
> Do you have any *realistic* and *actual* reason to suspect that the IPv6
> routing table will "explode" any further than the IPv4 has already?
That
Owen DeLong wrote:
>> It is the first step to have the RSIP style transparent Internet.
>>
>> The second step is to use port numbers for routing within ISPs.
>> But, it is not necessary today.
>>
> Still doesn't scale. 40 bits isn't enough to uniquely identify a
> conversation end-point.
It's 48
On Jun 21, 2012, at 5:36 PM, valdis.kletni...@vt.edu wrote:
> On Fri, 22 Jun 2012 08:40:02 +0900, Masataka Ohta said:
>> Owen DeLong wrote:
>
>>> What if my ISP just routes my /48? Seems to work quite well,
>>> actually.
>>
>> Unlike IPv4 with natural boundary of /24, routing table
>> explosion
On Fri, 22 Jun 2012 08:40:02 +0900, Masataka Ohta said:
> Owen DeLong wrote:
> > What if my ISP just routes my /48? Seems to work quite well,
> > actually.
>
> Unlike IPv4 with natural boundary of /24, routing table
> explosion of IPv6 is a serious scalability problem.
Do you have any *realistic*
On Jun 21, 2012, at 4:40 PM, Masataka Ohta wrote:
> Owen DeLong wrote:
>
>> Does not scale. Not enough IPv4 addresses to do that for 6.8
>> billion people on the planet.
>
> It is the first step to have the RSIP style transparent Internet.
>
> The second step is to use port numbers for routing
Owen DeLong wrote:
> Does not scale. Not enough IPv4 addresses to do that for 6.8
> billion people on the planet.
It is the first step to have the RSIP style transparent Internet.
The second step is to use port numbers for routing within ISPs.
But, it is not necessary today.
> What if my ISP ju
On Jun 21, 2012, at 5:04 AM, Masataka Ohta wrote:
> Karl Auer wrote:
>
>> Speaking for myself, I'm one of the "if I want to allow direct outside
>> connection to my interior machines I should be able to" crowd.
>
> While "direct" and "interior" are not compatible that you actually
> mean some i
On Thu, 2012-06-21 at 21:04 +0900, Masataka Ohta wrote:
> Karl Auer wrote:
> > Speaking for myself, I'm one of the "if I want to allow direct
> > outside connection to my interior machines I should be able to"
> > crowd.
>
> While "direct" and "interior" are not compatible that you actually
> mean
Karl Auer wrote:
> Speaking for myself, I'm one of the "if I want to allow direct outside
> connection to my interior machines I should be able to" crowd.
While "direct" and "interior" are not compatible that you actually
mean some indirections...
Anyway, what if, your ISP assigns a globally uni
> On Wed, 2012-06-20 at 19:05 -0400, Jay Ashworth wrote:
> That is, I don't want the architecture of the Internet to be crippled
> by NAT everywhere. If you want to NAT *your* network, go for it.
in this case, an air gap might be encouraged
randy
On Wed, 2012-06-20 at 19:05 -0400, Jay Ashworth wrote:
> Ah, you're on the "I should be required to allow direct outside
> connection to my interior machines if I want to be connected to the
> Internet" crowd.
Speaking for myself, I'm one of the "if I want to allow direct outside
connection to my
On Wed, Jun 20, 2012 at 11:05 PM, Jay Ashworth wrote:
> - Original Message -
>> From: "Dave Hart"
>
>> Sure, there are folks out there who believe NAT gives them benefits.
>> Some are actually sane (small multihomers avoiding BGP). You stand
>> out as insane for attempting to redefine "tr
- Original Message -
> From: "Dave Hart"
> Sure, there are folks out there who believe NAT gives them benefits.
> Some are actually sane (small multihomers avoiding BGP). You stand
> out as insane for attempting to redefine "transparent" to mean
> "inbound communication is possible after
Dave Hart wrote:
> Sure, there are folks out there who believe NAT gives them benefits.
> Some are actually sane (small multihomers avoiding BGP).
They are sane, because there is no proper support for multiple
addresses (as is demonstrated by a host with a v4 and a v6
addresses) nor automatic ren
On Wed, Jun 20, 2012 at 8:44 AM, Masataka Ohta wrote:
> Because we still have enough IPv4 addresses, because most
> users are happy with legacy NAT and because some people
> loves legacy NAT, there is not much commercial motivation.
Sure, there are folks out there who believe NAT gives them benefi
valdis.kletni...@vt.edu wrote:
>> hosts. However, for an ISP operating the NAT gateway, it may be
>> easier to operate independent servers at default port for DNS, SMTP,
>> HTTP and other applications for their customers than operating
>> application relays.
>
> So you're admitti
On Tue, 19 Jun 2012 22:21:11 +0900, Masataka Ohta said:
>Or, a NAT gateway may receive packets to certain ports and behave as
>an application gateway to end hosts, if request messages to the
>server contains information, such as domain names, which is the case
>with DNS, SMTP and H
Karl Auer wrote:
>> host <-> home UPnP NAT <-> Carrier UPnP NAT <-> Internet
>> <-> Carrier UPnP NAT <-> home UPnP NAT <-> host
>
> "Trivially"? I think this looks much nicer:
>
>host <-> Internet <-> host
Yes, if only the Internet were uniform.
However, comp
On Jun 19, 2012, at 8:44 AM, Alexandru Petrescu wrote:
> I think, the length of Interface ID be 64 is so mostly because IEEE
> works now with 64bit EUI identifiers (instead of older 48bit MAC
> addresses). I.e. compatibility between IEEE and IETF IPv6 would be the
> main reason for this Interfac
On Tue, 2012-06-19 at 22:28 +0900, Masataka Ohta wrote:
> It is trivially:
>
> host <-> home UPnP NAT <-> Carrier UPnP NAT <-> Internet
> <-> Carrier UPnP NAT <-> home UPnP NAT <-> host
"Trivially"? I think this looks much nicer:
host <-> Internet <-> host
The way
Le 07/06/2012 22:27, Ricky Beam a écrit :
On Wed, 06 Jun 2012 10:58:05 -0400, Chuck Church
wrote:
Does anyone know the reason /64 was proposed as the size for all L2
domains?
There is one, and only one, reason for the ::/64 split: SLAAC. IPv6
is a classless addressing system. You can make
I think, the length of Interface ID be 64 is so mostly because IEEE
works now with 64bit EUI identifiers (instead of older 48bit MAC
addresses). I.e. compatibility between IEEE and IETF IPv6 would be the
main reason for this Interface ID to be 64.
And this is so, even though there are IEEE links
Owen DeLong wrote:
> Showing that you don't actually understand what everyone else means when
> they say "end-to-end".
Where is your point only to demonstrate that you don't understand
what"end to end" means?
> No carrier is going to implement that for obvious reasons.
>
> Besides, that's not t
valdis.kletni...@vt.edu wrote:
> And you tell the rest of the world that customer A's SMTP port is on
> 125, and B's is on 225, and Z's is up at 2097, how?
How? In draft-ohta-e2e-nat-00.txt, I already wrote:
A server port number different from well known ones may be specified
through mecha
On Wed, 13 Jun 2012 14:47:35 +0900, Masataka Ohta said:
> Dave Hart wrote:
> > is inadequate for carrier NAT due to its model assuming the NAT trusts
> > its clients.
>
> UPnP gateway configured with purely static port mapping needs
> no security.
>
> Assuming shared global address of 131.112.32.1
On Jun 12, 2012, at 10:47 PM, Masataka Ohta wrote:
> Dave Hart wrote:
>
>> It is
>> not transparent when you have to negotiate an inbound path for each
>> service.
>
> I mean, for applications, global address and global port
> numbers are visible.
>
Showing that you don't actually understand
Dave Hart wrote:
> It is
> not transparent when you have to negotiate an inbound path for each
> service.
I mean, for applications, global address and global port
numbers are visible.
> UPnP
> is inadequate for carrier NAT due to its model assuming the NAT trusts
> its clients.
UPnP gateway con
On Wed, Jun 13, 2012 at 4:23 AM, Masataka Ohta wrote:
> I just need a UPnP capable NAT to restore the end to end
> transparency.
You're not restoring transparency, you're restoring communication
after stateful reconfiguration of the network for each service. It is
not transparent when you have to
Owen DeLong wrote:
>> Any multicast capable link is broadcast capable.
>
> BZZT! but thank you for playing.
>
> Many NBMA topologies support multicast.
When you specify a "link" as a small subset of NBMA, it is
broadcast capable, as was demonstrated by history of CLIP.
If you want to have a la
On Jun 12, 2012, at 4:24 PM, Masataka Ohta wrote:
> Tony Hain wrote:
>
>> Note the ~ ... And ARP requires media level broadcast, which ND does not.
>
> Any multicast capable link is broadcast capable.
BZZT! but thank you for playing.
Many NBMA topologies support multicast.
>
>> Not all med
Tony Hain wrote:
> Note the ~ ... And ARP requires media level broadcast, which ND does not.
Any multicast capable link is broadcast capable.
> Not all media support broadcast.
A fundamental misunderstanding of people designed IPv6 is that
they believed ATM not broadcast capable but multicast
Masataka Ohta
> Tony Hain wrote:
>
> >> It is because you avoid to face the reality of MLD.
>
> > MLD != ND
> > MLD == IGMP
>
> OK.
>
> > ND ~= ARP
>
> Wrong, because ND requires MLD while ARP does not.
Note the ~ ... And ARP requires media level broadcast, which ND does not.
Not all media s
Tony Hain wrote:
>> It is because you avoid to face the reality of MLD.
> MLD != ND
> MLD == IGMP
OK.
> ND ~= ARP
Wrong, because ND requires MLD while ARP does not.
> ND is less overhead on end systems than ARP
Today, overhead in time is more serious than that in processor
load.
As ND requi
Masataka Ohta wrote:
> Karl Auer wrote:
>
> >> : I've seen links with up to 15k devices where ARP represented
> >> : a significant part of the link usage, but most weren't (yet) IPv6.
> >>
> >> MLD noise around a router is as bad as ARP/ND noise.
> >
> > Possibly true, but that's another discussio
Karl Auer wrote:
>> : I've seen links with up to 15k devices where ARP represented
>> : a significant part of the link usage, but most weren't (yet) IPv6.
>>
>> MLD noise around a router is as bad as ARP/ND noise.
>
> Possibly true, but that's another discussion.
Then, you could have simply argu
On Tue, 2012-06-12 at 17:16 +0900, Masataka Ohta wrote:
> Er, do you want to say MLD noise is not a problem?
I did not say or imply that MLD noise is (or is not) a problem.
I took issue with the idea that DAD traffic - the specific kind of
traffic mentioned by the original poster - was likely
Karl Auer wrote:
> BTW, I'm assuming here that by "multicast filtering" you mean "switching
> that properly snoops on MLD and sends multicast packets only to the
> correct listeners".
Er, do you want to say MLD noise is not a problem?
> On this point I think you are wrong. Except for router
Karl Auer a écrit sur 07/06/2012 06:09:46 PM :
> On this point I think you are wrong. Except for router advertisements,
> most NDP packets are sent to a solicited node multicast address, and so
> do NOT go to all nodes. It is "the same as broadcast" only in a network
> with switches that do not d
On Fri, 2012-06-08 at 03:08 +, Dave Hart wrote:
> networks. With IPv4, ARP presents not only a network capacity issue,
> but also a host capacity issue as every node expends software
> resources processing every broadcast ARP. With ND, only a tiny
> fraction of hosts expend any software capac
On Fri, Jun 8, 2012 at 12:48 AM, Karl Auer wrote:
> Yes - whether with ARP or ND, any node has to filter out the packets
> that do not apply to it (whether it's done by the NIC or the host CPU is
> another question, not relevant here).
It is relevant to the question of the scalability of large L2
On Fri, 2012-06-08 at 11:08 +1000, Mark Andrews wrote:
> > This is pretty much the *point* of using multicast instead of
> broadcast.
>
> The point of multicast is be able to reject traffic sooner rather
> than later.
Well - yes - and my description was of how, when properly configured and
on the
In message <1339116492.2754.162.camel@karl>, Karl Auer writes:
>
> --=-ebOzahzuucm9tstf70zM
> Content-Type: text/plain; charset="UTF-8"
> Content-Transfer-Encoding: quoted-printable
>
> On Thu, 2012-06-07 at 22:27 +, Dave Hart wrote:
> > Karl, you seem to fail to understand how ethernet NICs
On Thu, 2012-06-07 at 22:27 +, Dave Hart wrote:
> Karl, you seem to fail to understand how ethernet NICs are implemented
> in the real world. Ignoring the optional (but common) promiscuous
> mode support and various offloading, IPv4 ARP is sent as ethernet
> broadcast and the NIC hardware and
On Thu, Jun 7, 2012 at 10:14 PM, Karl Auer wrote:
> On Thu, 2012-06-07 at 21:07 +, Dave Hart wrote:
>> Bzzt. With ARP, every IPv4 node on the link indicates each ARP packet
>> to the OS. With ND, only those nodes sharing the same last 24 bits of
>> the IPv6 address indicate the packet up the
On Thu, 2012-06-07 at 21:07 +, Dave Hart wrote:
> Bzzt. With ARP, every IPv4 node on the link indicates each ARP packet
> to the OS. With ND, only those nodes sharing the same last 24 bits of
> the IPv6 address indicate the packet up the stack. The rest of the
> IPv6 nodes filter the multica
On Thu, 2012-06-07 at 16:42 -0400, Ricky Beam wrote:
> On Wed, 06 Jun 2012 17:17:37 -0400, Karl Auer wrote:
> > a) DAD only happens when an IPv6 node is starting up. ARP happens
> > whenever a node needs to talk to another node that it hasn't seen in
> > while.
>
> DAD is a special case of ND. It
On Jun 7, 2012, at 1:27 PM, Ricky Beam wrote:
> On Wed, 06 Jun 2012 10:58:05 -0400, Chuck Church
> wrote:
>> Does anyone know the reason /64 was proposed as the size for all L2 domains?
>
> There is one, and only one, reason for the ::/64 split: SLAAC. IPv6 is a
> classless addressing system
On Thu, Jun 7, 2012 at 8:42 PM, Ricky Beam wrote:
> On Wed, 06 Jun 2012 17:17:37 -0400, Karl Auer wrote:
>>
>> c) Similarly, ND (the direct equivalent of ARP) goes only to solicited
>> node multicast addresses, ARP goes to every node on the link.
>
> Effectively the same as broadcast in the IPv6
On Wed, 06 Jun 2012 17:17:37 -0400, Karl Auer wrote:
a) DAD only happens when an IPv6 node is starting up. ARP happens
whenever a node needs to talk to another node that it hasn't seen in
while.
DAD is a special case of ND. It happens every time the system selects an
address. (i.e. startup
On Wed, 06 Jun 2012 10:58:05 -0400, Chuck Church
wrote:
Does anyone know the reason /64 was proposed as the size for all L2
domains?
There is one, and only one, reason for the ::/64 split: SLAAC. IPv6 is a
classless addressing system. You can make your LAN ::/117 if you want to;
SLAAC
On Wed, 2012-06-06 at 10:35 -0400,
jean-francois.tremblay...@videotron.com wrote:
> The ND noise generated is arguably higher than ARP because of DAD,
> but I don't remember seeing actual numbers on this (anybody?).
> I've seen links with up to 15k devices where ARP represented
> a significant p
Owen DeLong wrote:
> It is because of IEEE EUI-64 standard.
Right, so far.
> It was believed at the time of IPv6 development that EUI-48 would run out of
> numbers and IEEE had proposed going to EUI-64. While IEEE still hasn't
> quite made that change (though Firewire does appear to use EUI-64 a
On Jun 6, 2012, at 1:02 PM, Steve Clark wrote:
> On 06/06/2012 03:05 PM, Owen DeLong wrote:
>>
>> It is because of IEEE EUI-64 standard.
>>
>> It was believed at the time of IPv6 development that EUI-48 would run out of
>> numbers and IEEE had proposed going to EUI-64. While IEEE still hasn't
>
On 06/06/2012 03:05 PM, Owen DeLong wrote:
It is because of IEEE EUI-64 standard.
It was believed at the time of IPv6 development that EUI-48 would run out of
numbers and IEEE had proposed going to EUI-64. While IEEE still hasn't
quite made that change (though Firewire does appear to use EUI-64
It is because of IEEE EUI-64 standard.
It was believed at the time of IPv6 development that EUI-48 would run out of
numbers and IEEE had proposed going to EUI-64. While IEEE still hasn't
quite made that change (though Firewire does appear to use EUI-64 already),
it will likely occur prior to the E
Thus spake Chuck Church (chuckchu...@gmail.com) on Wed, Jun 06, 2012 at
10:58:05AM -0400:
> Does anyone know the reason /64 was proposed as the size for all L2 domains?
Some day eui-48 will "run out". So, just assume eui-64 now and map into it.
Also, as you point out below, not all L2 is ethern
Does anyone know the reason /64 was proposed as the size for all L2 domains?
I've looked for this answer before, never found a good one. I thought I
read there are some L2 technologies that use a 64 bit hardware address,
might have been Bluetooth. Guaranteeing that ALL possible hosts could live
t
74 matches
Mail list logo
