RE: Consensus Call: draft-weil-shared-transition-space-request
I do not support forwarding the draft (In fact, i oppose it strongly.). Chopping away bits of the usable v4 space to create more unusable space does not in any way help. I can but hope to emulate Randys terse and on-the-spot argumentation, so I'll have to make do with concurring. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 LBJ, LBJ, how many JOKES did you tell today??! signature.asc Description: Digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: tools a little bit broken
Fixed.
(This was an issue lingering after a disk-crash on one of the machines much
earlier this year, exposed by a major rev Python upgrade (2.6 -- 2.7)
which didn't pull in all the needed packages because they weren't registered
as installed, although present on disk for 2.6)
Best regards,
Henrik
On 2011-11-30 02:59 Terry Manderson said the following:
'twas just heading to the SIDR tools page in a effort to self inflict
sufficient mental confusion that I would try to scoop my eyeballs out of
their sockets with a rusty spoon, I was saved from myself by a bit of a
hiccup in the system:
Horrid cut-n-paste:
An error occurred at this point in the web-page generation.
An error report has been sent to the webmaster. If this error isn't fixed
within 48 hours, please contact the web page author directly.
% (timestr(filetime(cachename)), timestr(dirtime(.))) 451 # if not
cachefile: include = filename = '/www/tools.ietf.org/wg/sidr/index.pyht'
/www/cgi-bin/pyht.py in
include(filename='/www/tools.ietf.org/wg/sidr/index.pyht') 222 223 if
string.find(code, \n) -1: 224 exec code in execglobals, execlocals 225
else: 226 res = eval(code, execglobals, execlocals) code = '
\ntryinclude(head.pyht)\ntryinclude(top.pyht)\ntryinclude(drafts.pyht)
\ntryinclude(bot.pyht)\n' global execglobals = {'Wg': 'Sidr',
'__builtins__': , 'area': 'rtg', 'args': {}, 'basename': , 'cookie': ,
'dirname': , 'env': {'REDIRECT_STATUS': '200', 'SERVER_SOFTWARE':
'A.../sidr/', 'HTTP_ACCEPT_ENCODING': 'gzip, deflate'}, 'escape': ,
'filetext': , ...} execlocals = {'__name__': 'embedded-code-at-line-6',
'datenow': '30 Nov 2011 01:53 GMT', 'filebase': 'index', 'filedate': ,
'fileext': '.pyht', 'filename': '/www/tools.ietf.org/wg/sidr/index.pyht',
'filepath': '/www/tools.ietf.org/wg/sidr', 'filetime': , 'interpreter':
'/www/cgi-bin/pyht.py', 'time': , ...} /home/www/tools.ietf.org/wg/sidr/ in
() /www/cgi-bin/pyht.py in tryinclude(filename='top.pyht') 244 def
tryinclude(filename): 245 if os.path.isfile(filename): 246 include(filename)
247 return 248 global include = filename = 'top.pyht'
/www/cgi-bin/pyht.py in include(filename='top.pyht') 222 223 if
string.find(code, \n) -1: 224 exec code in execglobals, execlocals 225
else: 226 res = eval(code, execglobals, execlocals) code = '\nchairlist =
filetext(chairs.txt).rstrip().spl...f=mailto:%s;%s
\\n\' %(chair[0], name))\n' global execglobals = {'Wg': 'Sidr',
'__builtins__': , 'area': 'rtg', 'args': {}, 'basename': , 'cookie': ,
'dirname': , 'env': {'REDIRECT_STATUS': '200', 'SERVER_SOFTWARE':
'A.../sidr/', 'HTTP_ACCEPT_ENCODING': 'gzip, deflate'}, 'escape': ,
'filetext': , ...} execlocals = {'__name__': 'embedded-code-at-line-70',
'ad': 'adr...@olddog.co.uk\tAdrian Farrel', 'adlist': ': Stewart Bryant,
Adrian Farrel', 'chair': 'sandra.mur...@sparta.com\tSandra Murphy',
'chairlist': ['sandra.mur...@sparta.com\tSandra Murphy',
'morr...@ops-netman.net\tChris Morrow'], 'chartered': '2006-Apr-18',
'concluded': '', 'datenow': '30 Nov 2011 01:53 GMT', 'docroot':
'/home/www/tools.ietf.org/', 'email': ['Sandra.Murphy', 'sparta.com'], ...}
/home/www/tools.ietf.org/wg/sidr/ in () /home/www/tools.ietf.org/wg/sidr/ in
getimg(path='../../photo/', name='Sandra Murphy') : No module named Image
__class__ = __delattr__ = __dict__ = {} __doc__ = Import can't find module,
or can't find name in module. __format__ = __getattribute__ = __getitem__ =
__getslice__ = __hash__ = __init__ = __new__ = __reduce__ = __reduce_ex__ =
__repr__ = __setattr__ = __setstate__ = __sizeof__ = __str__ =
__subclasshook__ = __unicode__ = args = ('No module named Image',) message =
'No module named Image' The above is a description of an error in a Python
program. Here is the original traceback: Traceback (most recent call last):
File /www/cgi-bin/pyht.py, line 449, in include(filename) File
/www/cgi-bin/pyht.py, line 224, in include exec code in execglobals,
execlocals File , line 3, in File /www/cgi-bin/pyht.py, line 246, in
tryinclude include(filename) File /www/cgi-bin/pyht.py, line 224, in
include exec code in execglobals, execlocals File , line 12, in File ,
line 21, in getimg ImportError: No module named Image --
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
Date:Tue, 29 Nov 2011 21:09:22 -0700 From:Sumanth Channabasappa suma...@cablelabs.com Message-ID: 76AC5FEF83F1E64491446437EA81A61F81D7CBBA11@srvxchg This whole question is weird, when someone needs an address to use, and given that the pool of free (or close to it), that is, easily available, addresses no longer exists, I'm going to take whatever address will work for me for its purpose. What the various addresses are marked as in some RFC or IANA list, is immaterial, all that matters is what works. If that means borrowing (or squatting if you prefer) on the addresses some ISP in some remote part of the world uses for its customers, that my customers will never need to communicate with (in my opinion), then that's what I will do. More likely, if I can, will be to take some address that I know can't be needed, and use that - 1918 addresses are in that category. So is the documentation prefix (which only has as its problem that it is too little address space to actually use for most purposes). The only real criteria is whether the address I'm considering is in the routing tables or not - if it isn't, regardless of reason, then I can use it without harm. For most purposes, the 1918 address space is going to be the right choice whenever I don't need a routable address, and it is here too. | ISPs have already indicated (a few times) that RFC1918 space is not | practical behind the CGN due to the (real) possibility of overlap | with customer addressing. Frankly, that's nonsense. Not that there's the possibility of overlap, of course there is that possibility. And not that things would break if there was a duplicate allocation on both sides, they might, probably even would. But that that actually matters if done sensibly. We know that normal consumer CPE equipment doesn't use network 10 (you just have to look at some to see that, they almost all use 192.168 addresses). Further, it is hard to imagine how any network not managed by network professionals would, or could, ever use network 10, with the possible exception of 10.0.0/24 or 10.255.255/24 which are numbers that one might imagine some odd CPE manufacturer might just pluck from the air. If the ISP were simply to use 10.64.0.0/10 as the /10 they claim to need for their CGN's, the chances of that conflicting with any customer who doesn't have a network staff smart enough to deal with the issue is basically zero. For the one in a thousand (probably less) customers who do end up having a problem, there are plenty of other 1918 addresses that the ISP could pick from, for that individual customer, which would not cause problems. Certainly, no-one is going to want to have to deal with every individual customer, but dealing with one or two odd cases should be no burden. Further, I can't imagine that the ISPs aren't aware of this, they know what CPE equipment is being used, and how it is typically configured. They also know they could cope with the one in a thousand end user who actually has configured 10.64/8 in the inside of their CPE, and isn't willing to change that. The paranoid in me suspects that the IESG should not be making a decision to approve a /10 for CGN usage without making sure the anti-trust policy that's being discussed in another thread is in place, and that everything in this request has been in accordance with that policy. That's because, to me, this smells like a cartel of major ISPs with plenty of allocated IPv4 address space (legitimately allocated, and used properly right now) looking for a blessing from the IETF (that using private addresses and CGNs is OK) to be able to reclaim much of their currently allocated v4 address space. And I cannot imagine a single one of them (or almost any) just returning that space to the RIR's for allocations - in many countries, doing so (by any of the major ISPs that are listed public companies) would probably be a breach of the director's duty to properly manage the resources of the company - since addresses (address blocks) sell for such high returns these days, simply giving away whatever the company has had allocated could easily lead to prison terms for the directors of the ISP... Other than small privately owned ISPs, they really cannot return the addresses, so their only option is to be selling the things for the profit they'd gain. Does the IETF really want to be blessing a doc written by a group who all appear to come from the very types of ISPs who would be subject to likely to benefit from such an action? (Note: I am not intending to suggest that any of the authors of the doc was actually planning such an action, just looking at how it all appears from the outside.) Lastly, while I am here, I have absolutely no sympathy at all for manufacturers of consumer equipment (or any equipment) that is currently being sold, or has sold in the past 5 years (at least) that is not able to use IPv6 rather than IPv4 for network connectivity.
Re: tools a little bit broken
Thanks Henrik!
Back to the eye gouging fun ;)
Cheers,
Terry
On 30/11/2011, at 6:42 PM, Henrik Levkowetz hen...@levkowetz.com wrote:
Fixed.
(This was an issue lingering after a disk-crash on one of the machines much
earlier this year, exposed by a major rev Python upgrade (2.6 -- 2.7)
which didn't pull in all the needed packages because they weren't registered
as installed, although present on disk for 2.6)
Best regards,
Henrik
On 2011-11-30 02:59 Terry Manderson said the following:
'twas just heading to the SIDR tools page in a effort to self inflict
sufficient mental confusion that I would try to scoop my eyeballs out of
their sockets with a rusty spoon, I was saved from myself by a bit of a
hiccup in the system:
Horrid cut-n-paste:
An error occurred at this point in the web-page generation.
An error report has been sent to the webmaster. If this error isn't fixed
within 48 hours, please contact the web page author directly.
% (timestr(filetime(cachename)), timestr(dirtime(.))) 451 # if not
cachefile: include = filename = '/www/tools.ietf.org/wg/sidr/index.pyht'
/www/cgi-bin/pyht.py in
include(filename='/www/tools.ietf.org/wg/sidr/index.pyht') 222 223 if
string.find(code, \n) -1: 224 exec code in execglobals, execlocals 225
else: 226 res = eval(code, execglobals, execlocals) code = '
\ntryinclude(head.pyht)\ntryinclude(top.pyht)\ntryinclude(drafts.pyht)
\ntryinclude(bot.pyht)\n' global execglobals = {'Wg': 'Sidr',
'__builtins__': , 'area': 'rtg', 'args': {}, 'basename': , 'cookie': ,
'dirname': , 'env': {'REDIRECT_STATUS': '200', 'SERVER_SOFTWARE':
'A.../sidr/', 'HTTP_ACCEPT_ENCODING': 'gzip, deflate'}, 'escape': ,
'filetext': , ...} execlocals = {'__name__': 'embedded-code-at-line-6',
'datenow': '30 Nov 2011 01:53 GMT', 'filebase': 'index', 'filedate': ,
'fileext': '.pyht', 'filename': '/www/tools.ietf.org/wg/sidr/index.pyht',
'filepath': '/www/tools.ietf.org/wg/sidr', 'filetime': , 'interpreter':
'/www/cgi-bin/pyht.py', 'time': , ...} /home/www/tools.ietf.org/wg/sidr/ in
() /www/cgi-bin/pyht.py in tryinclude(filename='top.pyht') 244 def
tryinclude(filename): 245 if os.path.isfile(filename): 246 include(filename)
247 return 248 global include = filename = 'top.pyht'
/www/cgi-bin/pyht.py in include(filename='top.pyht') 222 223 if
string.find(code, \n) -1: 224 exec code in execglobals, execlocals 225
else: 226 res = eval(code, execglobals, execlocals) code = '\nchairlist =
filetext(chairs.txt).rstrip().spl...f=mailto:%s;%s
\\n\' %(chair[0], name))\n' global execglobals = {'Wg': 'Sidr',
'__builtins__': , 'area': 'rtg', 'args': {}, 'basename': , 'cookie': ,
'dirname': , 'env': {'REDIRECT_STATUS': '200', 'SERVER_SOFTWARE':
'A.../sidr/', 'HTTP_ACCEPT_ENCODING': 'gzip, deflate'}, 'escape': ,
'filetext': , ...} execlocals = {'__name__': 'embedded-code-at-line-70',
'ad': 'adr...@olddog.co.uk\tAdrian Farrel', 'adlist': ': Stewart Bryant,
Adrian Farrel', 'chair': 'sandra.mur...@sparta.com\tSandra Murphy',
'chairlist': ['sandra.mur...@sparta.com\tSandra Murphy',
'morr...@ops-netman.net\tChris Morrow'], 'chartered': '2006-Apr-18',
'concluded': '', 'datenow': '30 Nov 2011 01:53 GMT', 'docroot':
'/home/www/tools.ietf.org/', 'email': ['Sandra.Murphy', 'sparta.com'], ...}
/home/www/tools.ietf.org/wg/sidr/ in () /home/www/tools.ietf.org/wg/sidr/ in
getimg(path='../../photo/', name='Sandra Murphy') : No module named Image
__class__ = __delattr__ = __dict__ = {} __doc__ = Import can't find module,
or can't find name in module. __format__ = __getattribute__ = __getitem__ =
__getslice__ = __hash__ = __init__ = __new__ = __reduce__ = __reduce_ex__ =
__repr__ = __setattr__ = __setstate__ = __sizeof__ = __str__ =
__subclasshook__ = __unicode__ = args = ('No module named Image',) message =
'No module named Image' The above is a description of an error in a Python
program. Here is the original traceback: Traceback (most recent call last):
File /www/cgi-bin/pyht.py, line 449, in include(filename) File
/www/cgi-bin/pyht.py, line 224, in include exec code in execglobals,
execlocals File , line 3, in File /www/cgi-bin/pyht.py, line 246, in
tryinclude include(filename) File /www/cgi-bin/pyht.py, line 224, in
include exec code in execglobals, execlocals File , line 12, in File ,
line 21, in getimg ImportError: No module named Image --
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On 30/11/2011 05:46, Mark Andrews wrote: In messagem2r50q42nn.wl%ra...@psg.com, Randy Bush writes: 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? Aren't there a whole lot of other user gadgets that also need to work their way round this? Dyndns perhaps? How about some of the home VPN packages? Will remote desktop continue to work? The list looks large in the draft, but just how large is it in reality? Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On Wed, Nov 30, 2011 at 5:27 AM, Stewart Bryant stbry...@cisco.com wrote: On 30/11/2011 05:46, Mark Andrews wrote: In messagem2r50q42nn.wl%randy@**psg.com m2r50q42nn.wl%25ra...@psg.com, Randy Bush writes: 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? Aren't there a whole lot of other user gadgets that also need to work their way round this? Dyndns perhaps? How about some of the home VPN packages? Will remote desktop continue to work? The list looks large in the draft, but just how large is it in reality? And these applications will continue to need to work around this since non-RFC is already used (for years), and will continue to be used in CGN zones. The real issue is should this be controlled and predictable or not. This draft in no way changes that reality but seeks to improve. Victor K Stewart __**_ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/**listinfo/ietfhttps://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Consensus Call: draft-weil-shared-transition-space-request
Folks, Can anyone present empirical evidence that skype will break? I have heard claims in both directions. Ron -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Mark Andrews Sent: Tuesday, November 29, 2011 11:50 PM To: Randy Bush Cc: IETF Disgust Subject: Re: Consensus Call: draft-weil-shared-transition-space-request In message m2sjl644h3.wl%ra...@psg.com, Randy Bush writes: anyone who thinks this will not be used as 1918 space should share what they are smoking. the question is not if, but rather how many milliseconds before it is. that is the operational reality. And what harm to others does that cause? If a ISP is using this and the customer is using this rather than RFC 1918 space then they only have themselves to blame for operational problems it causes. and we should have a betting pool on how long before it is leaked into a measure such as route-views. And users would be advised to filter routes for it the same as they should be filtering routes for other space they are using. and all this is aside from the pnp, skype, ... and other breakage. and, imiho, we can screw ipv4 life support. 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? this has become a contest of wills, not a technical discussion. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-mpls-tp-mib-management-overview-05.txt(Multiprotocol Label Switching Transport Profile (MPLS-TP)MIB-based Management Overview) to Informational RFC
My review of draft-ietf-mpls-tp-mib-management-overview-05.txt It was a quick review, so that you have some idea of what I looked at. For a real review, I think it would take a lot of time. But feel free to use my comments as you see fit. As long as people realize that it was a quick skim and not a detailed review Bert Original Message Subject: Re: [MIB-DOCTORS] FW: Last Call: draft-ietf-mpls-tp-mib-management-overview-05.txt(Multiprotocol Label Switching Transport Profile (MPLS-TP)MIB-based Management Overview) to Informational RFC Date: Wed, 30 Nov 2011 12:03:47 +0100 From: Bert Wijnen (IETF) berti...@bwijnen.net To: Romascanu, Dan (Dan) droma...@avaya.com CC: mib-doct...@ietf.org, ops-...@ietf.org I did a skim of the document. - It seems to give an in depth overview of the current MIB modules in MPLS related space and also it lists identified gaps if those MIB modules need to support MPLS-TP space. - it looks to be in reasonable (good enough I guess) shape for publication as Informational RFC modulo some remarks below. - I did not go and check all the details and related documents. So I cannot claim that I have verified all (in fact any) of the statements. - I wonder if the may be extended and can be extended in the various subsections in section 5 are intended to mean different things. I think not. To me it all sounds like this could be done, but we doubt anyone will do it, or at least not in IETF. - Section 6 however DOES define what needs to be done in terms of new MIB modules, so that is promising. - I see in sect 6.1.2 that a MEP Identifier TC needs to be defined. Is this a similar identifier as the MEP Identifier defined in IEEE 802.1ag? Probably not, but someone should probably check at the time they start developing this MPLS-TP-TC MIB module. - sect 6.2.1 sems to want tio place a TC MIN module directly under transmission. I am not sure that is the proper place. So I am not sure how useful my short review is, other than to say that a document like this (assuming the data is correct and complete) is helpful for people who need to implement Network Management systems for MPLS and MPLS-TP based systems. Bert On 11/28/11 4:27 PM, Romascanu, Dan (Dan) wrote: MIB Doctors and OPS-MIB directorate members, This I-D deserves your attention, please read and send comments to the last call. Regards, Dan -Original Message- From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org] On Behalf Of The IESG Sent: Monday, November 28, 2011 5:07 PM To: IETF-Announce Cc: m...@ietf.org Subject: Last Call: draft-ietf-mpls-tp-mib-management-overview-05.txt(Multiprotocol Label Switching Transport Profile (MPLS-TP)MIB-based Management Overview) to Informational RFC The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Multiprotocol Label Switching Transport Profile (MPLS-TP) MIB-based Management Overview' draft-ietf-mpls-tp-mib-management-overview-05.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-12-12. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract A range of Management Information Base (MIB) modules has been developed to help model and manage the various aspects of Multiprotocol Label Switching (MPLS) networks. These MIB modules are defined in separate documents that focus on the specific areas of responsibility of the modules that they describe. The MPLS Transport Profile (MPLS-TP) is a profile of MPLS functionality specific to the construction of packet-switched transport networks. This document describes the MIB-based architecture for MPLS-TP, and indicates the interrelationships between different existing MIB modules that can be leveraged for MPLS-TP network management and identifies areas where additional MIB modules are required. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-mib-management-overvi ew/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-mib-management-overvi ew/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ MIB-DOCTORS mailing list mib-doct...@ietf.org https://www.ietf.org/mailman/listinfo/mib-doctors ___ MIB-DOCTORS mailing list mib-doct...@ietf.org https://www.ietf.org/mailman/listinfo/mib-doctors ___ MIB-DOCTORS mailing
Re: Consensus Call: draft-weil-shared-transition-space-request
Randy == Randy Bush ra...@psg.com writes: 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? Randy cool. then, by that logic, let's use 240/4. the apps will Randy patch within a week. ok, maybe two. Seriously, I think we *SHOULD* use 240/10. (let's keep some for the next horrible hack) -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Consensus Call: draft-weil-shared-transition-space-request
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Randy Bush talk to free.fr, camron byrne, ... there are roadmaps. but this proposal is not about migrating to ipv6. it is about ipv4 life extension and nat444 4ever. to hell with that. [WEG] let's see... free.fr = 6rd. Cameron Byrne (TMO) = NAT64 (which requires IPv6-capable end devices) + squatting on routable space (*not* 1918) + CGN. Please explain how either of those help to ensure that I can stay in business, given that my business requires me to provide functional IPv4 service to devices that my *customers* own which do not support IPv6, *IN ADDITION TO* deploying IPv6 [citations: 1, 2, 3, 4] for devices that do. Should I stop selling IPv4 service citing the IETF's principles on the matter? Tell all of my customers that they must spend hundreds or thousands of dollars to upgrade all of their otherwise functional IP-capable devices because the old ones are obsolete (not to mention that the current new ones *still* might not support IPv6)? I admit that DSLite would potentially help, but that requires support in CPE that is currently extremely limited, and my business model does not allow for me to purchase a new router for all X Million of my customers anyway. *taps the mic, clears throat* RandyBush I strongly encourage all of my competitors to do the above. /RandyBush snip this has become a contest of wills, not a technical discussion. [WEG] only because a number of folks, including you, insist on arguing about the principle of the thing and making the internet work better and IPv4 life support while rejecting technical arguments that you don't believe/like despite hearing them from multiple operators and other sources. This is turning into a referendum on CGN and whether the industry as a whole has deployed IPv6 fast enough for a set of armchair quarterbacks' taste, and now people seem content to wag fingers and revel in saying I told you so... because business reality didn't line up with their view of how the universe should work. This is akin to standing on the deck of the Titanic and yelling I told you we needed more lifeboats! instead of finding a piece of wood to float on. CGN = RFC6264. I'm not sure why it passed IETF LC or IESG vote given the resistance this draft is getting, but if you don't like it because it breaks the internet and extends IPv4, then write the draft to make that historic, along with NAT44, and any other astoundingly bad ideas that IETF has had for extending IPv4 beyond its original design life. For that matter, write a draft to make IPv4 historic. I (along with several authors of this draft) am already trying to update IETF's official position (for some value of official) from version agnostic to IPv6 is a requirement, and I'd welcome the help. But stop conflating a practical solution to a practical problem with whether IPv6 is deployed or whether CGN (and IPv4) is fundamentally bad. I've been conflicted on this draft all along. I hate the idea for all the same reasons everyone else does, and I'm just as unhappy that IPv6 isn't further along. But I see few good alternatives, and I'm not sure it's worth cutting off my nose to spite my face, so I chose to stop opposing it. You may be correct, that RFC1918 would work in the majority of cases, and that people are likely to use this new space for off-label uses the first time they run into an RFC1918 conflict. So what? Is squatting on allocated space really the better idea? What about people who legitimately *can't* use RFC1918 space? Are they just SOL, or are you convinced that they're lying? As far as I can tell, your argument regarding this being used as RFC1918 annex is - people are idiots and they'll do things we tell them not to, despite RFC that says 'Very Bad Things will happen if you do x', so we shouldn't even give them the option. The problem with idiot-proofing is that there are always better idiots. Wes George CF 1 http://www.timewarnercable.com/SoCal/support/IPv6.html 2 http://www.comcast6.net/ 3 http://ww2.cox.com/residential/idaho/support/internet/article.cox?articleId=%7B0bced860-9666-11df-6baf-%7D 4 http://www.att.com/esupport/article.jsp?sid=KB409112cv=812_requestid=723971#fbid=V_Bys5OCNCJ This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this
RE: Consensus Call: draft-weil-shared-transition-space-request
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Doug Barton Sent: Tuesday, November 29, 2011 7:00 PM To: Chris Grundemann Cc: IESG IESG; IETF Discussion Subject: Re: Consensus Call: draft-weil-shared-transition-space-request On 11/29/2011 15:37, Chris Grundemann wrote: I support draft-weil-shared-transition-space-request and the allocation of a /10 as Shared CGN Space because we are approaching complete global exhaustion of unallocated IPv4 addresses and the value of globally unique addresses is becoming manifest. As others have pointed out, those ideas contradict one another. The fact that free addresses are so valuable is precisely why they shouldn't be taken away from new entrants to the market in order to benefit the grasshoppers who've fiddled away the summer. And yes, I realize that 1,024 /20s is just a drop in the bucket. But sometimes the principle of the thing IS the thing. Even if I agree in principle, I can't agree in practice. How does a model ISP, who has deployed IPv6 to 100% of its users, support people with home electronics, and people who want to reach IPv4-only content? Network operators recognize the need to transition to IPv6 now more than ever. Again, no sympathy. They've had (by conservative estimates) 10 years. This isn't about saving network operators. draft-donley-nat444-impacts shows that CGN is not a good primary strategy; any operator with sense is deploying (or hopefully, has deployed) IPv6. What does an ISP do when it's out of IPv4 space, and new customers expect to use their game consoles? Or DVRs? Or Blu-ray players? Or web cams? Or picture frames? The IETF position might be that use of IPv4-only on consumer electronics is obsolete (see draft-intarea-ipv6-required), and that anything bought prior to IPv4 runout must be replaced. There may also be content that is IPv4-only. Smaller web sites, of course, may take a long time. Until every user has replaced their home gateways and has IPv6 access, there will certainly be p2p apps and content that are IPv4-only (not just the app, but the remote user could be IPv4-only). Of course, many of these apps break under NAT444, but many don't, and some are working around it. IPv6 would be better. However, the immediate necessity for IPv4 connectivity poses a near-term challenge which requires the deployment of address-sharing technologies. They created the crisis. Why is it our responsibility to fix it for them? Who did? You vilify ISPs, but even if an ISP has deployed IPv6 to 100% of its users, replacing all of their modems and home gateways, (gateways which many ISPs didn't provide in the first place) how does it support people with home electronics, and people who want to reach IPv4-only content? You made this an argument about CGN, so I'm describing why CGN is required. Draft-weil explains why designated address space is needed for it. Lee ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On Nov 28, 2011, at 4:25 PM, Ronald Bonica wrote: ... Because the October 10 last call elicited so little response, and because many community members have privately expressed strong opinions regarding this draft, I will summarize outstanding issues below. The following are arguments *against* draft-weil-shared-transition-space-request: - Allocation of a special-use /10 does not hasten the deployment of IPv6. It only extends the life of the IPv4 network. Since the detractors of this draft admit that operators will use another address space anyway if they're not given a /10, then the above argument is false. No matter what, CGNs will be deployed for IPv4 life-support. - If a special-use /10 is allocated, it will be used as additional RFC 1918 address space, despite a specific prohibition against such use stated by the draft. So what?? We write all kinds of RFCs with MUST NOTs in them that people ignore - but we can't stop writing RFCs just because that sometimes happens. The best we can do is write the MUST NOT, explain exactly why it's a MUST NOT, and then hope people listen. (and BTW, the current draft does not sufficiently explain why not, imho) - If a special-use /10 is allocated, it will encourage others to request still more special-use address space. So what?? They can request all they want, whether we publish this RFC or not. We'll be able to say no to them if their request falls in the same class as this one, or we'll be able to say yes to them if there's some technical merit to what they want. That's how things work, no? - Some applications will break. These applications share the characteristic of assuming that an interface is globally reachable if it is numbered by an non-RFC 1918 address. To date, the only application that has been identified as breaking is 6to4, but others may be identified in the future. Since the detractors of this draft admit that operators will use another address space anyway if they're not given a /10, then the above argument is false. There will be some address space used that is not publicly reachable and is not in the RFC1918 space, so these applications will break *anyway*. The question is if 6to4 and other use-cases would like to know what that address is going to be so they can fix themselves to handle the new address, or whether we keep them broken. -hadriel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IETF] Re: Consensus Call: draft-weil-shared-transition-space-request
On Nov 30, 2011, at 1:40 AM, Bob Hinden wrote: On Nov 29, 2011, at 10:16 PM, Christian Huitema huit...@microsoft.com wrote: I did share what I was smoking - it's called 'reality' :). Which reality? I think Randy is much more realistic! +1 +lots. You are telling us that you want a /10 of private address space set aside because you cannot use the current allocation of private address space in RFC 1918. You tell us that the effect you want to achieve cannot be attained if the address that you use are also used by customer networks. But then, there is no mechanism whatsoever that would prevent customer networks from using the new /10 as soon as it would be allocated. Sure, you may put text in a RFC somewhere, but that is not a mechanism. Ergo, if we were to make that allocation, it will become unusable for your stated purpose in a very short time. I think that's not a very good idea. I would rather not see that allocation being made. That is my view as well. I think this is a bad idea for the reasons stated. sob I was *really* trying to stay out of this (both because I made my position clear at the beginning of this effort, and because it has turned into a political pissing match). While Ron had made it clear that this was not intended to be another last call, it seems to have morphed into one, so... I too believe that this is a bad idea for the reasons already stated (and restated, and then restated again and then discussed and restated and then churned around and restated...). W Bob ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
draft-weil support
I support and encourage the immediate adoption of a /10 shared IPv4 transition space for service providers. I strongly believe that this will dramatically reduce the impact that service providers will already be burdened with when moving to CGN solutions in these last days of IPv4.In addition to pursuing CGN technologies to extend the life of our IPv4 allocations, I am actively pursuing the deployment of IPv6 to our consumer networks, initially by providing local tunnel broker POP and eventually deploying dual stack, as well as setting future product requirements to include mandatory IPv6 support. Thanks for your consideration. Scott A Griffith, Individual who cares Anchorage Alaska ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Draft Weil and Draft BDGKS
I strongly support both of these drafts. Allocation of the /10 will have only minimal negative impacts on the community, if any. Almost all of the impacts raised in the objections to draft weil will occur whether or not draft weil is moved to BCP status. The difference is that with draft weil in place, most of them can actually be mitigated whereas no such mitigation will be possible without draft weil. Delaying draft weil is, in this case, roughly equivalent to refusing it because operators are going to have to start implementing CGN and other IPv4 exhaustion coping mechanisms whether the IETF is ready or not. The objections listed in Ron's sending this to IESG ballot are: - Allocation of a special-use /10 does not hasten the deployment of IPv6. It only extends the life of the IPv4 network. - If a special-use /10 is allocated, it will be used as additional RFC 1918 address space, despite a specific prohibition against such use stated by the draft. - If a special-use /10 is allocated, it will encourage others to request still more special-use address space. - Some applications will break. These applications share the characteristic of assuming that an interface is globally reachable if it is numbered by an non-RFC 1918 address. To date, the only application that has been identified as breaking is 6to4, but others may be identified in the future. Taking each objection in order: - Allocation of a special-use /10 does not hasten the deployment of IPv6. It only extends the life of the IPv4 network. The first part of this statement is true. The second half is not an entirely accurate characterization. What this /10 will do is enable carriers and ISPs to provide services to end users in a consistent manner that vendors can adapt to. Absent this shared transition space, the uses for this space will not magically disappear and all of the problems described will still exist. The primary resulting difference will be that it will consume more global unicast addresses and create more potential for collision and other negative consequences while simultaneously removing all hope of allowing vendors to provide mitigation in software. I am one of the biggest IPv6 cheerleaders in the industry, but, I also have to work within the framework of operational reality. We're going to run out of IPv4 before everyone is ready, whether we like it or not. ISPs are going to have to cope with some various forms of IPv4 services for their customers after exhaustion. No matter what, this will be a bad situation. Failing to allocate this /10 will make it worse. - If a special-use /10 is allocated, it will be used as additional RFC 1918 address space, despite a specific prohibition against such use stated by the draft. I'm not convinced this argument is true, but, it can be made about virtually any RFC reserving space. Any special use or conventional allocation can be used in a manner contrary to it's prescribed intent. Rejecting this request with strong support and definite need from the operational community will not prevent misuse of address space, it will create the inevitable increase in such misuse as providers are forced to scramble to the use of dark space, re-use of global unicast space, and other less than ideal solutions for this purpose. - If a special-use /10 is allocated, it will encourage others to request still more special-use address space. I just don't see this. Nobody made this objection to the Documentation prefixes. Nobody made this objection to localhost getting a /8. Why is this special use request any more likely to encourage more such requests than any other? - Some applications will break. These applications share the characteristic of assuming that an interface is globally reachable if it is numbered by an non-RFC 1918 address. To date, the only application that has been identified as breaking is 6to4, but others may be identified in the future. All of the applications that will break if providers use this space will also break if providers use any of the following: RFC-1918 that collides with the customers internal network. Dark space Recycled Global Unicast Space Class E space The difference is that with this allocation, providers will all break in the same consistent way and vendors can mitigate the breakage through software upgrades in some (many) cases. Without this allocation, providers will use some random mixture of all of the above in an uncoordinated and undefined way, making it impossible for vendors to provide any mitigation to such breakage. Respectfully Submitted, Owen DeLong Co-author draft-bdgks IPv6 Evangelist Director Professional Services Hurricane Electric Member, ARIN Advisory Council The opinions contained here are my own and do not necessarily reflect the views of my employer, ARIN, or the ARIN Advisory Council. ___ Ietf mailing list Ietf@ietf.org
draft-weil
Two comments, admittedly from someone who's been well out of ISP sysadmin for some years now: 1) The proposal in draft-weil sucks. It fills me with abject horror that some ISPs - and I hope not all - are going to deploy CGN and other, similar, half-arsed connectivity tricks to pretend to customers that they're offering an actual service. 2) Unfortunately, the alternative - forcing the ISPs to jury-rig their own, worse, solutions, in effect - seems worse. I'm persuaded in particular by the comments made by Owen DeLong. And awful connectivity via the draft-weil method is at least better service than these alternatives. Therefore I support, with immense distaste, publication of draft-weil as a Least Awful Common Practise document. I'm really not keen on the notion of it being labelled Best, but I suppose it'll have to do. Dave. (Sent via IPv6, of course). -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
From: Ronald Bonica rbon...@juniper.net Allocation of a special-use /10 does not hasten the deployment of IPv6. Snark=0 - or as close to it as I can humanly manage. So, after reading the back-and-forth in the thread, I'm moved to come back to this. Just what measures, within the I*'s purview, do you (and the rest of the IESG, and the IAB) think _will_ hasten the deployment of IPv6? Because the I* has had very little success in getting IPv6 deployed over the last couple of decades. With this many smart people involved, you'd think that if there was a good way to make it happen, somebody would have worked it out by now. And if there is no good way to hasten the deployment of IPv6, if something _does not_ have that property - is that really a strike against it? Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE Draft Weil and Draft BDGKS
I'd like to thank Owen for explaning his point of view with such clarity and I'd like to concur with him by rephrasing in my own words (most of this has already been said by others thought). Taking the objections in order, again: 1. Allocation of a special-use /10 does not hasten the deployment of IPv6. It only extends the life of the IPv4 network. Indeed. This affirmation is entirely true IMHO. However the stone-cold reality is that IPv6 is not yet ready despite huge multi-years efforts by the community and many service providers (speaking by experience here). The huge IPv4-only installed base and the lack of IPv6 support by vendors can't be ignored wherever the blame is put. 2. If a special-use /10 is allocated, it will be used as additional RFC 1918 address space, despite a specific prohibition against such use stated by the draft. Of course. Mark has pointed it out already, we don't need the prohibition to be *enforced*, only to have it *written* in the document. If a provider's client complains of overlap, then the burden of renumbering is on him, not on the ISP or anybody else. 3. If a special-use /10 is allocated, it will encourage others to request still more special-use address space. I doubt others, whoever they are, will have 1) sufficient justification and 2) time to do so. 4. Some applications will break. These applications share the characteristic of assuming that an interface is globally reachable if it is numbered by an non-RFC 1918 address. To date, the only application that has been identified as breaking is 6to4, but others may be identified in the future. Applications will break anyway with squat space or multiple overlapping RFC1918 space. As Owen and others pointed out, at least with a known prefix it can be fixed in a consistent manner. CGN will happen and is already happening now because it's the only rational way to keep a service provider business running, whether one like it or not. Dedicated addressing space will only make this deployment cleaner than if it's done with squat space. In my very humble opinion, draft Weil is definitely the lesser of to evils here. Just as an example, what suspiciously looks like squat space can be seen now (*i47.154.0.0/16 ... 3561 701 9929 4808 4808 i). At least with a dedicated prefix it can be properly filtered and blackholed. These were my 2 (Canadian) cents. JF Tremblay Long time IPv6 enthusiast and Sr IPv6 Engineer at Videotron (The opinions contained here are my own and do not necessarily reflect the views of my $employer or any other affiliation) I strongly support both of these drafts. Allocation of the /10 will have only minimal negative impacts on the community, if any. Almost all of the impacts raised in the objections to draft weil will occur whether or not draft weil is moved to BCP status. The difference is that with draft weil in place, most of them can actually be mitigated whereas no such mitigation will be possible without draft weil. Delaying draft weil is, in this case, roughly equivalent to refusing it because operators are going to have to start implementing CGN and other IPv4 exhaustion coping mechanisms whether the IETF is ready or not. The objections listed in Ron's sending this to IESG ballot are: - Allocation of a special-use /10 does not hasten the deployment of IPv6. It only extends the life of the IPv4 network. - If a special-use /10 is allocated, it will be used as additional RFC 1918 address space, despite a specific prohibition against such use stated by the draft. - If a special-use /10 is allocated, it will encourage others to request still more special-use address space. - Some applications will break. These applications share the characteristic of assuming that an interface is globally reachable if it is numbered by an non-RFC 1918 address. To date, the only application that has been identified as breaking is 6to4, but others may be identified in the future. Taking each objection in order: - Allocation of a special-use /10 does not hasten the deployment of IPv6. It only extends the life of the IPv4 network. The first part of this statement is true. The second half is not an entirely accurate characterization. What this /10 will do is enable carriers and ISPs to provide services to end users in a consistent manner that vendors can adapt to. Absent this shared transition space, the uses for this space will not magically disappear and all of the problems described will still exist. The primary resulting difference will be that it will consume more global unicast addresses and create more potential for collision and other negative consequences while simultaneously removing all hope of allowing vendors to provide mitigation in software. I am one of the biggest IPv6 cheerleaders in the industry, but, I also have to work within the framework of operational reality. We're going to run out of IPv4 before everyone is ready, whether we
Re: Consensus Call: draft-weil-shared-transition-space-request
Draft-donley-nat444-impacts-03: +--++++--+--+ | Skype video | Pass | Pass | Pass | Pass | | | chat +--++++--+--+ We tested it. Skype worked in our lab through CGN. Chris On 11/30/11 7:21 AM, Ronald Bonica rbon...@juniper.net wrote: Folks, Can anyone present empirical evidence that skype will break? I have heard claims in both directions. Ron -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Mark Andrews Sent: Tuesday, November 29, 2011 11:50 PM To: Randy Bush Cc: IETF Disgust Subject: Re: Consensus Call: draft-weil-shared-transition-space-request In message m2sjl644h3.wl%ra...@psg.com, Randy Bush writes: anyone who thinks this will not be used as 1918 space should share what they are smoking. the question is not if, but rather how many milliseconds before it is. that is the operational reality. And what harm to others does that cause? If a ISP is using this and the customer is using this rather than RFC 1918 space then they only have themselves to blame for operational problems it causes. and we should have a betting pool on how long before it is leaked into a measure such as route-views. And users would be advised to filter routes for it the same as they should be filtering routes for other space they are using. and all this is aside from the pnp, skype, ... and other breakage. and, imiho, we can screw ipv4 life support. 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? this has become a contest of wills, not a technical discussion. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On Wed, Nov 30, 2011 at 12:18 PM, Chris Donley c.don...@cablelabs.comwrote: Draft-donley-nat444-impacts-03: +--++++--+--+ | Skype video | Pass | Pass | Pass | Pass | | | chat +--++++--+--+ It also works in a real production deployment in a real network. As I noted earlier. So oppose to claims that it does not work, I can let you know that it in fact works. regards, Victor K We tested it. Skype worked in our lab through CGN. Chris On 11/30/11 7:21 AM, Ronald Bonica rbon...@juniper.net wrote: Folks, Can anyone present empirical evidence that skype will break? I have heard claims in both directions. Ron -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Mark Andrews Sent: Tuesday, November 29, 2011 11:50 PM To: Randy Bush Cc: IETF Disgust Subject: Re: Consensus Call: draft-weil-shared-transition-space-request In message m2sjl644h3.wl%ra...@psg.com, Randy Bush writes: anyone who thinks this will not be used as 1918 space should share what they are smoking. the question is not if, but rather how many milliseconds before it is. that is the operational reality. And what harm to others does that cause? If a ISP is using this and the customer is using this rather than RFC 1918 space then they only have themselves to blame for operational problems it causes. and we should have a betting pool on how long before it is leaked into a measure such as route-views. And users would be advised to filter routes for it the same as they should be filtering routes for other space they are using. and all this is aside from the pnp, skype, ... and other breakage. and, imiho, we can screw ipv4 life support. 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? this has become a contest of wills, not a technical discussion. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On Nov 30, 2011, at 6:27 AM, Michael Richardson wrote: Randy == Randy Bush ra...@psg.com writes: 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? Randy cool. then, by that logic, let's use 240/4. the apps will Randy patch within a week. ok, maybe two. Seriously, I think we *SHOULD* use 240/10. (let's keep some for the next horrible hack) I agree, this is a good use of the Experimental Class E IPv4 addresses. It seems to me that this is for new deployments (the CDN gear and new customer CPE equipment). The operators who want this should be able to make this work and and incur the cost for doing so. Bob ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
Bob Hinden wrote: Michael Richardson wrote: Randy Bush ra...@psg.com writes: cool. then, by that logic, let's use 240/4. the apps will patch within a week. ok, maybe two. Seriously, I think we *SHOULD* use 240/10. (let's keep some for the next horrible hack) I agree, this is a good use of the Experimental Class E IPv4 addresses. It seems to me that this is for new deployments (the CDN gear and new customer CPE equipment). The operators who want this should be able to make this work and and incur the cost for doing so. How about 240/8 (more room than /10, easier to recognized for humans, but still addresses left for future hacks). -Martin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
Bob Hinden bob.hin...@gmail.com wrote: On Nov 30, 2011, at 6:27 AM, Michael Richardson wrote: Seriously, I think we *SHOULD* use 240/10. (let's keep some for the next horrible hack) I agree, this is a good use of the Experimental Class E IPv4 addresses. It seems to me that this is for new deployments (the CDN gear and new customer CPE equipment). The operators who want this should be able to make this work and and incur the cost for doing so. While I am neither for nor against allocation of a /10 from ordinary routable space, I would strongly favor allocation of a /10 from 240/4. It's not obvious to me from reading draft-weil why this wouldn't work; and I believe that allocations from 240/4 are quite appropriate, given the imminent exaustion of ordinary IPv4 space. -- John Leslie j...@jlc.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
but this proposal is not about migrating to ipv6. it is about ipv4 life extension and nat444 4ever. to hell with that. ipv6 deployment enthusiast If NAT444 gets deployed, then IPv4 will become progressively less reliable over time. As more people work on IPv6, IPv6 will become more reliable over time. Eventually, IPv6 will become more reliable than IPv4. At that point, I can tell my family that they should move to IPv6 - not because they've run out of addresses - but because they're fed up with an unreliable Internet connection. From a service provider perspective, adding NAT44 to the network comes at the cost of lighting up the call center. Eventually, the cost of the call center will become more expensive than deployment of IPv6... /ipv6 deployment enthusiast cgn developer This allows me to work with really complicated code that I can become an expert on that will have a constant stream of new work and will provide revenue for my company for years to come. /cgn developer See - all you need is a change in perspective... - Wes ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On Tue, Nov 29, 2011 at 17:00, Doug Barton do...@dougbarton.us wrote: On 11/29/2011 15:37, Chris Grundemann wrote: I support draft-weil-shared-transition-space-request and the allocation of a /10 as Shared CGN Space because we are approaching complete global exhaustion of unallocated IPv4 addresses and the value of globally unique addresses is becoming manifest. As others have pointed out, those ideas contradict one another. The fact that free addresses are so valuable is precisely why they shouldn't be taken away from new entrants to the market in order to benefit the grasshoppers who've fiddled away the summer. And yes, I realize that 1,024 /20s is just a drop in the bucket. But sometimes the principle of the thing IS the thing. It is more conservative to share a common pool. Network operators recognize the need to transition to IPv6 now more than ever. Again, no sympathy. They've had (by conservative estimates) 10 years. No sympathy for they (basically all residential ISPs on the planet) needed. The shared CGN space mitigates externalities that will likely be caused by every other alternative to a shared CGN space. However, the immediate necessity for IPv4 connectivity poses a near-term challenge which requires the deployment of address-sharing technologies. They created the crisis. Why is it our responsibility to fix it for them? See above. We are not fixing it for them. They will deploy CGN with or without us. We are giving them a way to do it in the least disruptive way. Cheers, ~Chris -- We could put the whole Internet into a book. Too practical. Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
At 11:38 30-11-2011, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'DKIM Authorized Third-Party Signers' draft-kucherawy-dkim-atps-11.txt as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-12-28. Exceptionally, comments may be In Section 2: Readers should be familiar with the material and terminology discussed in [MAIL] and [EMAIL-ARCH]. The references to RFC 5598 and RFC 5322 should be normative. In Section 3: An Author participates in this protocol if it wishes to announce that a message from it (in the RFC5322.From sense) should be considered authentic as long as it bears a signature from any in a set of specified domains. It's the domain and not the author which participates in this protocol. As a nit, the RFC 5598 term looks more like Originator instead of Author. The Abstract section uses the term authorization whereas authentic is used in the above text. Shouldn't that be considered as authorized? In Section 4.1: When the Signer generates a DKIM signature on behalf of an Author, it MUST include an atps tag in the signature and include as its value the Author's domain name. See above comment about originator. In Section 6: A Verifier implementing both ADSP and ATPS SHOULD treat a message for which the ATPS test described above passes as if it were signed by the author domain. That is, a pass of ATPS means a pass for ADSP. In plain English, this reads as an update of ADSP but this draft does not update RFC 5617. In Section 8: No actions are required by IANA at this time. The following need only be applied if and when this specification reaches the Standards Track. The IANA Considerations section is unusual. If no action is required at this time, the sub-sections are not needed. I suggest updating the DKIM-Signature Tag Specification Registry for the tags as they will appear on the Internet. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
Chris, On Nov 30, 2011, at 12:28 PM, Chris Grundemann wrote: They will deploy CGN with or without us. True. We are giving them a way to do it in the least disruptive way. Could you expand on the disruption you believe would be minimized by implementation of this draft? That is, what do you believe would happen if this draft is not accepted and the /10 allocation is not made? The draft doesn't spell this out explicitly (as far as I can tell) and I suspect much of the discussion revolves around different interpretations of the disruption. Thanks, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On 2011-12-01 09:28, Chris Grundemann wrote: ... It is more conservative to share a common pool. It suddenly occurs to me that I don't recall any serious analysis of using 172.16.0.0/12 for this. It is a large chunk of space (a million addresses) and as far as I know it is not used by default in any common CPE devices, which tend to use the other RFC 1918 blocks. I realise that ISPs with more than a million customers would have to re-use this space, whereas a /10 would only bring this problem above 4M customers, but at that scale there would be multiple CGN monsters anyway. Sorry to bring this up on the eve of the telechat. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
Subject: Re: Consensus Call: draft-weil-shared-transition-space-request Date: Wed, Nov 30, 2011 at 03:18:24PM -0500 Quoting Wes Beebee (wbee...@cisco.com): Eventually, IPv6 will become more reliable than IPv4. for me, v6 is more reliable at my two most frequented tethering points for the laptop. today. mostly because v6 is clean slate and 100% e2e. this is over tunneling to home. does not matter. the tunnel has lower latency than the v4 route to where I want to go. (wonders of peering wars) See - all you need is a change in perspective... or perhaps timetable. now -1 year was a good time to roll out v6. those who do not have v6 in their backbones today are lagging and will have to pay for it. early adopter pain was 10 years ago (line cards with v4 only feature sets and similar b0rkenendness.) access networks (especially dsl and cable) are a pathetic story in themselves wrt v6, but the backbone has been a breeze to v6-enable for years. peoples RFQen should have started _requiring_ v6 transit and feature parity for v6 and v4 at least two years ago. I did. it helps. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 SANTA CLAUS comes down a FIRE ESCAPE wearing bright blue LEG WARMERS ... He scrubs the POPE with a mild soap or detergent for 15 minutes, starring JANE FONDA!! signature.asc Description: Digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RE Draft Weil and Draft BDGKS
I echo Owen and JF's comments Given the available options, the dedicated /10 provides the least problematic solution. If the address space used by CGN is standardised, and identifiable then it can be managed appropriately by everyone in a consistent way. The sooner this is adopted, the easier it becomes to manage. Daryl On 30 November 2011 17:13, jean-francois.tremblay...@videotron.com wrote: I'd like to thank Owen for explaning his point of view with such clarity and I'd like to concur with him by rephrasing in my own words (most of this has already been said by others thought). Taking the objections in order, again: 1. Allocation of a special-use /10 does not hasten the deployment of IPv6. It only extends the life of the IPv4 network. Indeed. This affirmation is entirely true IMHO. However the stone-cold reality is that IPv6 is not yet ready despite huge multi-years efforts by the community and many service providers (speaking by experience here). The huge IPv4-only installed base and the lack of IPv6 support by vendors can't be ignored wherever the blame is put. 2. If a special-use /10 is allocated, it will be used as additional RFC 1918 address space, despite a specific prohibition against such use stated by the draft. Of course. Mark has pointed it out already, we don't need the prohibition to be *enforced*, only to have it *written* in the document. If a provider's client complains of overlap, then the burden of renumbering is on him, not on the ISP or anybody else. 3. If a special-use /10 is allocated, it will encourage others to request still more special-use address space. I doubt others, whoever they are, will have 1) sufficient justification and 2) time to do so. 4. Some applications will break. These applications share the characteristic of assuming that an interface is globally reachable if it is numbered by an non-RFC 1918 address. To date, the only application that has been identified as breaking is 6to4, but others may be identified in the future. Applications will break anyway with squat space or multiple overlapping RFC1918 space. As Owen and others pointed out, at least with a known prefix it can be fixed in a consistent manner. CGN will happen and is already happening now because it's the only rational way to keep a service provider business running, whether one like it or not. Dedicated addressing space will only make this deployment cleaner than if it's done with squat space. In my very humble opinion, draft Weil is definitely the lesser of to evils here. Just as an example, what suspiciously looks like squat space can be seen now (*i47.154.0.0/16 ... 3561 701 9929 4808 4808 i). At least with a dedicated prefix it can be properly filtered and blackholed. These were my 2 (Canadian) cents. JF Tremblay Long time IPv6 enthusiast and Sr IPv6 Engineer at Videotron (The opinions contained here are my own and do not necessarily reflect the views of my $employer or any other affiliation) I strongly support both of these drafts. Allocation of the /10 will have only minimal negative impacts on the community, if any. Almost all of the impacts raised in the objections to draft weil will occur whether or not draft weil is moved to BCP status. The difference is that with draft weil in place, most of them can actually be mitigated whereas no such mitigation will be possible without draft weil. Delaying draft weil is, in this case, roughly equivalent to refusing it because operators are going to have to start implementing CGN and other IPv4 exhaustion coping mechanisms whether the IETF is ready or not. The objections listed in Ron's sending this to IESG ballot are: - Allocation of a special-use /10 does not hasten the deployment of IPv6. It only extends the life of the IPv4 network. - If a special-use /10 is allocated, it will be used as additional RFC 1918 address space, despite a specific prohibition against such use stated by the draft. - If a special-use /10 is allocated, it will encourage others to request still more special-use address space. - Some applications will break. These applications share the characteristic of assuming that an interface is globally reachable if it is numbered by an non-RFC 1918 address. To date, the only application that has been identified as breaking is 6to4, but others may be identified in the future. Taking each objection in order: - Allocation of a special-use /10 does not hasten the deployment of IPv6. It only extends the life of the IPv4 network. The first part of this statement is true. The second half is not an entirely accurate characterization. What this /10 will do is enable carriers and ISPs to provide services to end users in a consistent manner that vendors can adapt to. Absent this shared transition space, the uses for this space will not magically disappear and all of the problems described will still exist. The primary resulting
Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
Readers should be familiar with the material and terminology discussed in [MAIL] and [EMAIL-ARCH]. The references to RFC 5598 and RFC 5322 should be normative. I agree; I missed that in my shepherd review. So sorry. A Verifier implementing both ADSP and ATPS SHOULD treat a message for which the ATPS test described above passes as if it were signed by the author domain. That is, a pass of ATPS means a pass for ADSP. In plain English, this reads as an update of ADSP but this draft does not update RFC 5617. It does not. There's no reason that anyone implementing ADSP need pay attention to this. *IF* you implement this, it might change your behaviour with respect to ADSP, but information about that is contained here. There's no reason for this to update 5617 in the IETF sense. The IANA Considerations section is unusual. If no action is required at this time, the sub-sections are not needed. I did call this out in my shepherd review (see the PROTO writeup: https://datatracker.ietf.org/doc/draft-kucherawy-dkim-atps/history/ and click show all on the PROTO writeup entry; side point: it should probably be easier to get to the PROTO writeup for a document). I actually think it's clever to put the information here in this manner, but, as I say in the writeup, it is unusual. I prefer that we leave it here, and just make sure that the intelligent folks at IANA do the intelligent thing. This can then serve as a template for the IANA Considerations section for a possible revision that moves ATPS to Standards Track, should that happen. Barry, document shepherd ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
It's not just about the CPE devices and customer LANs. Address conflicts are also going to happen within the ISP network / back-office etc. 172.16.0.0/12 is used there. Daryl On 30 November 2011 20:52, Brian E Carpenter brian.e.carpen...@gmail.comwrote: On 2011-12-01 09:28, Chris Grundemann wrote: ... It is more conservative to share a common pool. It suddenly occurs to me that I don't recall any serious analysis of using 172.16.0.0/12 for this. It is a large chunk of space (a million addresses) and as far as I know it is not used by default in any common CPE devices, which tend to use the other RFC 1918 blocks. I realise that ISPs with more than a million customers would have to re-use this space, whereas a /10 would only bring this problem above 4M customers, but at that scale there would be multiple CGN monsters anyway. Sorry to bring this up on the eve of the telechat. Brian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
Hi Barry, At 13:03 30-11-2011, Barry Leiba wrote: It does not. There's no reason that anyone implementing ADSP need pay attention to this. *IF* you implement this, it might change your behaviour with respect to ADSP, but information about that is contained here. There's no reason for this to update 5617 in the IETF sense. Ok. I did call this out in my shepherd review (see the PROTO writeup: https://datatracker.ietf.org/doc/draft-kucherawy-dkim-atps/history/ and click show all on the PROTO writeup entry; side point: it should probably be easier to get to the PROTO writeup for a document). I missed that. I actually think it's clever to put the information here in this manner, but, as I say in the writeup, it is unusual. I prefer that we leave it here, and just make sure that the intelligent folks at IANA do the intelligent thing. This can then serve as a template for the IANA Considerations section for a possible revision that moves ATPS to Standards Track, should that happen. Agreed. I support publication of the draft as Experimental. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
Hi, SM. Thanks for your comments. In reply to the stuff Barry hasn't already covered: -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of SM Sent: Wednesday, November 30, 2011 12:35 PM To: ietf@ietf.org Subject: Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC In Section 3: An Author participates in this protocol if it wishes to announce that a message from it (in the RFC5322.From sense) should be considered authentic as long as it bears a signature from any in a set of specified domains. It's the domain and not the author which participates in this protocol. As a nit, the RFC 5598 term looks more like Originator instead of Author. The term is more based on how DKIM and ADSP use it. But you're right in that Author Domain is the more correct term rather than Author. I'll change that for -12. The Abstract section uses the term authorization whereas authentic is used in the above text. Shouldn't that be considered as authorized? Yes, I think that's more correct as well. -MSK ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Wednesday, November 30, 2011 2:21 PM To: ietf@ietf.org Subject: RE: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC It's the domain and not the author which participates in this protocol. As a nit, the RFC 5598 term looks more like Originator instead of Author. The term is more based on how DKIM and ADSP use it. But you're right in that Author Domain is the more correct term rather than Author. I'll change that for -12. Actually ADMD from RFC5598 seems to be a good fit, so I'll use that. Thanks again! -MSK ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Secdir review of draft-ietf-dime-priority-avps-05
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This standards track document defines Diameter AVPs that can be used to convey a variety of priority parameters. In July 2011, I conducted a secdir review of a previous revision of this document (-04) and found that the Security Considerations section was inadequate because it did not include any analysis of the specific security issues related to priority systems. I'm pleased to say that the authors have attempted to address this issue in their new draft. They added a reference to the Security Considerations section of RFC 5866, which is thorough and sound. In addition, they explicitly identify one threat: unauthorized changes to QoS parameters in transit. However, the countermeasure proposed is confusing. The document now says integrity protected values SHOULD be ignored. I would expect the reverse. Values that are not integrity protected SHOULD be ignored. Am I wrong? I'm concerned that the other threats described in RFC 5866 are not addressed in this document. Lack of authentication and confidentiality protection for QoS parameters can have serious negative impacts, as described in RFC 5866. In the IETF spirit of send text, I suggest the following paragraph be added to the Security Considerations section of this draft: As described in [RFC5866], failure to provide adequate authentication and confidentiality protection for QoS parameters may result in serious failures that undermine the very purpose of QoS. Countermeasures such as Diameter communication security should be employed as appropriate. I will supply a further optional suggestion to clarify the text recently added regarding integrity. I recommend that the first paragraph of the Security Considerations section be stripped to just its first sentence and that the following paragraph be used in place of the new text that was added at the end of that paragraph: The values in the AVPs defined in this draft are not supposed to be changed by any of the Diameter servers or any other intermediaries. In fact, changes to these AVPs in transit could result in serious problems such as inability to complete high-priority emergency phone calls. Therefore, source integrity protection SHOULD be employed for those AVPs (e.g., the use of S/MIME with the SIP RPH, or an INTEGRITY object within a POLICY_DATA object). The text that I wrote may well be incorrect or misguided. I'm just trying to provide helpful suggestions from a security perspective. If the authors would like to have a further chat about this topic, I'd be glad to do so. And if they want to keep the text that they added on integrity protection, that's OK. I just found it a bit lacking in describing the threat and its consequences and in providing an effective countermeasure. Thanks, Steve ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Netfilter (Linux) Does IPv6 NAT
In case you didn't see this: http://www.h-online.com/open/news/item/Netfilter-developers-working-on-NAT-for-ip6tables-1385877.html It's a complete IPv6 NAT implementation with the functionality of the IPv4 one in the same stack. ALGs. Port translation. Connection tracking. You don't need me to tell you why I don't like this. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Netfilter (Linux) Does IPv6 NAT
Does it support RFC 6296? Regards Brian Carpenter On 2011-12-01 13:07, Sabahattin Gucukoglu wrote: In case you didn't see this: http://www.h-online.com/open/news/item/Netfilter-developers-working-on-NAT-for-ip6tables-1385877.html It's a complete IPv6 NAT implementation with the functionality of the IPv4 one in the same stack. ALGs. Port translation. Connection tracking. You don't need me to tell you why I don't like this. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
I'm one of the authors of RFC 5617, which this document would update if it moved into the standards track. It doesn't seem very useful to me, but it also seems mostly harmless so there's no reason not to publish it as experimental. This strikes me a hack that appeals primarily to bulk mail senders who grossly overestimate how interested receivers are in helping them do their mail management. So I would be surprised if there were many receiver-side implementations, but it's an experiment so what the heck. No actions are required by IANA at this time. The following need only be applied if and when this specification reaches the Standards Track. I would strongly suggest changing the IANA section so that the DKIM-Signature tags in section 8.4 are registered when this is published. Tags are text strings, and I'd rather the tags it uses be noted and reserved so that nobody uses them for something else in the future and risks collisions. For the same reason, it'd probably be a good idea to register the authentication-results tags described in sections 8.2 and 8.3. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Please consider the environment before reading this e-mail. http://jl.ly ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Netfilter (Linux) Does IPv6 NAT
On 1 Dec 2011, at 01:20, Brian E Carpenter wrote: Does it support RFC 6296? That was done in a separate, non-official implementation here: http://lwn.net/Articles/451914/ With this one, you can NAT between ranges, and that's it, if I've got this right. Fragmentation is also an issue. I'm not a netfilter expert, though, so I can't say whether it's possible to implement RFC6296 with it. The checksum difference calculation is obviously going to pose a problem. Cheers, Sabahattin ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
Daryl, The problem described in the draft is that CPEs use 1918 space *and that many of them can't deal with the fact that there might be addresses on the outside interface that are the same as on the inside interface*. The claim was made by Randy, among others, that only 192.168/16 space was used by such unintelligent CPEs. I believe I have seen the claim that 10/8 space is also used in unintelligent equipment that can't deal with identical addresses inside and outside. Is there reason to believe that within the ISP network / back-office etc. that there is equipment that can't deal with 17.16/12 space being on both the inside and outside? I haven't seen anyone make that specific claim. If we know that 172.16/12 used both inside and outside will break a significant amount of sites that CGNs will be used with, we can ignore this argument. But if not, then let's rewrite the document to say that CGNs should use 172.16/12 and that any device that wants to use 172.16/12 needs the ability to deal with identical addresses on the inside and the outside interface. Of course, all equipment should have always been able to deal with identical addresses inside and outside for all 1918 addresses anyway. But if we think the impact of using 172.16/12 for this purpose will cause minimal harm, then there's no compelling reason to allocate new space for this purpose. pr On 11/30/11 3:04 PM, Daryl Tanner wrote: It's not just about the CPE devices and customer LANs. Address conflicts are also going to happen within the ISP network / back-office etc. 172.16.0.0/12 http://172.16.0.0/12 is used there. Daryl On 30 November 2011 20:52, Brian E Carpenter brian.e.carpen...@gmail.com mailto:brian.e.carpen...@gmail.com wrote: On 2011-12-01 09:28, Chris Grundemann wrote: ... It is more conservative to share a common pool. It suddenly occurs to me that I don't recall any serious analysis of using 172.16.0.0/12 http://172.16.0.0/12 for this. It is a large chunk of space (a million addresses) and as far as I know it is not used by default in any common CPE devices, which tend to use the other RFC 1918 blocks. I realise that ISPs with more than a million customers would have to re-use this space, whereas a /10 would only bring this problem above 4M customers, but at that scale there would be multiple CGN monsters anyway. Sorry to bring this up on the eve of the telechat. -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On Nov 30, 2011, at 9:14 PM 11/30/11, Pete Resnick wrote: Daryl, The problem described in the draft is that CPEs use 1918 space *and that many of them can't deal with the fact that there might be addresses on the outside interface that are the same as on the inside interface*. The claim was made by Randy, among others, that only 192.168/16 space was used by such unintelligent CPEs. I believe I have seen the claim that 10/8 space is also used in unintelligent equipment that can't deal with identical addresses inside and outside. Another suggestion was the use of 10.64.0.0/10, with the argument that some devices may use 10.0.0.0 but those devices tend to start numbering with 10.0.0.0/24 or 10.0.1.0/24 and none would use addresses in 10.64.0.0/10. Is there evidence that there are deployments today of devices that use addresses in 10.64.0.0/10? - Ralph Is there reason to believe that within the ISP network / back-office etc. that there is equipment that can't deal with 17.16/12 space being on both the inside and outside? I haven't seen anyone make that specific claim. If we know that 172.16/12 used both inside and outside will break a significant amount of sites that CGNs will be used with, we can ignore this argument. But if not, then let's rewrite the document to say that CGNs should use 172.16/12 and that any device that wants to use 172.16/12 needs the ability to deal with identical addresses on the inside and the outside interface. Of course, all equipment should have always been able to deal with identical addresses inside and outside for all 1918 addresses anyway. But if we think the impact of using 172.16/12 for this purpose will cause minimal harm, then there's no compelling reason to allocate new space for this purpose. pr On 11/30/11 3:04 PM, Daryl Tanner wrote: It's not just about the CPE devices and customer LANs. Address conflicts are also going to happen within the ISP network / back-office etc. 172.16.0.0/12 is used there. Daryl On 30 November 2011 20:52, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 2011-12-01 09:28, Chris Grundemann wrote: ... It is more conservative to share a common pool. It suddenly occurs to me that I don't recall any serious analysis of using 172.16.0.0/12 for this. It is a large chunk of space (a million addresses) and as far as I know it is not used by default in any common CPE devices, which tend to use the other RFC 1918 blocks. I realise that ISPs with more than a million customers would have to re-use this space, whereas a /10 would only bring this problem above 4M customers, but at that scale there would be multiple CGN monsters anyway. Sorry to bring this up on the eve of the telechat. -- Pete Resnick http://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
Ralph, Please note the following report: WIDE Technical-Report in 2010 (DOC wide-tr-kato-as112-rep-01.pdf) Report suggested that all three RFC1918 blocks are well utilized. Regards, Victor K On 11-11-30 9:19 PM, Ralph Droms rdroms.i...@gmail.com wrote: On Nov 30, 2011, at 9:14 PM 11/30/11, Pete Resnick wrote: Daryl, The problem described in the draft is that CPEs use 1918 space *and that many of them can't deal with the fact that there might be addresses on the outside interface that are the same as on the inside interface*. The claim was made by Randy, among others, that only 192.168/16 space was used by such unintelligent CPEs. I believe I have seen the claim that 10/8 space is also used in unintelligent equipment that can't deal with identical addresses inside and outside. Another suggestion was the use of 10.64.0.0/10, with the argument that some devices may use 10.0.0.0 but those devices tend to start numbering with 10.0.0.0/24 or 10.0.1.0/24 and none would use addresses in 10.64.0.0/10. Is there evidence that there are deployments today of devices that use addresses in 10.64.0.0/10? - Ralph Is there reason to believe that within the ISP network / back-office etc. that there is equipment that can't deal with 17.16/12 space being on both the inside and outside? I haven't seen anyone make that specific claim. If we know that 172.16/12 used both inside and outside will break a significant amount of sites that CGNs will be used with, we can ignore this argument. But if not, then let's rewrite the document to say that CGNs should use 172.16/12 and that any device that wants to use 172.16/12 needs the ability to deal with identical addresses on the inside and the outside interface. Of course, all equipment should have always been able to deal with identical addresses inside and outside for all 1918 addresses anyway. But if we think the impact of using 172.16/12 for this purpose will cause minimal harm, then there's no compelling reason to allocate new space for this purpose. pr On 11/30/11 3:04 PM, Daryl Tanner wrote: It's not just about the CPE devices and customer LANs. Address conflicts are also going to happen within the ISP network / back-office etc. 172.16.0.0/12 is used there. Daryl On 30 November 2011 20:52, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 2011-12-01 09:28, Chris Grundemann wrote: ... It is more conservative to share a common pool. It suddenly occurs to me that I don't recall any serious analysis of using 172.16.0.0/12 for this. It is a large chunk of space (a million addresses) and as far as I know it is not used by default in any common CPE devices, which tend to use the other RFC 1918 blocks. I realise that ISPs with more than a million customers would have to re-use this space, whereas a /10 would only bring this problem above 4M customers, but at that scale there would be multiple CGN monsters anyway. Sorry to bring this up on the eve of the telechat. -- Pete Resnick http://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On 11/30/11 8:41 PM, Victor Kuarsingh wrote: Ralph, Please note the following report: WIDE Technical-Report in 2010 (DOC wide-tr-kato-as112-rep-01.pdf) Report suggested that all three RFC1918 blocks are well utilized. Well utilized in devices that can't deal with identical addresses on the inside and outside interfaces? That's the only question that counts. pr On 11-11-30 9:19 PM, Ralph Dromsrdroms.i...@gmail.com wrote: On Nov 30, 2011, at 9:14 PM 11/30/11, Pete Resnick wrote: Daryl, The problem described in the draft is that CPEs use 1918 space *and that many of them can't deal with the fact that there might be addresses on the outside interface that are the same as on the inside interface*. The claim was made by Randy, among others, that only 192.168/16 space was used by such unintelligent CPEs. I believe I have seen the claim that 10/8 space is also used in unintelligent equipment that can't deal with identical addresses inside and outside. Another suggestion was the use of 10.64.0.0/10, with the argument that some devices may use 10.0.0.0 but those devices tend to start numbering with 10.0.0.0/24 or 10.0.1.0/24 and none would use addresses in 10.64.0.0/10. Is there evidence that there are deployments today of devices that use addresses in 10.64.0.0/10? - Ralph Is there reason to believe that within the ISP network / back-office etc. that there is equipment that can't deal with 17.16/12 space being on both the inside and outside? I haven't seen anyone make that specific claim. If we know that 172.16/12 used both inside and outside will break a significant amount of sites that CGNs will be used with, we can ignore this argument. But if not, then let's rewrite the document to say that CGNs should use 172.16/12 and that any device that wants to use 172.16/12 needs the ability to deal with identical addresses on the inside and the outside interface. Of course, all equipment should have always been able to deal with identical addresses inside and outside for all 1918 addresses anyway. But if we think the impact of using 172.16/12 for this purpose will cause minimal harm, then there's no compelling reason to allocate new space for this purpose. pr On 11/30/11 3:04 PM, Daryl Tanner wrote: It's not just about the CPE devices and customer LANs. Address conflicts are also going to happen within the ISP network / back-office etc. 172.16.0.0/12 is used there. Daryl On 30 November 2011 20:52, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 2011-12-01 09:28, Chris Grundemann wrote: ... It is more conservative to share a common pool. It suddenly occurs to me that I don't recall any serious analysis of using 172.16.0.0/12 for this. It is a large chunk of space (a million addresses) and as far as I know it is not used by default in any common CPE devices, which tend to use the other RFC 1918 blocks. I realise that ISPs with more than a million customers would have to re-use this space, whereas a /10 would only bring this problem above 4M customers, but at that scale there would be multiple CGN monsters anyway. Sorry to bring this up on the eve of the telechat. -- Pete Resnick http://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On Nov 30, 2011, at 9:41 PM 11/30/11, Victor Kuarsingh wrote: Ralph, Please note the following report: WIDE Technical-Report in 2010 (DOC wide-tr-kato-as112-rep-01.pdf) Thanks for the reference. Do you have an easy pointer to retrieve the doc? I'm curious about how the data was gathered and what conclusions are drawn. - Ralph Report suggested that all three RFC1918 blocks are well utilized. Regards, Victor K On 11-11-30 9:19 PM, Ralph Droms rdroms.i...@gmail.com wrote: On Nov 30, 2011, at 9:14 PM 11/30/11, Pete Resnick wrote: Daryl, The problem described in the draft is that CPEs use 1918 space *and that many of them can't deal with the fact that there might be addresses on the outside interface that are the same as on the inside interface*. The claim was made by Randy, among others, that only 192.168/16 space was used by such unintelligent CPEs. I believe I have seen the claim that 10/8 space is also used in unintelligent equipment that can't deal with identical addresses inside and outside. Another suggestion was the use of 10.64.0.0/10, with the argument that some devices may use 10.0.0.0 but those devices tend to start numbering with 10.0.0.0/24 or 10.0.1.0/24 and none would use addresses in 10.64.0.0/10. Is there evidence that there are deployments today of devices that use addresses in 10.64.0.0/10? - Ralph Is there reason to believe that within the ISP network / back-office etc. that there is equipment that can't deal with 17.16/12 space being on both the inside and outside? I haven't seen anyone make that specific claim. If we know that 172.16/12 used both inside and outside will break a significant amount of sites that CGNs will be used with, we can ignore this argument. But if not, then let's rewrite the document to say that CGNs should use 172.16/12 and that any device that wants to use 172.16/12 needs the ability to deal with identical addresses on the inside and the outside interface. Of course, all equipment should have always been able to deal with identical addresses inside and outside for all 1918 addresses anyway. But if we think the impact of using 172.16/12 for this purpose will cause minimal harm, then there's no compelling reason to allocate new space for this purpose. pr On 11/30/11 3:04 PM, Daryl Tanner wrote: It's not just about the CPE devices and customer LANs. Address conflicts are also going to happen within the ISP network / back-office etc. 172.16.0.0/12 is used there. Daryl On 30 November 2011 20:52, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 2011-12-01 09:28, Chris Grundemann wrote: ... It is more conservative to share a common pool. It suddenly occurs to me that I don't recall any serious analysis of using 172.16.0.0/12 for this. It is a large chunk of space (a million addresses) and as far as I know it is not used by default in any common CPE devices, which tend to use the other RFC 1918 blocks. I realise that ISPs with more than a million customers would have to re-use this space, whereas a /10 would only bring this problem above 4M customers, but at that scale there would be multiple CGN monsters anyway. Sorry to bring this up on the eve of the telechat. -- Pete Resnick http://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On Wed, Nov 30, 2011 at 6:57 PM, Ralph Droms rdroms.i...@gmail.com wrote: On Nov 30, 2011, at 9:41 PM 11/30/11, Victor Kuarsingh wrote: Ralph, Please note the following report: WIDE Technical-Report in 2010 (DOC wide-tr-kato-as112-rep-01.pdf) Thanks for the reference. Do you have an easy pointer to retrieve the doc? I'm curious about how the data was gathered and what conclusions are drawn. - Ralph http://member.wide.ad.jp/tr/wide-tr-kato-as112-rep-01.pdf I don't find this document to be very convincing that residential services cannot be well served by 10.64.0.0/10. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of John Levine Sent: Wednesday, November 30, 2011 6:04 PM To: ietf@ietf.org Subject: Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC I'm one of the authors of RFC 5617, which this document would update if it moved into the standards track. It doesn't seem very useful to me, but it also seems mostly harmless so there's no reason not to publish it as experimental. This strikes me a hack that appeals primarily to bulk mail senders who grossly overestimate how interested receivers are in helping them do their mail management. So I would be surprised if there were many receiver-side implementations, but it's an experiment so what the heck. As the draft says, the point is to make the idea available and see if it sticks to anyone or anything. If the bulk senders (or receivers) do decide they collectively want this, there's something for them to try and report back. No actions are required by IANA at this time. The following need only be applied if and when this specification reaches the Standards Track. I would strongly suggest changing the IANA section so that the DKIM- Signature tags in section 8.4 are registered when this is published. Tags are text strings, and I'd rather the tags it uses be noted and reserved so that nobody uses them for something else in the future and risks collisions. For the same reason, it'd probably be a good idea to register the authentication-results tags described in sections 8.2 and 8.3. I'd be fine with that, so long as experimental-status drafts are allowed to make IANA registrations. (I thought they weren't, which is why it is the way it is right now.) Thanks, -MSK ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
The problem described in the draft is that CPEs use 1918 space *and that many of them can't deal with the fact that there might be addresses on the outside interface that are the same as on the inside interface*. The claim was made by Randy, among others, that only 192.168/16 space was used by such unintelligent CPEs. i never made any such, or similar, claim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On 12/1/11 12:48 AM, Randy Bush wrote: The problem described in the draft is that CPEs use 1918 space *and that many of them can't deal with the fact that there might be addresses on the outside interface that are the same as on the inside interface*. The claim was made by Randy, among others, that only 192.168/16 space was used by such unintelligent CPEs. i never made any such, or similar, claim Damn. It was Robert Elz I was thinking of. (See his 30-Nov 17:19 +0700 message.) I apologize to you both for the confusion. pr -- Pete Resnickhttp://www.qualcomm.com/~presnick/ Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
On 11/30/2011 8:09 PM, Murray S. Kucherawy wrote: As the draft says, the point is to make the idea available and see if it sticks to anyone or anything. If the bulk senders (or receivers) do decide they collectively want this, there's something for them to try and report back. if one thinks the mechanism is a bad idea, it's still worth having a good document to describe it.l I'd be fine with that, so long as experimental-status drafts are allowed to make IANA registrations. (I thought they weren't, which is why it is the way it is right now.) depends on the criteria for the registry. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC
-Original Message- From: Dave CROCKER [mailto:d...@dcrocker.net] Sent: Wednesday, November 30, 2011 11:16 PM To: Murray S. Kucherawy Cc: ietf@ietf.org Subject: Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized Third-Party Signers) to Experimental RFC I'd be fine with that, so long as experimental-status drafts are allowed to make IANA registrations. (I thought they weren't, which is why it is the way it is right now.) depends on the criteria for the registry. So it does, and the registry for DKIM signature tags is IETF Consensus, which doesn't require standards track documents to update. So I guess the registrations could indeed be made here. Neat. It's a short walk from the current wording to actually requesting the IANA action. I'll check with my shepherd and sponsoring AD for advice prior to the end of LC. Thanks, -MSK ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Protocol Action: 'Using MAC-authenticated Encryption in the Cryptographic Message Syntax (CMS)' to Proposed Standard (draft-gutmann-cms-hmac-enc-06.txt)
The IESG has approved the following document: - 'Using MAC-authenticated Encryption in the Cryptographic Message Syntax (CMS)' (draft-gutmann-cms-hmac-enc-06.txt) as a Proposed Standard This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Sean Turner. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-gutmann-cms-hmac-enc/ Technical Summary This document specifies the conventions for using MAC-authenticated encryption with the Cryptographic Message Syntax (CMS) authenticated- enveloped-data content type. This mirrors the use of a MAC combined with an encryption algorithm that's already employed in IPsec, SSL/ TLS, and SSH, which is widely supported in existing crypto libraries and hardware, and has been extensively analysed by the crypto community. Working Group Summary This document was discussed in the S/MIME WG list. It's just a new algorithm for an existing standards-track S/MIME mechanism, so there wasn't any controversy over anything. Document Quality There's an existing implementation that's been deployed for about a year, and two more that have indicated they're implementing it (I'd have to check the current status, since I don't want to say X has comitted to put it in their next release on their behalf). Personnel Peter Gutmann is the Document Shepherd. Sean Turner is the Responsible AD. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
