On Feb 15, 2012, at 1:56 AM, Bob Hinden wrote:
> Martin,
>
> On Feb 14, 2012, at 2:45 PM, Martin Rex wrote:
>
>> Brian E Carpenter wrote:
>>>
>>> Martin,
>>>
One the one hand, the IETF was frowning upon NATs when they were
developed outside of the IETF. But if you look at the IETFs
Victor Kuarsingh wrote:
>
> "Randy Bush" wrote:
> >
> >> In that I completely agree with what Randy is saying, the point
> >> that needs to be made is that this should not be officially
> >> sanctioned as RFC-1918 space -- no manufacturer or programmer
> >> should treat this netblock the same.
>
Brian E Carpenter wrote:
>> With a fully backwards compatible transparent addressing scheme,
>> a much larger fraction of the nodes would have switched to actively
>> use IPv6 many years ago.
> Why? They would have needed updated stacks. The routers would
> have need updated stacks. The servers w
On Feb 14, 2012 7:40 PM, "Randy Bush" wrote:
>
> > Why? They would have needed updated stacks. The routers would
> > have need updated stacks. The servers would have needed updated
> > stacks. The firewalls would have needed updated stacks. The load
> > balancers would have needed updated stacks.
> Why? They would have needed updated stacks. The routers would
> have need updated stacks. The servers would have needed updated
> stacks. The firewalls would have needed updated stacks. The load
> balancers would have needed updated stacks. Many MIBs would have
> needed to be updated. DHCP server
On 02/14/2012 17:26, Pete Resnick wrote:
> Of course it will be used as 1918 space. That's not the point of the text.
My first reply in this most recent version of the thread pointed out
that now that we're finally willing to admit that if a new block is
issued it will be used as 1918 space then t
On 2012-02-15 11:45, Martin Rex wrote:
> Brian E Carpenter wrote:
>> Martin,
>>
>>> One the one hand, the IETF was frowning upon NATs when they were
>>> developed outside of the IETF. But if you look at the IETFs
>>> (lack of) migration plan, the translation that you need in order
>>> to make old-
Support Draft as written +1.
Victor K
On 12-02-14 12:38 PM, "William Check" wrote:
>+1, I support this draft Bill Check
>
>
>On Feb 14, 2012, at 10:08 AM, Thienpondt Hans wrote:
>
>> http://tools.ietf.org/html/draft-weil-shared-transition-space-request-14
>>
>> +1
>> I support this draft!
>>
On 12-02-14 3:49 PM, "Randy Bush" wrote:
>> In that I completely agree with what Randy is saying, the point
>> that needs to be made is that this should not be officially
>> sanctioned as RFC-1918 space -- no manufacturer or programmer
>> should treat this netblock the same.
>>
>> If some fly
Randy Bush wrote:
> what silliness. it will be used as rfc 1918 space no matter what the document
> says.
The difference is on how future conflicts can be resolved.
> nine years ago i was in bologna and did a traceroute out. i was surprised
> to find that the isp was using un-announced us mili
On 2/14/12 2:35 PM, Randy Bush wrote:
what silliness. it will be used as rfc 1918 space no matter what the document
says.
[...]
any thought that this is not just adding to rfc 1918 is pure bs.
Of course it will be used as 1918 space. That's not the point of the text.
The text is saying,
Pete Resnick wrote:
>
> Do you, or do you not, object to the proposed change that changes the
> text from saying, "This space may be used just as 1918 space" to "This
> space has limitations and cannot be used as 1918 space"? Nobody on the
> list objected to that new text. That new text signifi
> The deployment problem was not due to technical issues, it was because
> the Internet changed to only deploy new technology that generated
> revenue in the short term. After a lot of thought, I have come to the
> conclusion that it wouldn't have mattered what the IETF did, we would
> still be fa
Bradner, Scott wrote:
> the IAB advised ARIN that such assignments were in the purview of the IETF
Then, isn't it enough for IETF to conclude "let ARIN decide"?
Are there any objections to conclude so?
Masataka Ohta
___
Mark Andrews wrote:
> Happy eyeballs just points out problems with multi-homing in general.
> IPv4 has the *same* problem and sites spend 1000's of dollars working
> around the issue which could have been addressed with a couple of
> extra lines of code on the client side in most cases.
It's Bria
Brian E Carpenter wrote:
> I'm sorry, but *any* coexistence between RFC791-IPv4-only hosts and
> hosts that are numbered out of an address space greater than 32 bits
> requires some form of address sharing,
Sure.
> address mapping, and translation.
Not at all.
Realm Specific IP [RFC3102] is su
Martin,
On Feb 14, 2012, at 2:45 PM, Martin Rex wrote:
> Brian E Carpenter wrote:
>>
>> Martin,
>>
>>> One the one hand, the IETF was frowning upon NATs when they were
>>> developed outside of the IETF. But if you look at the IETFs
>>> (lack of) migration plan, the translation that you need in
In message <201202142245.q1emjaou019...@fs4113.wdf.sap.corp>, Martin Rex writes
:
> The necessary changes to applications would be minimal,
> the "happy eyeballs" contortion completely unnecessary
> and the security assessment for an IPv6 enabled network
> *MUCH* simpler.
Happy eyeballs just poin
Brian E Carpenter wrote:
>
> Martin,
>
> > One the one hand, the IETF was frowning upon NATs when they were
> > developed outside of the IETF. But if you look at the IETFs
> > (lack of) migration plan, the translation that you need in order
> > to make old-IPv4 interoperate with new-IPv6, is act
Martin,
> One the one hand, the IETF was frowning upon NATs when they were
> developed outside of the IETF. But if you look at the IETFs
> (lack of) migration plan, the translation that you need in order
> to make old-IPv4 interoperate with new-IPv6, is actually worse than
> an IPv4 NAT.
I'm sor
Bob Braden wrote:
>
> Within the ARPA-funded Internet research program that designed IP and
> TCP, Jon Postel and Danny Cohen argued strenuously for variable length
> addresses. (This must have been around 1979. I cannot name most of the
> other 10 people in the room, but I have a clear mental pi
I agree with Adrian. Individuals come to the IETF, not companies. Sure
they are employed by companies, but they also have to follow the rules stated
in BCP79. I am really tired of the myriad of excuses people have given in the
past about why they have not been able to comply. Its a re
Randy Bush writes:
> in response to me:
> > In that I completely agree with what Randy is saying, the point
> > that needs to be made is that this should not be officially
> > sanctioned as RFC-1918 space -- no manufacturer or programmer
> > should treat this netblock the same.
> >
> > If some fl
Todd,
You may or may not be right about whether an individual can make a decision to
disclose. In my experience they often can't, but do have the power to
request/implore their employer to disclose.
On the other hand, they *do* have the power to not participate.
BCP79 offers this choice and I ma
> In that I completely agree with what Randy is saying, the point
> that needs to be made is that this should not be officially
> sanctioned as RFC-1918 space -- no manufacturer or programmer
> should treat this netblock the same.
>
> If some fly-by-night company chooses to use it on their own,
>
On 2012-02-15 09:35, Randy Bush wrote:
>> Do you, or do you not, object to the proposed change that changes the
>> text from saying, "This space may be used just as 1918 space" to "This
>> space has limitations and cannot be used as 1918 space"?
>
> what silliness. it will be used as rfc 1918 s
Randy Bush writes:
> in response to Pete Resnick, who wrote:
>> Do you, or do you not, object to the proposed change that
>> changes the text from saying, "This space may be used just
>> as 1918 space" to "This space has limitations and cannot be
>> used as 1918 space"?
>
> what silliness. it wi
This is a reminder that the IAOC is conducting a T-Shirt Design Contest to
develop a unique t-shirt for the Paris meeting. You have until this Friday, Feb
17 to submit your design for consideration. We've received two submissions so
far and you can see them here:
http://www.ietf.org/meeting/83/
> Do you, or do you not, object to the proposed change that changes the
> text from saying, "This space may be used just as 1918 space" to "This
> space has limitations and cannot be used as 1918 space"?
what silliness. it will be used as rfc 1918 space no matter what the document
says.
nine y
On 2/14/12 1:50 PM, ned+i...@mauve.mrochek.com wrote:
>> Are you now objecting to that replacement text and want -14 published as
>> is? Do you think the document should say that the new allocation can be
>> used as 1918 space? If so, please explain.
>
> Not sure how a +1 to a statement saying
On 2/14/12 1:50 PM, ned+i...@mauve.mrochek.com wrote:
Are you now objecting to that replacement text and want -14 published as
is? Do you think the document should say that the new allocation can be
used as 1918 space? If so, please explain.
Not sure how a +1 to a statement saying "I support t
Pete Resnick wrote:
> I'm not sure I understand what you're saying. There was some
> objection at the beginning of this thread by Wes George, Noel
> Chiappa, and Brian Carpenter. I agreed that the document
> could be misunderstood as encouraging the use of the space as
> 1918 space and proposed
To the addressed folks who's messages appear below:
I'm not sure I understand what you're saying. There was some objection
at the beginning of this thread by Wes George, Noel Chiappa, and Brian
Carpenter. I agreed that the document could be misunderstood as
encouraging the use of the space as 1
On Tue, Feb 14, 2012 at 1:49 PM, David Conrad wrote:
> I'm curious: how is the IETF stopping ARIN from allocating the space?
>
+1
though honestly I'm not a fan of the process.
> Thanks,
> -drc
>
> On Feb 14, 2012, at 10:33 AM, Bradner, Scott wrote:
>
> (not voting twice, my other address did n
the IAB advised ARIN that such assignments were in the purview of the IETF
Scott
Scott O Bradner
Senior Technology Consultant
Harvard University Information Technology
Innovation & Architecture
(P) +1 (617) 495 3864
29 Oxford St. Rm 407
Cambridge, MA 02138
On Feb 14, 2012, at 1:49 P
I'm curious: how is the IETF stopping ARIN from allocating the space?
Thanks,
-drc
On Feb 14, 2012, at 10:33 AM, Bradner, Scott wrote:
> (not voting twice, my other address did not seem to work)
>
> +1
>
> On Feb 14, 2012, at 1:25 PM, Ross Callon wrote:
>
>> +1.
>>
>> Ross
>>
>> From: ie
To the addressed folks who's messages appear below:
I'm not sure I understand what you're saying. There was some objection
at the beginning of this thread by Wes George, Noel Chiappa, and Brian
Carpenter. I agreed that the document could be misunderstood as
encouraging the use of the space as
in the case of IPng, the router people wanted variable length but the host people (or at least some of them) did not
Scott
Scott O Bradner
Senior Technology Consultant
Harvard University Information Technology
Innovation & Architecture
(P) +1 (617) 495 3864
29 Oxford St. Rm 407
Cambridge,
The word alignment issue was very strong and the router people had considerably
more influence than the host folks. I tried to propose variable length
addressing using four bit nibbles in August 1974 and I got no traction at all.
Steve
Sent from my iPhone
On Feb 14, 2012, at 6:31 PM, Bob Brad
(not voting twice, my other address did not seem to work)
+1
On Feb 14, 2012, at 1:25 PM, Ross Callon wrote:
+1.
Ross
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On
Behalf Of Owen DeLong
Sent: Monday, February 13, 2012 2:06 PM
To: ietf@ietf.org
Cc: draft-bdgks-
+1.
Ross
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Owen
DeLong
Sent: Monday, February 13, 2012 2:06 PM
To: ietf@ietf.org
Cc: draft-bdgks-arin-shared-transition-space@tools. org
Subject: Re: Another last call for draft-weil
I support draft-weil as revised. There is
Apologies for top posting rather than addressing specific
commentators, but there have been several misconceptions raised
several times that I felt should be addressed generically:
1) "We are out of IPv4 space / There's no-where to get this /10" -
There is already a /10 reserved by the ARIN commun
On 2/12/2012 10:12 AM, Adrian Farrel wrote:
> Hi SM,
So isnt the real issue that of informed consent? If you dont know that
someone else has already existing work is it their fault for not telling
the IETF?
If so then there would also need to be some form of process identical to
this for verifyin
+1, I support this draft… Bill Check
On Feb 14, 2012, at 10:08 AM, Thienpondt Hans wrote:
> http://tools.ietf.org/html/draft-weil-shared-transition-space-request-14
>
> +1
> I support this draft!
>
> Best Regards,
>
> Hans
>
>
> --
> Hans Thienpondt
> Technology Engineer
>
> Converged Net
On 2/2/2012 3:05 PM, Chris Grundemann wrote:
> Hides the screen, nervous, pays cash... Sounds to me like anyone
> surfing pr0n at the "Internet Cafe" is now a suspected terrorist.z
You should go spend a week in the border towns in Israel before you make
such telling comments like that.
Todd
>
>
On 2/13/2012 7:53 PM, Noel Chiappa wrote:
> From: Brian E Carpenter
> The design error was made in the late 1970s, when Louis Pouzin's advice
> that catenet addresses should be variable length, with a format prefix,
> was not taken during the design of IPv4.
Ironically,
http://tools.ietf.org/html/draft-weil-shared-transition-space-request-14
+1
I support this draft!
Best Regards,
Hans
--
Hans Thienpondt
Technology Engineer
Converged Network Engineering
Telenet NV
Liersesteenweg 4 - box 52
T: +32 15 33 30 24
2800 Mechelen - Belgium
**
On Feb 14, 2012, at 5:23 AM, Maglione Roberta wrote:
Please let me know if you have additional comments.
Thanks! I think you should change this text in the introduction:
The mandatory authentication was
originally motivated by a legitimate security concern whereby in some
network environ
Hi Randy and Brian,
I am sure the discussion of the discussion has been had before, but:
> > IPv4 provides no mechanism whatever for addresses greater than 32 bits.
> > Therefore, mathematically, there is no possible design for an IP with
> > bigger addresses that is transparently backwards com
On Feb 13, 2012, at 3:21 PM, Ted Lemon wrote:
> On Feb 13, 2012, at 4:06 PM, Ben Campbell wrote:
>> Do I infer correctly from your comment that the security properties of the
>> mechanism don't really matter? That is, if the attacker we care about can't
>> eavesdrop in the first place, does thi
On Feb 13, 2012, at 4:06 PM, Ben Campbell wrote:
Do I infer correctly from your comment that the security properties of the
mechanism don't really matter? That is, if the attacker we care about can't
eavesdrop in the first place, does this really need to be an HMAC?
Hm, I thought about that a bi
On Feb 11, 2012, at 10:24 AM, Ted Lemon wrote:
>> [RM] The intention is to use this method only for environments with native
>> security mechanisms, such as the Broadband Access network. You are right it
>> is not clearly said in the document I can add the following sentence at the
>> end of th
Hi, thanks for the response. See additional comments inline. (I removed
sections for which no further comment seems necessary)
On Feb 10, 2012, at 7:52 AM, Maglione Roberta wrote:
[...]
>
> -- I admit to not being a DHCP expert, but If I understand this draft
> correctly, it proposes to send
I support draft-weil as revised. There is a vital need for this to move forward
and the IETF should stop standing in the way and let ARIN allocate the space
already.
Owen
On Feb 13, 2012, at 10:09 AM, Chris Grundemann wrote:
> Fellow BDGKS Authors,
>
> FYI: draft-weil is in another Last Call
+1. One point I would like to make regarding not being encourage to
move to IPv6, was increased when the RIRs established the new IPv4
request "prove your need" policies. It immediately strengthen the
notion that we must keep our existing IPv4 Class C network because if
we let it go, we might
I support this draft as updated.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
> I support this updated draft, and I am keen for this to be published as a
> BCP.
+1
> I believe the amendments in this revision clarify the usage and intended
> purpose of the shared transition space.
+1
Ned
___
Ietf
I also support this draft.
Donald
On Tuesday, February 14, 2012, Daryl Tanner
wrote:
> I support this updated draft, and I am keen for this to be published as a
BCP.
>
> I believe the amendments in this revision clarify the usage and intended
purpose of the shared transition space.
>
>
> Daryl
>
> From: Roger Jorgensen
> Sorry Noel but I choice to reply public to this one.
Ah, no, actually. Had you thought about it for a moment or two, you could
have realized that you could have made your point just as well without
publicly quoting my private email. But why am I not surprised?
On 2/13/2012 7:09 PM, Brian E Carpenter wrote:
On 2012-02-14 13:42, Dave CROCKER wrote:
On 2/13/2012 4:38 PM, Brian E Carpenter wrote:
There were very specific reasons why this was not done.
Is there a useful citation that covers this strategic decision?
You may recall that at the time,
I support this updated draft, and I am keen for this to be published as a
BCP.
I believe the amendments in this revision clarify the usage and intended
purpose of the shared transition space.
Daryl
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.o
Hello Ted and Bell,
I tried to address both your comments by combining your proposals:
Basically I added the text suggested by Ted in the security considerations
section and then I slightly modified the introduction in order to clarify the
applicability.
I've just posted version -04 that include
The more serious problem is that IPv6 people in IETF do
not admit IPv6 broken, which makes it impossible to fix
IPv6.
Make a draft, gather your "supporters" and take that discussion on
6man wg. I'm sure there are people open to consider any arguments on
what's wrong/or not.
Now, I'm tired of s
On Tue, Feb 14, 2012 at 5:51 AM, Masataka Ohta
wrote:
> Brian E Carpenter wrote:
>
>> Sure, that's very common, but these devices are consumer electronics and
>> will get gradually replaced by IPv6-supporting boxes as time goes on.
>
> The problem is that IPv6 specification is still broken in
> se
Sorry Noel but I choice to reply public to this one.
On Mon, Feb 13, 2012 at 10:52 PM, Noel Chiappa wrote:
> > IPv6 is The Key!
>
> If you think denying a CGN block will do anything at all to help IPv6,
> you're very confused.
quote out of context etc... but my change of mind from supporting
65 matches
Mail list logo
