Syslog inquiry, TAG delimiters.
Hello, We got a problem interpreting the RFC 3164 and we would appreciate any comments of the issue of what is a valid TAG delimiter. First, last part of section 4.1.3 states: The MSG part has two fields known as the TAG field and the CONTENT field. The value in the TAG field will be the name of the program or process that generated the message. The CONTENT contains the details of the message. This has traditionally been a freeform message that gives some detailed information of the event. The TAG is a string of ABNF alphanumeric characters that MUST NOT exceed 32 characters. Any non-alphanumeric character will terminate the TAG field and will be assumed to be the starting character of the CONTENT field. Most commonly, the first character of the CONTENT field that signifies the conclusion of the TAG field has been seen to be the left square bracket character ([), a colon character (:), or a space character. This is explained in more detail in Section 5.3. This part implies that space is a legal character to terminate a TAG with. However, further down in the text, section 5.4 Examples, you will find: Use the BFG! While this is a valid message, it has extraordinarily little useful information. This message does not have any discernable PRI part. It does not contain a timestamp or any indication of the source of the message. If this message is stored on paper or disk, subsequent review of the message will not yield anything of value. This example is obviously an original message from a device. A relay MUST make changes to the message as described in Section 4.3 before forwarding it. The resulting relayed message is shown below. 13Feb 5 17:32:18 10.0.0.99 Use the BFG! In this relayed message, the entire message has been treated as the CONTENT portion of the MSG part. First, a valid PRI part has been This implies that space is not a valid delimiter. So in this case, the TAG field is absent. In my ears this sounds as a better approach? But how do I approach this? Regards, Johan Bosaeus Weird Solutions AB ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
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. When not even those of us who can differentiate between different Internet connections by other means then speed can manage to get a proper Internet connection (e.g. with multiple fixed addresses), how can we expect regular users to ask for such advanced features? Myself, I am stuck with a telco-ISP that do not even provide the option to buy extra IP-addresses (or fixed addresses). This means I am forced to run a NAT at home, and do the tricks to make applications work in this environment (including making servers work, which of course is not allowed, but why should I care). At several occasions, friends have asked me why some of their communications applications do not work although they have a premium Internet connection, which meant they had purchased the highest speed available. Unfortunately, they have all been fooled by the ISPs that the only difference between different Internet connections is the maximal throughput, and they have ended up in a crappy NETed home environment. But why should ISPs be honest and explain to regular users that there could be better alternatives and that what they are currently selling is a restricted Internet connection? For ISPs, these restricted connections means users have problems running some applications, which reduces the traffic they generate, but the problems users have are not attributed to limitations in what the ISP provides. Only some ISP's openly declare the details of the Internet connections they provide, such as whether IP addresses are fixed or dynamic, if one can get multiple addresses, if IPv6 can be provided, etc. However, some do, and therefore I still believe there is hope, but it is hard for regular users to understand what different alternatives would mean (especially when ISPs are not honest with these matters). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: the iab net neutrality
On Mar 29, 2006, at 10:56 AM, Henning Schulzrinne wrote: We could ask the IEEE, since the relationship between the WiFi folks and IEEE 802.11 seems to be somewhat similar. One of the problems I see is that many of the industry associations (SIP Forum, IPv6 forum, to name two I'm somewhat familiar with) tend to focus on service providers, not consumers. But an organization such as the SIP Forum could provide a VoIP-optimized label for NAT boxes and maybe even ISPs. I'm a board member of the SIP Forum, so I'd like to respond to Henning. (I'm speaking as an individual here who happens to be on the SIP Forum board so these are personal views neither discussed with nor agreed to by the rest of the board. Ditto for the IAB.) The SIP Forum is a creature of our members, which today are almost exclusively service providers and equipment vendors. We try to respond to the pain points they bring us and add value by bridging the gap between protocol standardization through the IETF and needs in the market. So far, we've been pretty successful at running interoperability testing through the SIPIT program, and coming up with deployment and feature bundling specifications in areas like hooking up SIP-based enterprise VoIP systems to service providers who are offering PSTN origination and termination services. The question of how to help the consumer market segment is one we are stumped on, for a number of reasons. First, there is no obvious advocate for the needs of consumers among our membership. Second, few to none of the vendors who sell consumer gear (e.g. Linksys, Netgear, Sony, Apple) are members. Third, much of that market segment is driven by offshore manufacturers who have little incentive to lead in engineering. Their expertise is in channel and brand management, and in minimizing all costs, including engineering (not to mention forum memberships...). That said, a number of us believe that we are having a modest effect. For example, in the enterprise interconnect specification, we worked very hard to make sure straightforward interconnect worked without mandating extra firewall, NAT or B2BUA functionality. The idea of having the SIP Forum sponsor work to at least partially drain the NAT/firewall traversal swamp is a good one. So - seeing as this is on the IETF public list, let me offer a plea: if you work with or build SIP products for consumers, JOIN THE SIP FORUM and help us put together a program in our Technical Working Group to address these issues. We are driven by our members. Membership is free for individuals and of modest cost for companies. Cheers, Dave Oran Thus, I think we need a separate organization (or work with a separate organization) that does branding and certification. It's hard to buy a non-WiFi device in stores today; the equivalent consumer assurance needs to be true for core consumer and small- business network devices, and possibly services. I don't know how this would work, but if it could be made to work, that might be very helpful. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: draft-santesson-tls-ume Last Call comment
On Sunday, March 26, 2006 02:48:17 PM -0800 Kurt D. Zeilenga [EMAIL PROTECTED] wrote: I note that SASLprep is case-insensitive and hence may not be appropriate for the user portion of a UPN. I think this is a type. SASLprep is case-preserving, and hence may not be appropriate for the user portion of a UPN, if the latter are intended to be case-insensitive. I also think it odd to allow both toUnicode and toASCII domain component forms on the wire. So do I. (I recommend the latter). Why? The toASCII form was designed to allow IDN's to be encoded for use in protocol fields which are very restrictive about what octet strings they can carry; in particular, label fields in the DNS wire protocol. Why do I keep seeing people who insist on using that inefficient encoding in protocol slots which are perfectly capable of carrying UTF-8? That's very much like suggesting the use of base-32 encoding in an 8-bit-clean field. Use of toASCII is appropriate for _existing_ IDN-unaware uses of domain names. I wish someone would explain to me why so many people want to use it for IDN-aware uses in new protocols. -- Jeff ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
Lars, Michel Py wrote: 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. Lars-Erik Jonsson wrote: 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. Your argument does not hold water. Do a survey of customers who have the advanced or pro package (with higher speed and multiple static IP addresses) and you will find that the very vast majority of them (if not all) use NAT anyway even though they have enough public addresses. For ISPs, these restricted connections means users have problems running some applications, which reduces the traffic they generate. This does not hold water either. By far, the volume of traffic is peer-to-peer (mostly questionable in terms of copyright). All major P2P apps for the most widely used protocols (bittorrent, edonkey etc) cross NAT nicely, most have UPNP support (no configuration of the NAT box) and some even have external NAT traversal mechanisms that don't even require to open a port. Breaking games an other low-volume apps serves no purpose. When ISPs want to curb traffic, they either: cap the speed, have monthly quotas, or (rarely, as it will result in loss of business) enforce their AUP. Michel. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On 5-Apr-2006, at 11:09, Michel Py wrote: Your argument does not hold water. Do a survey of customers who have the advanced or pro package (with higher speed and multiple static IP addresses) and you will find that the very vast majority of them (if not all) use NAT anyway even though they have enough public addresses. A survey of users where? Arguments which shuttle backwards and forwards between people in regions with different packaging of internet access services are unlikely to bear fruit so long as the arguments concentrate on assumptions about packaging. Different ISPs package access in different ways. Some do the NAT for you, in their network; some do the NAT in the CPE equipment they supply; some don't do NAT for you at all. Some ISPs provide only dynamic addresses, and distinguish their packages based on speed; some ISPs have the option of static addresses, but only one per subscriber; some ISPs can assign a subnet to a customer. Some ISPs package their access services according to peak speed available; some according to a contention ratio within their network (or within the telco's network which they use to reach the customer). Some ISPs provide a data cap. Some ISPs charge for volume. Some ISPs restrict access speed when a volume threshold within a billing period has been reached. Some ISPs bill according to data transferred; some ISPs bill at a flat rate. Some ISPs filter traffic towards their customers; some don't. Some ISPs (apparently, possibly) deliberately introduce jitter and latency into their access products to discourage customers from using VoIP. Others don't. Some ISPs are happy for people to run servers; some are not. Some ISPs are happy for customers to announce their own address space to them over DSL using BGP (I know this, since I am a customer of one of them). Some ISPs sell symmetric access services; others sell asymmetric services. Some use cable; some use DSL; some use fibre; some use wireless transmission; some use frame-relay or PPP or HDLC over synchronous T1s or E1s. Some ISPs compete for customers in an open market. Some ISPs don't need to, because they have a natural monopoly in access. Some ISPs have access to the copper; some ISPs are dependent on wholesale products of telcos, and are perhaps limited in what they can provide for that reason. It's a rich tapestry. Assuming that what is available in one region implies anything about what is available in other regions is unproductive. Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
Michel Py wrote: Your argument does not hold water. Do a survey of customers who have the advanced or pro package (with higher speed and multiple static IP addresses) and you will find that the very vast majority of them (if not all) use NAT anyway even though they have enough public addresses. Joe Abley A survey of users where? Of anywhere where ISPs offer a package with static IP addresses. I mean a survey of regular customers, not fellow IETFers or geek buddies. How many of them actually have multiple static IPs and how many are behind NAT nevertheless. Run your survey and come back with data. It's a rich tapestry. It is. Assuming that what is available in one region implies anything about what is available in other regions is unproductive. Assuming that IETFers and their ideas on how to configure a network are representative of the general consumer base is ignoring this rich tapestry. Michel. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On 5-Apr-2006, at 12:16, Michel Py wrote: Of anywhere where ISPs offer a package with static IP addresses. I mean a survey of regular customers, not fellow IETFers or geek buddies. How many of them actually have multiple static IPs and how many are behind NAT nevertheless. Run your survey and come back with data. I was under the impression that *you* were the one making assertions about user behaviour. I don't necessarily disagree with them. However, asking other people to do surveys to confirm your assertions (with the implication that people who can't be bothered to do those surveys somehow aren't fit to disagree) seems more like an exercise in rhetoric than in engineering. On 5-Apr-2006, at 11:09, Michel Py wrote: [...] Do a survey of customers who have the advanced or pro package (with higher speed and multiple static IP addresses) and you will find that the very vast majority of them (if not all) use NAT anyway even though they have enough public addresses. [...] By far, the volume of traffic is peer-to-peer (mostly questionable in terms of copyright). All major P2P apps for the most widely used protocols (bittorrent, edonkey etc) cross NAT nicely, most have UPNP support (no configuration of the NAT box) and some even have external NAT traversal mechanisms that don't even require to open a port. Breaking games an other low-volume apps serves no purpose. When ISPs want to curb traffic, they either: cap the speed, have monthly quotas, or (rarely, as it will result in loss of business) enforce their AUP. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
--On Wednesday, 05 April, 2006 08:09 -0700 Michel Py [EMAIL PROTECTED] wrote: Michel Py wrote: 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. Lars-Erik Jonsson wrote: 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. Your argument does not hold water. Do a survey of customers who have the advanced or pro package (with higher speed and multiple static IP addresses) and you will find that the very vast majority of them (if not all) use NAT anyway even though they have enough public addresses. It is worth noting in this context that many of the Router products that are sold for SOHO use (including the high-end products from the first two vendors listed above) do not provide any support for multiple static addresses except via one-to-one NAT. It is simply not possible to configure those devices to support use of static public addresses for hosts on the LAN side. This situation would somewhat contaminate the results of the survey you suggest above. These are not ISP-imposed limitations, but limitations imposed by commercially-available products. It also suggests, again, that part of the current drive by vendors to support NAT is not because of address shortages but by support and configuration difficulties with providing and using small pools of provider-dependent static addresses. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
John C Klensin wrote:
It is simply not possible to configure those devices
to support use of static public addresses for hosts
on the LAN side.
First, this is totally false, see below. Second, if you want to use
public IPs on the LAN side you just have to plug your hosts directly in
the back of the {DSL|whatever} modem. Or use the firewall of your
choice.
This situation would somewhat contaminate the results
of the survey you suggest above.
Not at all, see above. Plus, read below also.
It is worth noting in this context that many of the Router
products that are sold for SOHO use (including the high-end
products from the first two vendors listed above) (Linksys,
Netgear) do not provide any support for multiple static
addresses except via one-to-one NAT.
This is simply NOT true. Large numbers of SOHO routers can operate
with or without NAT and yes including the high-end products from the
first two vendors listed above.
Linksys RV042: http://tinyurl.com/zf7o8
Netgear FVG318: http://www.netgear.com/products/details/FVG318.php
And this is the norm. The one I use right now:
http://www.broadxent.com/products/8120.asp
and many more:
http://www.sonicwall.com/totalsecure/ts10.html
http://www.netopia.com/equipment/routers/routers_models.html
I have seen some of the speedstreams too and they all had an option to
run with or without NAT. Many of them also have the option to have a
bridge mode allowing the customer to provide their own router/firewall
solution.
These are not ISP-imposed limitations, but limitations
imposed by commercially-available products.
Please stop spreading disinformation. The proof is in the pudding, just
click on the links above. Maybe actually looking at what's out there
would help too.
Michel.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On 5-apr-2006, at 17:09, Michel Py wrote: By far, the volume of traffic is peer-to-peer (mostly questionable in terms of copyright). All major P2P apps for the most widely used protocols (bittorrent, edonkey etc) cross NAT nicely, most have UPNP support (no configuration of the NAT box) and some even have external NAT traversal mechanisms that don't even require to open a port. Breaking games an other low-volume apps serves no purpose. This sounds a lot like NAT doesn't really break anything. If I pretend I'm a regular user for a minute, I can tell you this is not the case. When I used NAT for my Powerbook I had lots of problems doing videochats with Apple's iChat with someone else who was also behind NAT. Even when I configured the single real IP address I got on my Powerbook (very tricky because there was a Cisco SOHO box terminating a PPPoA ADSL link in the middle) it still didn't work very reliably. RTSP with Quicktime didn't work when the Cisco 82x did the NATting, but it would when an Apple Airport Extreme performed NAT. Peer-to-peer isn't a good example, because of the high built-in redundancy. Even someone who can only set up outgoing sessions can run BitTorrent without too much trouble because there are plenty of peers without NAT or portmappings of some kind (manual, uPnP or NAT- PMP) that can receive the incoming sessions. When the sessions are up, traffic can flow both ways. However, if you read forums or release notes you'll see lots of discussion on port mapping because being able to receive incoming session setup attempts means that you get to connect to more peers (all of them, without port mapping only others that are not behind NAT or do have port mapping) so your downloads are faster. Given the market place realities the IETF should be careful to make its protocols interoperate with NAT whenever possible, but don't think for a minute that adding NAT workarounds solves the problem completely. Here in the Netherlands ISPs generally give out a single real IP address to their customers, but most customers use a DSL or cable modem with NAT or an additional NAT router or wireless base station so they can connect more than one computer. Despite some individual reports to the contrary, I believe the same is true for most IP users. However, some ISPs already perform NAT for their customers in their network, and that's only going to increase as IPv4 addresses become more scarce and eventually run out completely. At that point, many people will be behind two layers of NAT. Also, reserving ports will be very hard because many systems share one real IP address. Maybe it's just me, but I don't see the IETF or anyone else for that matter coming up with something that allows communication between two people who are both behind two layers of NAT with any modicum of reliability. So in addition to supporting NAT where reasonably possible, the IETF should also continue to plan for a future where there is enough address space to make NAT unnecessary. However, universal reachability isn't coming back even if NAT is out of the picture because people love to run firewalls that break way more stuff than intended. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
--On Wednesday, 05 April, 2006 11:23 -0700 Michel Py
[EMAIL PROTECTED] wrote:
John C Klensin wrote:
It is simply not possible to configure those devices
to support use of static public addresses for hosts
on the LAN side.
First, this is totally false, see below. Second, if you want
to use public IPs on the LAN side you just have to plug your
hosts directly in the back of the {DSL|whatever} modem. Or use
the firewall of your choice.
Michel, spreading disinformation is a rather strong claim; not
one I would choose to make without actually examining the
devices and their manuals, not just the marketing descriptions
you cite below. That said, I did somewhat oversimplify the
problem I described. More detail, and a pair of partial product
reviews, follows below. If I owe the vendors an apology, I will
apologize, but I will do so only in the presence of either
vendor documentation of how to do what is needed (user manual,
knowledge base article, or the equivalent) or a user-level
description of how to do it that the vendors will support. See
below.
This situation would somewhat contaminate the results
of the survey you suggest above.
Not at all, see above. Plus, read below also.
It is worth noting in this context that many of the Router
products that are sold for SOHO use (including the high-end
products from the first two vendors listed above) (Linksys,
Netgear) do not provide any support for multiple static
addresses except via one-to-one NAT.
This is simply NOT true. Large numbers of SOHO routers can
operate with or without NAT and yes including the high-end
products from the first two vendors listed above.
Linksys RV042: http://tinyurl.com/zf7o8
Netgear FVG318:
http://www.netgear.com/products/details/FVG318.php And this is
the norm.
Our experience differs, but this is not disinformation. I'm
running an RV082 (the 042's bigger and more capable sibling)
here and consigned an FVG318 to the parts closet before getting
the RF082.In both cases, I bought the products at retail and
struggled for some weeks, reading manuals and using the vendor's
customer support mechanisms and, in the RV082 case, taking
advantage of some additional support resources before reaching
the conclusions that I reached.
At least part of the problem are some constraints that, as a
simplification, I didn't mention. The two most recent ISPs I've
dealt with personally, and two more I've deal with on behalf of
friends I was trying to set up, all insist on owning control of
the front-end CPE modem/ router equipment. They do not
permit (by TsCs, password control, etc.) the customer to
reconfigure that equipment to, e.g., operate it in bridge mode.
The number of static addresses available or in use is quite
small, typically a /28 or even a /29. Finally, I need a device
with the ability to specify port priorities and to supply some
firewall capability.
One implication of this is that there is a little problem of
router co-existence: the customer-supplied device has to be
plugged into the LAN side of the ISP-supplied device, using one
of those static addresses as its WAN-side but supplying the
others to devices on the actual LAN. In principle, it ought to
be possible to do that by setting up static routes, but (i)
neither vendor was able to specify how to do it and (ii) some,
if not all, of the ISPs configure their interface devices to
require that different addresses appear on the different ports
they supply.
For both of these vendors can use static addresses in
marketing literature apparently mean that one can use a static
address on its WAN side and can turn DHCP off, or run DHCP with
MAC-mapped addresses, on the LAN side. Both support those
capabilities; the problem is where the addresses come from.
Actual experience with trying to set the devices up with a
static /29 pool of public addresses used on the LAN side of the
device and with the same pool presented to and used from the
public Internet were unsuccessful.
Disclaimer about the Netgear box: I haven't tried to use it with
static, public addresses for well over a year. Perhaps new
firmware and documentation has been released and it has been
changed to better support these functions. I doubt it somehow,
but perhaps.
In the case of Netgear, there is not a hint in any of the
documentation, or in their knowledge base as of a year or so
ago, that use of public addresses is possible. After an
extended discussion with their technical support operation (and
an escalation or two), I was told that the device would not
support what I needed (i.e., public addresses on the LAN
identical to the public addresses by which the Internet saw
those hosts, with no NAT function of any sort) and that, if I
could trick it into doing what I was asking for, they would not
support it. That led to a discussion about how they could
claim support for static, public, addresses, but that discussion
didn't lead anywhere.
In the case of the Linksys device, the
RE: Stupid NAT tricks and how to stop them.
-John Calcote ([EMAIL PROTECTED])Sr. Software EngineeerNovell, Inc. John C Klensin [EMAIL PROTECTED] 4/5/2006 10:43:36 am --On Wednesday, 05 April, 2006 08:09 -0700 Michel Py[EMAIL PROTECTED] wrote: Michel Py wrote: 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.It is worth noting in this context that many of the Routerproducts that are sold for SOHO use (including the high-endproducts from the first two vendors listed above) do not provideany support for multiple static addresses except via one-to-oneNAT. It is simply not possible to configure those devices tosupport use of static public addresses for hosts on the LANside. This situation would somewhat contaminate the results ofthe survey you suggest above.These are not ISP-imposed limitations, but limitations imposedby commercially-available products. -- I'll just jump in here for a second and mention also that vendors offer what they have to, not what they can. They want to provide the most "bang for the buck", so to speak. These companies don't offer the multiple-static-ip-address option today because most ISP's don't offer it to home users and home (SOHO) users represent the target market. That said, they *would* offer these features if SOHO users were constantly frustrated about the fact that they can't make use of the multiple static addresses that their ISP provides them because of limitations in their router equipment... The fact is, _when_ IPv6 becomes truly mainstream and ISP's begin to offer multiple static addresses because they can, then these companies will offer the features on their routers. Let's not mistake what the world wants, for what it is successfully living with today. John BEGIN:VCARD VERSION:2.1 X-GWTYPE:USER FN:John Calcote EMAIL;WORK;PREF;NGW:[EMAIL PROTECTED] N:Calcote;John ORG:;Unified Identity System Eng TE TEL;WORK:1-801-861-7517 TITLE:Sr. Software Engineer ADR;DOM;WORK;PARCEL;POSTAL:;PRV-H-511;;Provo LABEL;DOM;WORK;PARCEL;POSTAL;ENCODING=QUOTED-PRINTABLE:John Calcote=0A= PRV-H-511=0A= Provo END:VCARD ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On 5-apr-2006, at 21:57, John C Klensin wrote: they all had an option to run with or without NAT. Many of them also have the option to have a bridge mode allowing the customer to provide their own router/firewall solution. It is that bridge mode that is critical. As I indicated above, neither the Linksys nor the Netgear devices provide it. The SonicWall does, but raises other, unrelated, issues. I carefully did not address any devices I haven't actually used. That leaves us in a state in which it is necessary to handle static public IP addresses by either * running the ISP's interface device in bridge mode, which many (although perhaps not all) ISPs prohibit * running the router devices as one-one NATs It occurs to me that there is nothing that prevents this exact same issue from coming up in IPv6. Even with an unpronouncable number of addresses, if you provide your own box that performs routing (which is generally a requirement for any kind of firewalling), the ISP has set up an address range to communicate with that box, and another address range that it forwards to that box for use behind it. I.e., if the ISP provides a CPE box under their control and I have my own router/firewall, then I need a subnet between the two and at least one more subnet on another port of my router/firewall where my hosts reside. The first issue is that this makes getting a single /64 from the ISP useless, and the second issue is that either there needs to be some manual configuration or there needs to be some kind of address provisioning protocol to be run between the CPE and the customer router/firewall, such as DHCPv6 prefix delegation. (Note by the way that PPP can do address provisioning for a single address in IPv4 but it can't do this for IPv6, making stuff like IPv6 over dial-up extremely hard to do.) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
At 11:23 AM -0700 4/5/06, Michel Py wrote: John C Klensin wrote: It is simply not possible to configure those devices to support use of static public addresses for hosts on the LAN side. First, this is totally false, see below. No, it is *partially* false, but unfortunately true in many cases. Some SOHO devices allow to use the outside IP addresses on the inside, and some don't. More importantly, some that say they allow you to turn off the NAT don't actually work. In the VPNC test lab, we have found some SOHO systems (from more than one vendor, based on code from more than one OEM) where turning off the NAT using the GUI didn't do anything: the NAT was still in force. The vendors had to fix their software before they could continue with our testing because we explicitly do not test with NATs (except for our upcoming testing of IPsec NAT-traversal interop). The VPNC members were fairly happy to have discovered sooner rather than later that their NAT configuration was not what they thought it was. They were not happy to have to fix their code, of course, but it is better to have to do so early in the shipping cycle before the customer support calls come. On the other hand, one vendor who has a series of boxes that cannot have their NATs turned off said that they essentially never get complaints about it, even though the always-NAT-no-matter-what feature is not listed on the box. Assuming that the system documentation is correct in this area is not a good idea, at least from the hands-on experience in our lab. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
--On Wednesday, 05 April, 2006 22:24 +0200 Iljitsch van Beijnum [EMAIL PROTECTED] wrote: On 5-apr-2006, at 21:57, John C Klensin wrote: they all had an option to run with or without NAT. Many of them also have the option to have a bridge mode allowing the customer to provide their own router/firewall solution. It is that bridge mode that is critical. As I indicated above, neither the Linksys nor the Netgear devices provide it. The SonicWall does, but raises other, unrelated, issues. I carefully did not address any devices I haven't actually used. That leaves us in a state in which it is necessary to handle static public IP addresses by either * running the ISP's interface device in bridge mode, which many (although perhaps not all) ISPs prohibit * running the router devices as one-one NATs It occurs to me that there is nothing that prevents this exact same issue from coming up in IPv6. Even with an unpronouncable number of addresses, if you provide your own box that performs routing (which is generally a requirement for any kind of firewalling), the ISP has set up an address range to communicate with that box, and another address range that it forwards to that box for use behind it. I.e., if the ISP provides a CPE box under their control and I have my own router/firewall, then I need a subnet between the two and at least one more subnet on another port of my router/firewall where my hosts reside. The first issue is that this makes getting a single /64 from the ISP useless, and the second issue is that either there needs to be some manual configuration or there needs to be some kind of address provisioning protocol to be run between the CPE and the customer router/firewall, such as DHCPv6 prefix delegation. This was part of the point I was trying to make before the totally false assertion arose. The boxes can't magically a small-address-range single subnet work because making it work is tricky to do and trickier to support. If the subnet is big enough that one can plausibly throw half of it away (as might be the case with an IPv6 /64), then there is an obvious trick with subnet masks... but I believe that at least some of these router/firewall boxes won't support it. And neither many hardware vendors nor many ISPs are particularly anxious to support configurations that are tricky-- they cause (expensive for the vendor/ ISP) support calls. (Note by the way that PPP can do address provisioning for a single address in IPv4 but it can't do this for IPv6, making stuff like IPv6 over dial-up extremely hard to do.) More of the same. From my perspective, parts of this discussion, in its many repetitions and many forms, have become pointless to the level of uninteresting. Some of us believe that NATs are bad news and harmful. Others believe that NATs fall somewhere on the scale between harmless and actually good. That debate has turned into a religious war and cannot be settled -- presumed facts presented by either side are simply ignored, or rejected with claims stated in strong language, by the other. By contrast, the question of whether IPv6, by itself, will solve or eliminate NATs is one that is susceptible to engineering evaluation and, IMO, suggests work that the IETF ought to be doing. Whether we like NATs or not, we need to understand the forces that drive them and to understand that those forces are not all about address space. And, on that basis, we need to look, again IMO, at both protocols and policies to be sure that we have provided the tools for permitting those who wish to get rid of NATs to do so. If we don't know how to build, and inexpensively support, a router/firewall without address mapping, then we had better figure it out. If ISPs like NATs because they can't economically handle the perceived higher support costs of every end-user LAN having a slightly different topology, then we had better figure out how to solve the underlying problem rather than assuming that IPv6 will eliminate the NATs. If, as Iljitsch suggests, PPP (as now defined) isn't quite suitable for supporting IPv6 over dialup, then someone better be looking at fixing that -- and looking at strange-to-me setups such as PPoE in the process. And, if everyone gets a /64 really doesn't work because of outside-firewall and inside-firewall issues, we had best either figure out how to change that restriction or turn the allocation rule into everyone gets two /65s, or do something else to deal with the issues that can be standardized and built into both equipment and user manuals. Until that work is done, we, I believe, should keep our expectations about IPv6 deployment to end-user LANs very modest. john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
John Calcote wrote: I'll just jump in here for a second and mention also that vendors offer what they have to, not what they can. They want to provide the most bang for the buck, so to speak. These companies don't offer the multiple-static-ip-address option today because most ISP's don't offer it to home users and home (SOHO) users represent the target market. That said, they *would* offer these features if SOHO users were constantly frustrated about the fact that they can't make use of the multiple static addresses that their ISP provides them because of limitations in their router equipment... Exactly. As I said many times: vendors sells what the market wants to buy, and IETFers do not make the market. John, John C Klensin wrote: spreading disinformation is a rather strong claim; not one I would choose to make without actually examining the devices and their manuals, not just the marketing descriptions you cite below. I have personally configured non-NAT on a least a dozen different of these boxes. At least part of the problem are some constraints that, as a simplification, I didn't mention. I can see that now, but your original text said nothing. The two most recent ISPs I've dealt with personally, and two more I've deal with on behalf of friends I was trying to set up, all insist on owning control of the front-end CPE modem/ router equipment. They do not permit (by TsCs, password control, etc.) the customer to reconfigure that equipment to, e.g., operate it in bridge mode. Common issue, then ask the ISP to reconfigure it in bridge mode themselves. If the contract says you get public IPs this means these IPs available for your hosts, not for their router. I never had an ISP refuse to do this, it's quite easy at time of installation to call the sales droid and tell it that if they don't configure their stuff to deliver your public addresses on the LAN side they can stick it. Sales droid wants his commission, sales droid talks to the techs. Other method: spend $20 on eBay for a DSL modem/router that you have control of. It is not illegal to swap their modem for yours, and if you ever have to call their support (you know, the guys that ask for 1/2 hour if the power is on and if the lights are green) just plug their modem back for the time of troubleshooting and the put yours back when done. For this very reason I kept the Alcatel aDSL modem that PacBell sold me 7 years ago although I have used at least 4 different ones. FYI, in the latest ATT (formerly SBC formerly Pacific Bell) aDSL self-install kits that they ship, the password to admin the NAT box is on a sticker underneath the box. Before, techies still knew that it was the MAC address or the serial number of the box. They actually want you to try to configure the box, mess it up, and send you a tech and bill $200 to fix it. Also, they were tired of people clogging their support to ask how to make this of that work. New method: if it does not work, see your software vendor. ISPs that survive and grow provide what their customers ask for, and admin access to the CPE device to open ports is one of these demands. The number of static addresses available or in use is quite small, typically a /28 or even a /29. In my experience, /29 is good enough for a typical home and /28 for a typical small office. If you need more you fall into the medium business category and allegedly have the $$$ that go with it. Finally, I need a device with the ability to specify port priorities Your requirements are way over the typical user. If you have requirements that represent 1% of the demand, you will not be able to use the canned solution that fits the masses. Possibly not because of technical reasons but for business reasons: vendors might think that if you have such requirements you have the money to pay for them (which is partially justified by higher support costs). If you don't find what you need in el-cheapo mass-produced consumer stuff it's not because vendors are trying to screw you but because your business does not represent enough money for them to take action. and to supply some firewall capability. There is no cheap firewall solution unless you call firewall what comes with a $20 NAT box. In the case of the Linksys device, the documentation is fairly clear that the address space on the WAN-side needed to be disjoint from the address space on the LAN-side. This is the case also for many others even high-end ones such as the Cisco PIX firewall (last time I checked). Your requirements are different than the masses, you have to use the box that fits your requirements. The fact that very few firewalls support bridging is simply due to the lack of demand. A solution to this is that either the ISP-supplied CPE or the internal router device operate in bridge mode. Indeed and I do acknowledge that many firewalls do not, which I found myself to be a pain. But you still have two avenues: 1. A router/firewall
Re: Stupid NAT tricks and how to stop them.
John Calcote writes: I'll just jump in here for a second and mention also that vendors offer what they have to, not what they can. They want to provide the most bang for the buck, so to speak. These companies don't offer the multiple-static-ip-address option today because most ISP's don't offer it to home users and home (SOHO) users represent the target market. It is unlikely that ISPs will ever offer static IPs or multiple IPs to home users at any time in the future for free. They will continue to charge heavy premiums for such professional features, with or without IPv6. That said, they *would* offer these features if SOHO users were constantly frustrated about the fact that they can't make use of the multiple static addresses that their ISP provides them because of limitations in their router equipment... SOHO users probably won't be willing to pay 500% more for multiple or static IPs, anyway. The fact is, _when_ IPv6 becomes truly mainstream and ISP's begin to offer multiple static addresses because they can ... ISPs can do that already, but they charge a great deal for it, and they probably always will. ATT used to charge for any telephone color other than black, even though the cost of producing a telephone was the same no matter what color it was. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Last Call: 'IKE and IKEv2 Authentication Using ECDSA' to Proposed Standard
The IESG has received a request from an individual submitter to consider the following document: - 'IKE and IKEv2 Authentication Using ECDSA' draft-ietf-ipsec-ike-auth-ecdsa-05.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-05-03. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-auth-ecdsa-05.txt Also, this IPR disclosure may be of inerest https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=695 ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
WG Action: Conclusion of Kerberized Internet Negotiation of Keys WG (kink)
The Kerberized Internet Negotiation of Keys WG (kink) in the Security Area has concluded. The IESG contact persons are Russ Housley and Sam Hartman. The mailing list will remain active. +++ The Kink working group has completed its objectives by publishing a Kerberized IPsec key management protocol and requirements for that protocol. Thanks to all those who have contributed over the years. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Last Call: 'DDP/RDMAP Security' to Proposed Standard
The IESG has received a request from the Remote Direct Data Placement WG to consider the following documents: - 'DDP/RDMAP Security ' draft-ietf-rddp-security-08.txt as a Proposed Standard - 'Applicability of Remote Direct Memory Access Protocol (RDMA) and Direct Data Placement (DDP) ' draft-ietf-rddp-applicability-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 any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-04-19. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-rddp-security-08.txt http://www.ietf.org/internet-drafts/draft-ietf-rddp-applicability-05.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
