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
In message 20111206055756.gd20...@besserwisser.org, =?utf-8?B?TcOlbnM=?= Nils
son writes:
Subject: Re: class E (was: Consensus Call: draft-weil-shared-transition-s=
pace-request) Date: Tue, Dec 06, 2011 at 08:38:56AM +1100 Quoting Mark Andr=
ews (ma...@isc.org):
=20
Ask everyone everywhere
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.
Mark,
On 12/5/11 10:38 PM, Mark Andrews wrote:
It's not that the CPE's can't renumber. The ISP are already using RFC
1918, in good faith, internally to talk to the management interfaces
of modems so using RFC 1918 is forcing the ISP's to renumber out of
whichever RFC 1918 block that is
In message 4ede4884.1030...@cisco.com, Eliot Lear writes:
Mark,
On 12/5/11 10:38 PM, Mark Andrews wrote:
It's not that the CPE's can't renumber. The ISP are already using RFC
1918, in good faith, internally to talk to the management interfaces
of modems so using RFC 1918 is forcing the
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
On Dec 5, 2011, at 4:58 PM, David Conrad wrote:
On Dec 5, 2011, at 1:13 PM, John C Klensin wrote:
this is a much stronger argument for a dear customer, either renumber or
upgrade your
hardware position
I'd imagine the vast majority of the customers of ISPs who are facing this
issue
Subject: Re: class E (was: Consensus Call:
draft-weil-shared-transition-space-request) Date: Wed, Dec 07, 2011 at
12:19:49AM +1100 Quoting Mark Andrews (ma...@isc.org):
In message 20111206055756.gd20...@besserwisser.org, =?utf-8?B?TcOlbnM=?=
Nils
son writes:
Subject: Re: class E
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
On 5 December 2011 04:27, Cameron Byrne wrote:
[they = the IETF]
they underscored that point by not rejecting various past attempts at
expanding private ipv4 space like 240/4.
Sorry. S/not rejecting/rejecting/
ACK. The last state I'm aware of is that the 240/4 addresses minus one
were and
Frank,
On Dec 5, 2011, at 9:46 AM, Frank Ellermann wrote:
The last state I'm aware of is that the 240/4 addresses minus one
were and still are (RFC 5735) reserved for IETF experiments, did I miss
some newer IETF consensus about this?
...
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,
On Mon, Dec 5, 2011 at 9:46 AM, Frank Ellermann
hmdmhdfmhdjmzdtjmzdtzktdkzt...@gmail.com wrote:
On 5 December 2011 04:27, Cameron Byrne wrote:
[they = the IETF]
they underscored that point by not rejecting various past attempts at
expanding private ipv4 space like 240/4.
Sorry. S/not
On Mon, Dec 5, 2011 at 1:00 PM, David Conrad d...@virtualized.org wrote:
Frank,
On Dec 5, 2011, at 9:46 AM, Frank Ellermann wrote:
The last state I'm aware of is that the 240/4 addresses minus one
were and still are (RFC 5735) reserved for IETF experiments, did I miss
some newer IETF
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,
Marshall,
On Dec 5, 2011, at 10:21 AM, Marshall Eubanks wrote:
On Mon, Dec 5, 2011 at 1:00 PM, David Conrad d...@virtualized.org wrote:
Frank,
On Dec 5, 2011, at 9:46 AM, Frank Ellermann wrote:
The last state I'm aware of is that the 240/4 addresses minus one
were and still are (RFC 5735)
From: Bob Hinden bob.hin...@gmail.com
As far as I can tell, it would only require the CPE router, CGN's, and
routers between the CPE and CGN's to support it. ... I think it's
reasonable for the ISPs who want to deploy this CGN gear to the deal with
upgrading the CPE
Noel,
On Dec 5, 2011, at 10:58 AM, Noel Chiappa wrote:
From: Bob Hinden bob.hin...@gmail.com
As far as I can tell, it would only require the CPE router, CGN's, and
routers between the CPE and CGN's to support it. ... I think it's
reasonable for the ISPs who want to deploy this CGN gear to
On 05/12/2011 18:58, Noel Chiappa wrote:
Why don't the ISPs get together, outside the IETF (I so wanted to expand on
this thought, but I had better not), and have one of them - one which is in
an area with an RIR with the most available space - go their RIR and ask for
a /10 for their in-house
Bob,
On Dec 5, 2011, at 11:36 AM, Bob Hinden wrote:
So a CGN deployment is a new deployment and the ISPs choosing to do this
could make sure that their customers CPE can support class E addresses,
upgrade the CPE firmware,
I think the ISPs are saying that there is a non-trivial base of
From: Nick Hilliard n...@inex.ie
Given that we just saw a /16 sold for $12/ip, what makes you think that
any carrier would open up a /10 allocated to them for the good of
humanity, at a potential future asset loss of $50m?
I hear you, but... if these things are worth so much,
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
--On Monday, December 05, 2011 11:54 -0800 David Conrad
d...@virtualized.org wrote:
Bob,
On Dec 5, 2011, at 11:36 AM, Bob Hinden wrote:
So a CGN deployment is a new deployment and the ISPs choosing
to do this could make sure that their customers CPE can
support class E addresses, upgrade
On 12/5/11 2:13 PM, John C Klensin john-i...@jck.com wrote:
--On Monday, December 05, 2011 11:54 -0800 David Conrad
d...@virtualized.org wrote:
Bob,
On Dec 5, 2011, at 11:36 AM, Bob Hinden wrote:
So a CGN deployment is a new deployment and the ISPs choosing
to do this could make sure
In message 0780b9d75d1ce23f15b5a...@pst.jck.com, John C Klensin writes:
--On Monday, December 05, 2011 11:54 -0800 David Conrad
d...@virtualized.org wrote:
Bob,
On Dec 5, 2011, at 11:36 AM, Bob Hinden wrote:
So a CGN deployment is a new deployment and the ISPs choosing
to do this
In message cb028331.30361%c.don...@cablelabs.com, Chris Donley writes:
On 12/5/11 2:13 PM, John C Klensin john-i...@jck.com wrote:
--On Monday, December 05, 2011 11:54 -0800 David Conrad
d...@virtualized.org wrote:
Bob,
On Dec 5, 2011, at 11:36 AM, Bob Hinden wrote:
So a CGN
In message
CAJNg7V+wxN_hsqGA_hQOr0Yc3Xyf1dqJQmaCDjzRu-zGCf_-=w...@mail.gmail.com
, Marshall Eubanks writes:
On Mon, Dec 5, 2011 at 1:00 PM, David Conrad d...@virtualized.org wrote:
Frank,
On Dec 5, 2011, at 9:46 AM, Frank Ellermann wrote:
The last state I'm aware of is that the 240/4
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
John,
On Dec 5, 2011, at 1:13 PM, John C Klensin wrote:
this is a much stronger argument for a dear customer, either renumber or
upgrade your
hardware position
I'd imagine the vast majority of the customers of ISPs who are facing this
issue would react either with anger or non-comprehension
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
Subject: Re: class E (was: Consensus Call:
draft-weil-shared-transition-space-request) Date: Tue, Dec 06, 2011 at
08:38:56AM +1100 Quoting Mark Andrews (ma...@isc.org):
Ask everyone everywhere that is using this block, in good faith,
for some purpose other than supporting addresses behind
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
1 - 100 of 211 matches
Mail list logo
