Re: RE: Stupid NAT tricks and how to stop them.
Lars-Erik, From: Michel Py [mailto:[EMAIL PROTECTED] Unfortunately some protocol purity zealots still have to realize that Linksys, Netgear, Belkin and consorts don't sell NAT boxes because they think NAT is good, they sell NAT boxes because consumers want to buy them. I do not think consumers in general want to buy NAT boxes, but they are forced to do so by ISP's who do not give them a choice. We're over-analyzing things. The last 3 WLAN APs I bought had NAT on by default; 2 of them it was impossible to turn this off. I got into long discussions with tech support who were telling me it is impossible to design a WLAN AP-router combo that didn't NAT. My DSL provier offers me 5 DHCP address for free (consumer grade connection) and my mobile carrier is now using real IP address for GPRS (they had too many problems caused by NATed IP addresses). In practice, I've needed to power-cycle these NAT boxes every few weeks, to clear out the garbage. The most common things most ISP tech support lines are unplug your router/AP/box, count to 60 and plug it back in. However, if I am just a normal user, go to Best Buy and pickup a home WLAN Access Point, I'll have a NAT by default. There is no NAT inside logo on the box, nor are there clear instructions on how to turn this off. Vendors have turned NAT on by default because it is easier for them; not because the market has asked them to. As for reference, my local paper started, computer stores started advertising NAT firewalls around 1998-99. When NATs first came to a the market, the marketing message was that NATs provided a security feature. Still, I have far too many tech support discussions where there is common confusion between NAT firewall features. I don't think it is really intellectually honest to say the market has chosen NATs because it is what they wanted - it is a band-aid fix for a couple of different problems, which it kind of solved, but creates some ugly side effects. To get around these side effects, people are deploying ALRs, B2BUA and SBCs to help fix the side-effects (and to do other things). Human nature being what it is, we'll probably keep applying these quick fixes, until it gets far to messy and someone comes in and wipes these away with a new solution. Circuit switching, ATM, ISDN, etc. all have been useful for some solutions - but when you try to go beyond what they have been designed for, you tend to have to apply patches and hacks to get things working. John ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Copyright status of early RFCs
Henning Schulzrinne wrote: However, it seems that rather than having each individual chase after authors, at least one of whom is unfortunately no longer with us, wouldn't it make sense to have the Trust sent a release form to the authors so that they can grant retroactive permission equivalent to the modern RFCs? This would put action behind the desire. In the IPR WG meeting, Lucy Lynch said, on behalf of the trust: Lucy Lynch: We plan to solicit donations to the Trust, including donations from early authors and things like the video assets from the mbone broadcasts. We can not say “we unilaterally own them, give them to us”. I guess she'd be happy to get offers to help. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reality (was RE: Stupid NAT tricks and how to stop them.)
On 11-apr-2006, at 4:39, Anthony G. Atkielski wrote: It is worth about the same as a postal address that comes naturally when they build a new house. In a similar way when a new device comes to existence it gets an address out of infinite universe of 0 and 1. Maybe in some part of the universe addresses are infinite, but in the part where I live it's mostly 32 bits. That would only be true if IP addresses were geographically assigned, which they aren't. You know, you could assign IPv6 addresses in a strictly geographic way and you'd have more than enough for everyone, everywhere, with very simple routing. But of course that won't be done. No, routing would be more complex. Routing is the art and science of getting to a place, which is a lot harder than simply knowing where a place is. However, geographic addressing could give us aggregation with provider independece. If you examine European routes in the routing table of a router on the American west coast, you'll see that the vast majority of those routes point towards the same next hop. So if you could express an aggregate that encompasses all those routes and point that aggregate towards that next hop, you could filter out all those specific routes and the routing table in that one router would be a lot smaller. At each hop the number of routes that have a different next hop than the aggregate increases, until at some point the aggregate doesn't serve a useful purpose anymore. But by then you're in Europe or at least on the American east coast, where you can heavily aggregate Asia. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
John Loughney wrote: Lars-Erik, From: Michel Py [mailto:[EMAIL PROTECTED] Unfortunately some protocol purity zealots still have to realize that Linksys, Netgear, Belkin and consorts don't sell NAT boxes because they think NAT is good, they sell NAT boxes because consumers want to buy them. I do not think consumers in general want to buy NAT boxes, but they are forced to do so by ISP's who do not give them a choice. We're over-analyzing things. The last 3 WLAN APs I bought had NAT on by default; 2 of them it was impossible to turn this off. I got into long discussions with tech support who were telling me it is impossible to design a WLAN AP-router combo that didn't NAT. Just for curiousity: The TI chipset AR7 is the core of a couple of boxes. The all run linux and you can telnet them. They can route. No need for NAT My box is an Eumex 300 IP from t-online.de It is the same as the Fritzbox from AVM. Netgear, Siemens, Linksys and D-link produce similar boxes. I remember some people at RIPE loudly thinking about writing their own software for the Netgear or the Linksys. My DSL provier offers me 5 DHCP address for free (consumer grade connection) and my mobile carrier is now using real IP address for GPRS (they had too many problems caused by NATed IP addresses). DHCP is almost as bad as NAT is. Best get an aDSL-modem, if you are connected by aDSL then distribute the line via a switch and let your five coputers to the PPPoE stuff. So your computers are the DHCP clients and can dyndns or whatever. In practice, I've needed to power-cycle these NAT boxes every few weeks, to clear out the garbage. The most common things most ISP tech support lines are unplug your router/AP/box, count to 60 and plug it back in. I have had that same power-cycle problems with a GrandStrem ATA for my VoIP. My ISP dtag.de or t-online.de forces a disconnect every 24 hours. Sometimes they dont disconnect very cleanly and the Grandstream breaks. Best forget GrandStream. It breaks ICMP and it has problems with ssh and telnet passing through. Problably it does not get MTU correctly from people living behind tunnels. Their support never cared to answer. A Siemens router is now connected for half a yaer without any power-cycles. I guess the box is one of those AR7 linux boxes. My eumex too did not show any problems except for nagging about undisciplined disconnects form my ISP. However, if I am just a normal user, go to Best Buy and pickup a home WLAN Access Point, I'll have a NAT by default. There is no NAT inside logo on the box, nor are there clear instructions on how to turn this off. Vendors have turned NAT on by default because it is easier for them; not because the market has asked them to. I guess if you are a normal user then you are a loser anyhow. Those people normally have open windows and they dont know how to close them :) Putting those people behind triple NAT would not only save their harddisk some viruses but it would save our bandwidth too - keeping them from p2p each other :) As for reference, my local paper started, computer stores started advertising NAT firewalls around 1998-99. When NATs first came to a the market, the marketing message was that NATs provided a security feature. Still, I have far too many tech support discussions where there is common confusion between NAT firewall features. I don't think it is really intellectually honest to say the market has chosen NATs because it is what they wanted - it is a band-aid fix for a couple of different problems, which it kind of solved, but creates some ugly side effects. To get around these side effects, people are deploying ALRs, B2BUA and SBCs to help fix the side-effects (and to do other things). Human nature being what it is, we'll probably keep applying these quick fixes, until it gets far to messy and someone comes in and wipes these away with a new solution. Circuit switching, ATM, ISDN, etc. all have been useful for some solutions - but when you try to go beyond what they have been designed for, you tend to have to apply patches and hacks to get things working. John Cheers Peter and Karin -- Peter and Karin Dambier The Public-Root Consortium Graeffstrasse 14 D-64646 Heppenheim +49(6252)671-788 (Telekom) +49(179)108-3978 (O2 Genion) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
Peter Dambier wrote: Just for curiousity: The TI chipset AR7 is the core of a couple of boxes. The all run linux and you can telnet them. They can route. No need for NAT My box is an Eumex 300 IP from t-online.de It is the same as the Fritzbox from AVM. Netgear, Siemens, Linksys and D-link produce similar boxes. I remember some people at RIPE loudly thinking about writing their own software for the Netgear or the Linksys. People ARE writing software for these devices. And using their software. See, for instance, http://en.wikipedia.org/wiki/Wrt54g Among the publicly available enhancements you can get a tunneled v6 service if your provider doesn't support it natively. --Jari ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reality (was RE: Stupid NAT tricks and how to stop them.)
You know, you could assign IPv6 addresses in a strictly geographic way and you'd have more than enough for everyone, everywhere,with very simple routing. But of course that won't be done.In fact some people are doing this todaywithin their networks.IPv6 marveles ability to "address every millonth of a second of arc inlatitude and longitude on the planet" drives the entire excitment and funding.Private networks aside IP address allocation maybe needs to be done on a strictly geographical basisin a politically neutral fashion, e.g. via UN sponsored RIR / LIR. Wemay need an RFC on how tofund IANA activitiesthrough UN allowing "free" allocation of addresses to any interested individual or establishment.[EMAIL PROTECTED] "Anthony G. Atkielski" [EMAIL PROTECTED] wrote: Peter Sherbin writes: It is worth about the same as a postal address that comes naturally when they build a new house. In a similar way when a new device comes to existence it gets an address out of infinite universe of 0 and 1.That would only be true if IP addresses were geographically assigned,which they aren't.You know, you could assign IPv6 addresses in a strictly geographic wayand you'd have more than enough for everyone, everywhere, with verysimple routing. But of course that won't be done. The actual cost driver here is a need for an operator (e.g. Postal Service or ISP) to maintain a list of all existing addresses to be able to provide their services.Not necessarily. If the addressing is strictly geographic--naddresses for each area of m square metres on the planet--routingwould be very simple and wouldn't require much in the way of tables.With 78 bits, you can address every millonth of a second of arc inlatitude and longitude on the planet. That's an area of about 0.00095square millimetres.___Ietf mailing listIetf@ietf.orghttps://www1.ietf.org/mailman/listinfo/ietf Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates.___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Reality (was RE: Stupid NAT tricks and how to stop them.)
... However, geographic addressing could give us aggregation with provider independece. If you examine European routes in the routing table of a router on the American west coast, you'll see that the vast majority of those routes point towards the same next hop. So if you could express an aggregate that encompasses all those routes and point that aggregate towards that next hop, you could filter out all those specific routes and the routing table in that one router would be a lot smaller. At each hop the number of routes that have a different next hop than the aggregate increases, until at some point the aggregate doesn't serve a useful purpose anymore. But by then you're in Europe or at least on the American east coast, where you can heavily aggregate Asia. You'll have to produce the BGP4 table for a pretty compelling simulation model of a worldwide Internet with a hundred million enterprise customers and ten billion total hosts to convince me. I'm serious. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: RE: Stupid NAT tricks and how to stop them.
John Loughney wrote: We're over-analyzing things. I don't think so. The Internet is no longer this thing for researchers and geeks it used to be. Now it is a global commercial product. As long as we keep producing protocols designed by researchers and geeks for researchers and geeks with total disregard to mass-market considerations, we will keep having these discussions about why crap gets deployed instead of the good stuff. My DSL provier offers me 5 DHCP address for free (consumer grade connection) Then you don't need a router; if you don't NAT there is no address space you could route your DHCP addresses to/from. You need a bridge, just connect only the LAN side of your combo box and you'll be able to have your DHCP addresses over the WiFi. The wireless-to-wired bridge works regardless of the configuration of the WAN side of the combo box. Ironically, it is probably cheaper to buy a combo box than a pure wireless bridge, but that's another story. What you might want is a real firewall that could bridge, and as discussed earlier there are not many consumer grade offerings as of today. There few offerings because there is very little demand, and there is little demand because such firewalls have many of the inconveniences of NAT. Vendors have turned NAT on by default because it is easier for them; not because the market has asked them to. I do not agree. It was not easy at the beginning; it is easier now because it has become a more mature product. The market buys products, and the vendors react by producing the gear that the market wants to buy, for cheap because it's a competitive environment. When a product is new, vendors more or less guess what it could/will be, but when a product is mature such as NAT now, vendors design products based on what sells and recurse with small changes. In mass-market products vendors have little influence over the market. Marketing and advertising can somehow change what the market wants to buy, but in the end consumers often buy what is cheap or whatever their buddies have, and the fact that something is superior might not make any difference. As for reference, my local paper started, computer stores started advertising NAT firewalls around 1998-99. When NATs first came to the market, the marketing message was that NATs provided a security feature. At that time, NAT did provide some security. It was very common then to see PCs directly connected to the Internet with a public IP, with all the NetBios ports open to all would-be hackers in the world. The nothing in unless initiated inside is not perfect, but it was a heck of a lot better than an unprotected PC sitting directly on a public IP. I don't think it is really intellectually honest to say the market has chosen NATs because it is what they wanted - it is a band-aid fix for a couple of different problems, which it kind of solved I disagree with this as well. The market chose NAT. The market probably does not know it's a band-aid, nor does it care. But it knows it's cheap and it works good enough. The market chose cars that rust over stainless steel ones too (remember these cool DeLorean cars). The stainless steel car is superior to the regular car, but the inconvenience of the car rusting was not worth the difference in price and consumers did not embrace it. Same for light bulbs and neon tubes: light bulbs blow regularly and are not efficient; neons produce low-quality light. There are technologies that last long, are efficient and produce good quality light. Look around you. Same applies to NAT: if we want to get rid of it, instead of forever whining that it sucks we have to provide the market with a better alternative for about the same price, which we don't have today. Better meaning not what we deem as technically superior but what the market would consider worth implementing. Michel. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Reality (was RE: Stupid NAT tricks and how to stop them.)
Noel, Back in 1993 I predicted that what you have just stated is what us end users will actually do in regards to IPv6 (which we called IPng back then). I documented my thoughts in that regards in RFC 1687. RFC 1687 is somewhat dated now, since the example of a killer app I selected is rather quaint (to be generous), but the types of motivation underlying that identification still persist. In any case, I applaud your insight below that us end users will go to great lengths to avoid any costly network upgrade that does not contribute anything to our bottom line. Think about it: why would we spend tens of millions of dollars to get equivalent network connectivity to what we already have? It makes absolutely no sense from our point-of-view. --Eric -Original Message- From: Noel Chiappa [mailto:[EMAIL PROTECTED] Sent: Monday, April 10, 2006 7:36 AM To: ietf@ietf.org Cc: [EMAIL PROTECTED] Subject: Re: Reality (was RE: Stupid NAT tricks and how to stop them.) From: Tony Hain [EMAIL PROTECTED] The world needs the wake up call that reality is about to hit them in the face and they will need all the time there is left to develop a managed IPv6 deployment plan. If they don't start now they will be forced into a crash deployment when they try to get more space and find out the pool had long ago run dry. The IETF as a whole needs to wake up as well and stop developing for a dead end technology. The best laid plans o' mice an' men gang aft agley. -- Robert Burns 'Do not put too much faith in this hairy architecture you have constructed', retorted Daemon Feature. 'All this is insignificant compared to the Hack.' -- Mark Crispin, Software Wars Many years ago now, a funny thing happened on the way to complete exhaustion of the IPv4 address space (Version 1). Some clever people worked out this ugly hack, which the marketplace judged - despite its ugliness - to be a superior solution to the forklift upgrade to IPv6. It's been selling like hot-cakes ever since, while IPv6 languished. I've become rather disenchanted with my crystal ball, which seems quite cloudy of late (if you'd told me, in 1986, we'd still be running a Destination-Vector routing architecture for a routing table of this size 20 years later, I'd have *known* you were bonkers), so I have no specific prediction to make, but... Don't be surprised if the world, facing complete exhaustion of the IPv4 address space (Version 2) decides, yet again, that some sort of Plan B is a better choice than a conversion to IPv6. I have no idea exactly what it will be (maybe a free market in IPv4 addresses, plus layered NAT's, to name just one possibility), but there are a lot of clever people out there, and *once events force them to turn their attention to this particular alligator*, don't be surprised if they don't come up with yet another workaround. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'The Base16, Base32, and Base64 Data Encodings' to Proposed Standard
On 4/10/06 6:34 PM, John C Klensin [EMAIL PROTECTED] wrote: --On Tuesday, 11 April, 2006 11:26 +1000 Mark Andrews [EMAIL PROTECTED] wrote: On 4/10/06 4:31 PM, Mark Andrews [EMAIL PROTECTED] wrote: Did the base32 extended hex version get used in the SASL work? Can we upda te the reference or if it is not needed not just remove it. base32 extended hex is being / will be used for NSEC3 as it preserves the sort order. Great - perhaps we could add a reference to that. Work in progress. draft-ietf-dnsext-nsec3-04.txt needs to be update to say base32 extended hex and reference this draft. But such a reference from the Base16, Base32,... draft is not normative. To simply give (clearly non-normative) examples, with each encoding, of where it is used or expected to be used seems to me to helpful to the reader and to cost almost nothing. john I was concerned that we might be defining an option that no one needed and that would just encourage more variations where they were not needed. The fact that nsec3 has chosen to use this particular form is good enough proof for me that there is a need for the base32 extended hex form. I agree a informative ref to the work in progress will help people fine examples of where it was used and perhaps have a better understanding of where and why they might pick a particular form. All sounds good. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RFC 4295 on Mobile IPv6 Management Information Base
A new Request for Comments is now available in online RFC libraries. RFC 4295 Title: Mobile IPv6 Management Information Base Author: G. Keeni, K. Koide, K. Nagami, S. Gundavelli Status: Standards Track Date: April 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 109 Characters: 209038 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-mip6-mipv6-mib-07.txt URL:http://www.rfc-editor.org/rfc/rfc4295.txt This memo defines a portion of the Management Information Base (MIB), the Mobile-IPv6 MIB, for use with network management protocols in the Internet community. In particular, the Mobile-IPv6 MIB will be used to monitor and control the mobile node, home agent, and correspondent node functions of a Mobile IPv6 (MIPv6) entity. [STANDARDS TRACK] This document is a product of the Mobility for IPv6 Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4466 on Collected Extensions to IMAP4 ABNF
A new Request for Comments is now available in online RFC libraries. RFC 4466 Title: Collected Extensions to IMAP4 ABNF Author: A. Melnikov, C. Daboo Status: Standards Track Date: April 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 17 Characters: 33752 Updates:RFC2088, RFC2342, RFC3501, RFC3502, RFC3516 See-Also: I-D Tag:draft-melnikov-imap-ext-abnf-08.txt URL:http://www.rfc-editor.org/rfc/rfc4466.txt Over the years, many documents from IMAPEXT and LEMONADE working groups, as well as many individual documents, have added syntactic extensions to many base IMAP commands described in RFC 3501. For ease of reference, this document collects most of such ABNF changes in one place. This document also suggests a set of standard patterns for adding options and extensions to several existing IMAP commands defined in RFC 3501. The patterns provide for compatibility between existing and future extensions. This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516. It also includes part of the errata to RFC 3501. This document doesn't specify any semantic changes to the listed RFCs. [STANDARDS TRACK] This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4435 on A Framework for the Usage of Internet Media Guides (IMGs)
A new Request for Comments is now available in online RFC libraries. RFC 4435 Title: A Framework for the Usage of Internet Media Guides (IMGs) Author: Y. Nomura, R. Walsh, J-P. Luoma, H. Asaeda, H. Schulzrinne Status: Informational Date: April 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 22 Characters: 51687 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-mmusic-img-framework-09.txt URL:http://www.rfc-editor.org/rfc/rfc4435.txt This document defines a framework for the delivery of Internet Media Guides (IMGs). An IMG is a structured collection of multimedia session descriptions expressed using the Session Description Protocol (SDP), SDPng, or some similar session description format. This document describes a generalized model for IMG delivery mechanisms, the use of existing protocols, and the need for additional work to create an IMG delivery infrastructure. This memo provides information for the Internet community. This document is a product of the Multiparty Multimedia Session Control Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4455 on Definition of Managed Objects for Small Computer System Interface (SCSI) Entities
A new Request for Comments is now available in online RFC libraries. RFC 4455 Title: Definition of Managed Objects for Small Computer System Interface (SCSI) Entities Author: M. Hallak-Stamler, M. Bakke, Y. Lederman, M. Krueger, K. McCloghrie Status: Standards Track Date: April 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 88 Characters: 178947 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-ips-scsi-mib-09.txt URL:http://www.rfc-editor.org/rfc/rfc4455.txt This memo defines a portion of the Management Information Base (MIB), for use with network management protocols in the Internet community. In particular, it describes managed objects for Small Computer System Interface (SCSI) entities, independently of the interconnect subsystem layer. [STANDARDS TRACK] This document is a product of the IP Storage Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4293 on Management Information Base for the Internet Protocol (IP)
A new Request for Comments is now available in online RFC libraries. RFC 4293 Title: Management Information Base for the Internet Protocol (IP) Author: S. Routhier, Ed. Status: Standards Track Date: April 2006 Mailbox:[EMAIL PROTECTED] Pages: 122 Characters: 242243 Obsoletes: RFC2011, RFC2465, RFC2466 See-Also: I-D Tag:draft-ietf-ipv6-rfc2011-update-10.txt URL:http://www.rfc-editor.org/rfc/rfc4293.txt This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for implementations of the Internet Protocol (IP) in an IP version independent manner. This memo obsoletes RFCs 2011, 2465, and 2466. [STANDARDS TRACK] This document is a product of the IP Version 6 Working Group Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4292 on IP Forwarding Table MIB
A new Request for Comments is now available in online RFC libraries. RFC 4292 Title: IP Forwarding Table MIB Author: B. Haberman Status: Standards Track Date: April 2006 Mailbox:[EMAIL PROTECTED] Pages: 34 Characters: 69321 Obsoletes: RFC2096 See-Also: I-D Tag:draft-ietf-ipv6-rfc2096-update-07.txt URL:http://www.rfc-editor.org/rfc/rfc4292.txt This document defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects related to the forwarding of Internet Protocol (IP) packets in an IP version-independent manner. This document obsoletes RFC 2096. [STANDARDS TRACK] This document is a product of the IP Version 6 Working Group Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4389 on Neighbor Discovery Proxies (ND Proxy)
A new Request for Comments is now available in online RFC libraries. RFC 4389 Title: Neighbor Discovery Proxies (ND Proxy) Author: D. Thaler, M. Talwar, C. Patel Status: Experimental Date: April 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 18 Characters: 38124 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-ipv6-ndproxy-04.txt URL:http://www.rfc-editor.org/rfc/rfc4389.txt Bridging multiple links into a single entity has several operational advantages. A single subnet prefix is sufficient to support multiple physical links. There is no need to allocate subnet numbers to the different networks, simplifying management. Bridging some types of media requires network-layer support, however. This document describes these cases and specifies the IP-layer support that enables bridging under these circumstances. This memo defines an Experimental Protocol for the Internet community. This document is a product of the IP Version 6 Working Group Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussio and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 4457 on The Session Initiation Protocol (SIP) P-User-Database Private-Header (P-Header)
A new Request for Comments is now available in online RFC libraries. RFC 4457 Title: The Session Initiation Protocol (SIP) P-User-Database Private-Header (P-Header) Author: G. Camarillo, G. Blanco Status: Informational Date: April 2006 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 8 Characters: 15884 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-camarillo-sipping-user-database-02.txt URL:http://www.rfc-editor.org/rfc/rfc4457.txt This document specifies the Session Initiation Protocol (SIP) P-User-Database Private-Header (P-header). This header field is used in the 3rd-Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) to provide SIP registrars and SIP proxy servers with the address of the database that contains the user profile of the user that generated a particular request. This memo provides information for the Internet community. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
