Toerless Eckert wrote:
Not sure why rfc1981 PMTUD was never fixed.
Because IPv6 people believe multicast PMTUD MUST work.
RFC1981 even states:
The local
representation of the path to a multicast destination must in fact
represent a potentially large set of paths.
that they actively
Not sure why rfc1981 PMTUD was never fixed. I've repeatedly tried to
suggest to just forget about PMTUD for IP multicast, and i have never
come across a good use case to justify MTU 1280 for IP multicast
across the Internet.
We did manage to get section 11.1 into rfc 3542 though. It's a little
Hi Mark,
Adding a address range as non-public to existing equipment is a lot
easier than adding IPv6 so that you can use DS-Lite. Much CPE
equipment doesn't have the flash capacity to do the later. The former
is trival provide the company that supplied the fireware is still in
business.
On 12/5/11 7:47 PM, Doug Barton do...@dougbarton.us wrote:
On 12/04/2011 19:10, Chris Donley wrote:
More seriously, the impression I've gathered from various discussions
is that the 90/10 model is viable, but it's not the first choice
because the 10 part involves customer service work that
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Doug Barton
Thank you for confirming publicly that the issue here is not a
technical
one, but rather that the ISPs would prefer not to bear the costs of
dealing with the problem that they
Subject: Re: Consensus Call: draft-weil-shared-transition-space-request Date:
Mon, Dec 05, 2011 at 12:28:56AM -0500 Quoting John C Klensin
(john-i...@jck.com):
(John, this is more of a general rant than a reply directly
to you. Please accept apologies for the kidnapping
--On Monday, December 05, 2011 09:59 +0100 Måns Nilsson
mansa...@besserwisser.org wrote:
Subject: Re: Consensus Call:
draft-weil-shared-transition-space-request Date: Mon, Dec 05,
2011 at 12:28:56AM -0500 Quoting John C Klensin
(john-i...@jck.com):
(John, this is more of a general
On 12/4/11 9:04 AM, Hadriel Kaplan wrote:
For RFC 1918 space, the problem with picking it isn't so much that the ISP
can't pick one that consumer NATs don't use - it's that they can't pick one
that no Enterprise on a*different* ISP uses. For example, assume my employer
used 10.64.0.0/10
On 12/5/11 07:51 , Pete Resnick wrote:
On 12/4/11 9:04 AM, Hadriel Kaplan wrote:
For RFC 1918 space, the problem with picking it isn't so much that the ISP
can't pick one that consumer NATs don't use - it's that they can't pick one
that no Enterprise on a *different* ISP uses. For example,
On Mon, 5 Dec 2011, Randy Bush wrote:
The assumption in my question is that if the legacy (broken?) gear in
question all uses 10/8 *and* we publish a document that declares a
particular (presently unused by said gear) block of 1918 address space
is henceforth off limits to use in equipment
On Dec 4, 2011 10:40 AM, Joel jaeggli joe...@bogus.com wrote:
10.170.127.192/27 link#12UCS 20 en3
10.170.127.193 4c:47:45:56:44:58 UHLWIi422 34 en3
1197
10.170.127.207 127.0.0.1 UHS 00 lo0
And
On 12/5/11 08:37 , C. M. Heard wrote:
On Mon, 5 Dec 2011, Randy Bush wrote:
The assumption in my question is that if the legacy (broken?) gear in
question all uses 10/8 *and* we publish a document that declares a
particular (presently unused by said gear) block of 1918 address space
is
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Cameron
Byrne
The ietf did act. It is called ipv6.
[WEG] sarcasm thanks for that wonderfully relevant and technical rebuttal.
I'm so glad we've stopped debating philosophy and religion in this thread and
gotten down to
From: George, Wes wesley.geo...@twcable.com
sarcasm thanks for that wonderfully relevant and technical rebuttal.
Err, Ron asked us to stay off this (non-productive) point:
From: Ronald Bonica rbon...@juniper.net
Date: Sat, 3 Dec 2011 17:06:42 -0500
By contrast,
Wes,
On Dec 5, 2011, at 10:02 AM, George, Wes wrote:
Independent of whether we have any left, continued support for IPv4 in the
home and enterprise is *non-negotiable*,
True, however as I understand it, this isn't the issue. IIUC, the problem
isn't what happens in the home and enterprise,
Pete == Pete Resnick presn...@qualcomm.com writes:
For RFC 1918 space, the problem with picking it isn't so much
that the ISP can't pick one that consumer NATs don't use - it's
that they can't pick one that no Enterprise on a*different* ISP
uses. For example, assume my
On Mon, Dec 05, 2011 at 04:02:07PM -0500, Michael Richardson wrote:
Even when it is solved, it's still a horrible hack.
At last! The slogan for this discussion!
A
--
Andrew Sullivan
a...@anvilwalrusden.com
___
Ietf mailing list
Ietf@ietf.org
In message 3e7ae2ad-18e0-4ea0-bf76-704cd49ec...@virtualized.org, David Conrad
writes:
Wes,
On Dec 5, 2011, at 10:02 AM, George, Wes wrote:
Independent of whether we have any left, continued support for IPv4 in the
home and enterprise is *non-negotiable*,
True, however as I understand
On 12/05/2011 10:02, George, Wes wrote:
I don't know how much clearer I can make this, so I'll keep repeating it
until it hopefully sinks in:
Independent of whether we have any left, continued support for IPv4 in the
home and enterprise is *non-negotiable*
In case it isn't clear, and in
On 12/04/2011 19:10, Chris Donley wrote:
More seriously, the impression I've gathered from various discussions
is that the 90/10 model is viable, but it's not the first choice
because the 10 part involves customer service work that those
interested in deploying CGN would like to avoid in
I am not sure why 10.64.0.0/10 is being discussed instead of 10.128/10 or
10.192/10... but let's assume we picked 10.192.0.0/10 instead. I'm sitting at
home and my laptop currently has this interface:
inet 10.2XX.XXX.XXX netmask 0xff00 broadcast 10.2XX.XXX.XXX
[specific digits
I have a question to the authors and ISPs as well, which may help explain why
using RFC 1918 and Class-E address space can't be done; or it may not if the
answer is different.
The question: could this new address space be used *without* a NATing CPE being
provided by the ISP? In other words,
Hadreil,
I will try and summarize the information in response to your query as best
as possible. I have left your your text below (for future readers), and
will discuss address assignment behaviours in both Mobile (3GPP) and
Wireline (Cable). I will let someone discuss DSL (which will have
From: Mark Andrews ma...@isc.org
The CGN boxes are new. The customer boxes which are being allocated the
addresses are old. Lots of these boxes will not work with a 240/4
address.
Here's a question, though: would a mix of a smaller block of 'classic' IPv4
space, _along with_
Noel,
On 11-12-04 10:55 AM, Noel Chiappa j...@mercury.lcs.mit.edu wrote:
I ask because I gather there are a lot of situations where e.g. a cable
modem
has an ISP-local address on its ISP-facing side, and a global IP address
(which the customer gets) on the customer side. (I see this in checking
Hi Victor,
Yes that helps, thanks - it confirms what I had always assumed was the case but
could not grok from the discussions on this list nor the draft.
Because the new address space is actually seen/used by the consumer's
interface, we cannot possibly pick a safe RFC 1918 address nor
On 12/4/11 08:48 , Hadriel Kaplan wrote:
Hi Victor, Yes that helps, thanks - it confirms what I had always
assumed was the case but could not grok from the discussions on this
list nor the draft.
Because the new address space is actually seen/used by the consumer's
interface, we cannot
On Dec 4, 2011 10:40 AM, Joel jaeggli joe...@bogus.com wrote:
On 12/4/11 08:48 , Hadriel Kaplan wrote:
Hi Victor, Yes that helps, thanks - it confirms what I had always
assumed was the case but could not grok from the discussions on this
list nor the draft.
Because the new address
Joel
It's an absurdity that the clearly impossible is in fact the defacto
deployment model.
This is the case for this specific Wireless provider and the particular
APN you are connected to. The sum of all Wireless providers do not use
RFC1918 (some do, and some do not, and some use both
Yes, I know that mobile networks have started going that way - which is why I
asked the question. The reason we (the IETF) cannot possibly pick the same
RFC1918 address space is because those mobile networks now have the problem I
described: when you try to run your VPN client on that laptop,
On 12/4/11 11:06 , Hadriel Kaplan wrote:
Yes, I know that mobile networks have started going that way - which
is why I asked the question.
It's not a question of starting. outside of some small number of
developed economies mobile carriers and a number of wireline providers
were always
On Dec 4, 2011 11:06 AM, Hadriel Kaplan hkap...@acmepacket.com wrote:
Yes, I know that mobile networks have started going that way - which is
why I asked the question. The reason we (the IETF) cannot possibly pick
the same RFC1918 address space is because those mobile networks now have
the
On Dec 4, 2011, at 2:26 PM, Joel jaeggli wrote:
It's not a question of starting. outside of some small number of
developed economies mobile carriers and a number of wireline providers
were always depolyed that way, or out of squat space however bad an idea
that may have been.
OK, yeah
On 12/3/2011 6:41 PM, David Conrad wrote:
On Dec 3, 2011, at 5:18 PM, Doug Barton wrote:
We cannot use 1918 for CGN because some customers use it
internally, and they have CPEs that break if the same block is used
on both sides. Therefore, we need a new, !1918 block for our side
of the CGN.
Doug,
On Dec 4, 2011, at 1:13 PM, Doug Barton wrote:
a) use normal space b) use somebody else's space c) redeploy stuff
d) Use 1918 space other than 192.168.[01]/24 for 90% of customers, deal
with one-offs for the rest.
I am making the assumption that the folks who have proposed draft-weil
On 12/4/2011 1:51 PM, David Conrad wrote:
Doug,
On Dec 4, 2011, at 1:13 PM, Doug Barton wrote:
a) use normal space b) use somebody else's space c) redeploy stuff
d) Use 1918 space other than 192.168.[01]/24 for 90% of customers, deal
with one-offs for the rest.
I am making the
In message 20111204155527.be11218c...@mercury.lcs.mit.edu, Noel Chiappa write
s:
From: Mark Andrews ma...@isc.org
The CGN boxes are new. The customer boxes which are being allocated the
addresses are old. Lots of these boxes will not work with a 240/4
address.
Here's
On 12/4/11 8:22 AM, Hadriel Kaplan wrote:
So you tell me how safe picking a specific RFC 1918 address space is. There are ~100,000
enterprises with over 100 employees just in the US, and ~20,000 with over 500 employees
in the US. Obviously my company is a tech company so it's probably not
On 12/2/11 12:06 PM, Ted Hardie wrote:
I think there is an unstated premise in Pete's question that the set
of customers behind that legacy gear has a stable usage pattern of
private addresses. That is, if the current set of customers behind
that legacy gear uses 10/8 then use of any other
I've seen many enterprise customers using RFC 1918 address space internally.
This includes allocating 10/8 addresses for hosts, and 172.16/12 for isolated
segments behind firewalls. Since 192.168/16 may be used by employees in their
homes accessing the corpnet, often this block is avoided for
More seriously, the impression I've gathered from various discussions is
that the 90/10 model is viable, but it's not the first choice because
the 10 part involves customer service work that those interested in
deploying CGN would like to avoid in order to protect their margins. I'm
not
On Dec 4, 2011 7:10 PM, Chris Donley c.don...@cablelabs.com wrote:
More seriously, the impression I've gathered from various discussions is
that the 90/10 model is viable, but it's not the first choice because
the 10 part involves customer service work that those interested in
deploying CGN
On Dec 4, 2011 7:24 PM, Cameron Byrne cb.li...@gmail.com wrote:
On Dec 4, 2011 7:10 PM, Chris Donley c.don...@cablelabs.com wrote:
More seriously, the impression I've gathered from various discussions is
that the 90/10 model is viable, but it's not the first choice because
the 10 part
The assumption in my question is that if the legacy (broken?) gear in
question all uses 10/8 *and* we publish a document that declares a
particular (presently unused by said gear) block of 1918 address space
is henceforth off limits to use in equipment that can't translate when
addresses are
--On Sunday, December 04, 2011 20:40 -0600 Pete Resnick
presn...@qualcomm.com wrote:
...
Nope, but your close. The assumption in my question is that if
the legacy (broken?) gear in question all uses 10/8 *and* we
publish a document that declares a particular (presently
unused by said gear)
Daryl Tanner wrote:
The IPv6 chickens and eggs discussion could (and probably will) go on
forever:
service provider - no content
IPv6 is the right answer,
Wrong.
IPv6 is not operational, which is partly why most service
providers refuse it.
For example, to purposelessly enable
Mark Andrews wrote:
224/10 could be made to work with new equipement provided there was
also signaling that the equipment supported it. That doesn't help
ISP that have new customers with old equipment and no addresses.
Yes, it takes time.
However, 224/4 (or most of it) and 240/4 (except for
On 11-12-03 7:25 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp
wrote:
Mark Andrews wrote:
224/10 could be made to work with new equipement provided there was
also signaling that the equipment supported it. That doesn't help
ISP that have new customers with old equipment and no
Ralph:
Is there evidence that there are deployments today of devices that use
addresses in 10.64.0.0/10?
I have seen addresses in this space used.
Russ
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
On 12/2/2011 8:50 PM, Ross Callon wrote:
If a customer uses a CGN-specific allocation on the inside of
their network as if it were RFC 1918 space, then, yes, they will
have trouble if they ever use a provider that uses a CGN.
Thanks. So my point is, this proposed allocation doesn't solve
From: Doug Barton do...@dougbarton.us
Doing the allocation will postpone the pain, until such time as those
folks that we keep hearing have exhausted all of 1918 internally catch
on, and then start using this block as 1918 space.
But if any particular site uses this space for
Victor Kuarsingh wrote:
However, 224/4 (or most of it) and 240/4 (except for 255.255.255.255)
should be released for unicast uses to reduce market price on
IPv4 addresses.
I have not objection to this. But anything that requires replacement of
equipment only will have longer term benefit.
On 12/3/2011 4:49 PM, Noel Chiappa wrote:
From: Doug Barton do...@dougbarton.us
Doing the allocation will postpone the pain, until such time as those
folks that we keep hearing have exhausted all of 1918 internally catch
on, and then start using this block as 1918 space.
From: Doug Barton do...@dougbarton.us
there is nothing to stop customers from using the new block internally
...
because the pain of dealing with customers who are using your CGN block
internally is going to exist anyway, why not just use the least popular
1918
On 12/3/2011 5:26 PM, Noel Chiappa wrote:
From: Doug Barton do...@dougbarton.us
there is nothing to stop customers from using the new block internally
...
because the pain of dealing with customers who are using your CGN block
internally is going to exist anyway,
From: Doug Barton do...@dougbarton.us
This argument has been raised before, but IMO the value is exactly
zero. The fact that you have a finger to wag at someone doesn't make
the costs of dealing with the conflict any smaller.
Perhaps. But I don't know the ISPs' business as
Almost all residential customers will use a standard home router; as long as
that home router does not make the new space available to customers, it will
not be used. Almost all residential users get their home NAT box either from
the ISP (who obviously won't ship such a box) or from one of a
On 12/3/2011 5:54 PM, Henning Schulzrinne wrote:
Almost all residential customers will use a standard home router; as
long as that home router does not make the new space available to
customers, it will not be used. Almost all residential users get
their home NAT box either from the ISP (who
The same thought occurred to me. A very large enterprise will not utilize this
/10 on a whim; they'd talk to their ISP first. A consumer is unlikely to
modify the settings of their home router, except if they download malware that
does it for them :) and a consumer router vendor has such a
On Dec 3, 2011, at 5:18 PM, Doug Barton wrote:
We cannot use 1918 for CGN because some customers use it internally,
and they have CPEs that break if the same block is used on both sides.
Therefore, we need a new, !1918 block for our side of the CGN.
The problem with that argument is that
I think this is indeed all about economics. Role acting ISP for a minute: From
a consumer ISP perspective asked to weigh in here, there are two options beyond
the ones mentioned below:
(1) They can support the new /10, which doesn't cost them anything and reduces
the chance that existing NAT
Noel,
Opinion from an operator. There is a difference, and the reality is that
the space is unlikely to be used by enterprises and consumers.
Here is the difference. RFC1918 has been out (defined) for a long time,
so it's well know by operators, enterprise folks and some consumers.
There is a
I've followed the discussion, both on the OPSAWG list and on the
IETF list, and I have to say that I agree with the comments below by
Henning Schulzrinne and Bernard Aboba.
One question, though, that I wish to address to the authors of
draft-weil-shared-transition-space-request and perhaps
CM
One question, though, that I wish to address to the authors of
draft-weil-shared-transition-space-request and perhaps others: why
would not an allocation from 240/4 (the former Class E address
space) work for CGN space? I'm well aware that it would be very
difficult to use this as ordinary
In message pine.lnx.4.64.1112032019010.23...@shell4.bayarea.net, C. M. Heard
writes:
I've followed the discussion, both on the OPSAWG list and on the
IETF list, and I have to say that I agree with the comments below by
Henning Schulzrinne and Bernard Aboba.
One question, though, that I
Date:Thu, 01 Dec 2011 23:08:51 -0800
From:Doug Barton do...@dougbarton.us
Message-ID: 4ed87983.4090...@dougbarton.us
| Step 3: If your customer has somehow chosen the same prefix, tell them
| they can't do that.
Another alternative there is for the ISP to simply
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Doug Barton
Step 1: Determine the most popular inside prefixes for CPEs
Step 2: Use the least popular RFC 1918 prefix for the CGN network
Step 3: If your customer has somehow chosen the
Subject: RE: Consensus Call: draft-weil-shared-transition-space-request Date:
Fri, Dec 02, 2011 at 09:15:16AM -0500 Quoting Lee Howard (l...@asgard.org):
Which problem did ISPs create?
By dragging their feet to the inevitable roll-out of v6 they checked
the demand for consumer electronics
And yes, I realize that Step 3 is going to be incredibly unpopular for
the ISPs, but they created the problem, so they should have to live with
the results.
Which problem did ISPs create?
big broadband providers sitting on thumbs for a decade instead of
looking their (mostly edge) vendors in
solution.
A dedicated, shared prefix (not from 1918) is the lowest risk for address
conflicts, and easiest to manage and control.
Daryl
On 2 December 2011 16:03, Måns Nilsson mansa...@besserwisser.org wrote:
Subject: RE: Consensus Call: draft-weil-shared-transition-space-request
Date: Fri, Dec 02
On Thu, Dec 1, 2011 at 11:08 PM, Doug Barton do...@dougbarton.us wrote:
On 12/01/2011 22:07, Ted Hardie wrote:
No, I think that premise is mis-stated. Premise 1: There exists
equipment that can't handle identical addresses on the interior and
exterior interface. Premise 2: it may be
Which problem did ISPs create?
By dragging their feet to the inevitable roll-out of v6 they checked
the demand for consumer electronics compatible with v6. If v6 connectivity
had been norm 6 years ago we'd have more v6-ready devices deployed today.
The problem is three part: Connectivity /
On Thu, Dec 1, 2011 at 11:44 PM, John C Klensin john-i...@jck.com wrote:
Assume that no vendor in its collective right mind would deploy
new address translation gear (or firmware) that couldn't cope
with having addresses from the same pool on the inside and
outside and that we are willing to
Ted, your response does not address what I said at all. Not
one bit. Let's assume that *every* enterprise used every
last address of 172.16/12 (and, for that matter ever bit of
1918 space). That's irrelevant and still does not address my
question. The question is whether
On 12/2/11 09:59 , Michael Richardson wrote:
Ted, your response does not address what I said at all. Not
one bit. Let's assume that *every* enterprise used every
last address of 172.16/12 (and, for that matter ever bit of
1918 space). That's irrelevant and still does not
--On Friday, December 02, 2011 10:06 -0800 Ted Hardie
ted.i...@gmail.com wrote:
...
In that context, questions like Pete's make perfect sense
because they are questions about how to patch around said
legacy gear while causing minimum damage to today's
assumptions about, e.g., routable and
On Nov 28, 2011, at 13:25 , Ronald Bonica wrote:
[…] I will submit the draft to the full IESG for its consideration at its
December 1 teleconference. The draft will be published as a BCP if a
sufficient number of IESG members ballot Yes or No Objection, and if no
IESG member ballots
Subject: Re: Consensus Call: draft-weil-shared-transition-space-request Date:
Fri, Dec 02, 2011 at 04:56:55PM + Quoting Daryl Tanner
(daryl.tan...@blueyonder.co.uk):
I don't like CGN, but the reality is that we're stuck with it. On this
basis, it's a case of looking for the least
On 2 dec 2011, at 21:38, Måns Nilsson wrote:
Subject: Re: Consensus Call: draft-weil-shared-transition-space-request Date:
Fri, Dec 02, 2011 at 04:56:55PM + Quoting Daryl Tanner
(daryl.tan...@blueyonder.co.uk):
I don't like CGN, but the reality is that we're stuck
From: Nilsson mansa...@besserwisser.org
On this basis, it's a case of looking for the least-problematic
solution.
Which is v6.
Yes, beating up on IPv4 has been such a success in getting IPv6 deployed,
hasn't it?
Let's dial the way-back machine back to 1994, when IPv6 was
James,
In simpler terms, what I want is a document that clearly implies 6to4-PMT
is not applicable with this new Shared CGN Address Space. No, I am not
joking, and I'm very sorry that I had to bring up the topic of 6to4 again.
I appreciate your position. I am also biased as much as you
Subject: Re: Consensus Call: draft-weil-shared-transition-space-request Date:
Fri, Dec 02, 2011 at 04:07:47PM -0500 Quoting Noel Chiappa
(j...@mercury.lcs.mit.edu):
Which is v6.
Yes, beating up on IPv4 has been such a success in getting IPv6 deployed,
hasn't it?
There is no beating
On Dec 2, 2011, at 1:51 PM, Joel jaeggli wrote:
On 12/2/11 09:59 , Michael Richardson wrote:
Ted, your response does not address what I said at all. Not
one bit. Let's assume that *every* enterprise used every
last address of 172.16/12 (and, for that matter ever bit of
1918 space). That's
From: Nilsson mansa...@besserwisser.org
There is no beating up. v4 is dead, move on.
If you're sure v4 is really dead, why do you care if other people want to
re-arrange a few limbs?
Noel
___
Ietf mailing list
Ietf@ietf.org
On 12/2/11 13:31 , Warren Kumari wrote:
On Dec 2, 2011, at 1:51 PM, Joel jaeggli wrote:
On 12/2/11 09:59 , Michael Richardson wrote:
Ted, your response does not address what I said at all. Not
one bit. Let's assume that *every* enterprise used every
last address of 172.16/12 (and, for
Subject: Re: Consensus Call: draft-weil-shared-transition-space-request Date:
Fri, Dec 02, 2011 at 04:31:56PM -0500 Quoting Noel Chiappa
(j...@mercury.lcs.mit.edu):
From: Nilsson mansa...@besserwisser.org
There is no beating up. v4 is dead, move on.
If you're sure v4 is really
On 12/02/2011 09:50, Ted Hardie wrote:
On Thu, Dec 1, 2011 at 11:08 PM, Doug Barton do...@dougbarton.us
mailto:do...@dougbarton.us wrote:
On 12/01/2011 22:07, Ted Hardie wrote:
No, I think that premise is mis-stated. Premise 1: There exists
equipment that can't handle
On Fri, Dec 2, 2011 at 1:31 PM, Warren Kumari war...@kumari.net wrote:
But (also realistically) a sufficiently large enterprise that uses all
of RFC1918 is not going to be sitting behind a CGN...
W
Big enterprises buy small ones; sometimes at a great rate. Imagine an
enterprise that uses
On Dec 2, 2011, at 13:15 , Victor Kuarsingh wrote:
[…] I would like to point out that PMT has worked in a large production
network with much success (as ugly as one may think it is). The reality is
that it works, and works well […]
In order to retain a semblance of professional composure,
In message 30683.1322848...@marajade.sandelman.ca, Michael Richardson writes:
Ted, your response does not address what I said at all. Not
one bit. Let's assume that *every* enterprise used every
last address of 172.16/12 (and, for that matter ever bit of
1918 space).
Date:Fri, 2 Dec 2011 15:20:34 -0800
From:Ted Hardie ted.i...@gmail.com
Message-ID:
ca+9kkmajnup60nczwctokzstctk1lrdvrfqjzmbzpfbgoo5...@mail.gmail.com
| Big enterprises buy small ones; sometimes at a great rate.
And this itself is a good argument that 1918 space is
If a customer uses a CGN-specific allocation on the inside of their
network as if it were RFC 1918 space, then, yes, they will have trouble
if they ever use a provider that uses a CGN.
Thanks. So my point is, this proposed allocation doesn't solve anything,
it just kicks the can down the
Randy,
On 11/30/11 6:09 AM, Randy Bush wrote:
skype etc. will learn. This does prevent the breakage it just makes
it more controlled. What's the bet Skype has a patched released
within a week of this being made available?
cool. then, by that logic, let's use 240/4. the apps will patch
On Dec 1, 2011, at 3:35 AM 12/1/11, Eliot Lear wrote:
Randy,
On 11/30/11 6:09 AM, Randy Bush wrote:
skype etc. will learn. This does prevent the breakage it just makes
it more controlled. What's the bet Skype has a patched released
within a week of this being made available?
cool.
Ralph,
Where we ran into trouble the last time on this was that the OSS systems
themselves that manage the edge devices needed to be able to actually
communicate with those devices using the reserved space (reachability
testing, what-have-you). All that stuff runs on a variety of h/w,
including
On Dec 1, 2011, at 8:10 AM 12/1/11, Eliot Lear wrote:
Ralph,
Where we ran into trouble the last time on this was that the OSS systems
themselves that manage the edge devices needed to be able to actually
communicate with those devices using the reserved space (reachability
testing,
Ralph,
I'm not sure what would take longer - getting new subscriber gws
supporting 240/4 or IPv6 into the field, and I know which one I'd prefer
vendor engineers to be working on ;-).
Chris
On 12/1/11 6:06 AM, Ralph Droms rdroms.i...@gmail.com wrote:
Those subscriber GWs would have to
On 29 Nov 2011, at 18:54, Ronald Bonica wrote:
I think that our time would be used much more productively if we discussed
whether to make the allocation or not. The proposed status of the document is
a secondary issue.
yes, it is, and yes, we should.
I've slept on it, but it's no good.
I will add one more concern with this allocation.
IPv4 address allocation is a market (supply exceeds demand in this
case), and thus a strategic game (like chess) to gather limited
resources .
We have known for a long time how IPv4 was not an acceptable long term solution.
We have known for a
From: Sabahattin Gucukoglu m...@sabahattin-gucukoglu.com
IPv4 is now practically dead.
The logic here doesn't seem to follow. If it's basically dead, why do you
care how the remaining address space is allocated?
From: Cameron Byrne cb.li...@gmail.com
I do not believe this
1 - 100 of 188 matches
Mail list logo
