.255 and .0 addresses
Dear Colleagues, I am not quite sure that routing-wg@ is a right place to ask my question, but nothing more convenient came to my mind :-) I am trying to push one BIG telecom equipment vendor TAC to consider wrong situation with assignment of IP addresses like xxx.xxx.xxx.0 and xxx.xxx.xxx.255 from dynamic IP pools bigger than or equal to /24. Quick googling has not shown any STD or BCP documents, which could be used as reference, but has shown number of pages, saying something like "do not use .0 or .255 addresses, it could cause problems". Our small research has shown that some sites are not reachable from .255 and .0 addresses. Are there any published documents or strong research results which could be used as reference point to illustrate this problem existance? -- Regards, Volodymyr.
hi, On Sun, Sep 12, 2004 at 08:05:55PM +0300, Volodymyr Yakovenko wrote:
I am trying to push one BIG telecom equipment vendor TAC to consider wrong situation with assignment of IP addresses like xxx.xxx.xxx.0 and xxx.xxx.xxx.255 from dynamic IP pools bigger than or equal to /24.
Strictly speaking, this is not a software bug. Inside a larger network, say a /23 going from .0.0 - .3.255, the "inside" .0 and .255 addresses are not special, and could be used just fine, just as any other address. OTOH, in the Internet, a fair number of people are now filtering .0 and .255 addresses due to the common exploiting of the "smurf" packet amplifying method. So the addresses cannot really be used for Internet connectivity anymore. We work around that by defining the pools in multiple steps: ip local pool dial-in-block a.b.52.1 a.b.52.254 ip local pool dial-in-block a.b.53.1 a.b.53.254 ip local pool dial-in-block a.b.54.1 a.b.54.254 ip local pool dial-in-block a.b.55.1 a.b.55.254 that way, "one of the big vendors"' equipment will not assign .0 and .255 out of the pool. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 66629 (65398) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
On Sunday 12 September 2004 18:05, Volodymyr Yakovenko wrote:
Dear Colleagues,
I am trying to push one BIG telecom equipment vendor TAC to consider wrong situation with assignment of IP addresses like xxx.xxx.xxx.0 and xxx.xxx.xxx.255 from dynamic IP pools bigger than or equal to /24.
Quick googling has not shown any STD or BCP documents, which could be used as reference, but has shown number of pages, saying something like "do not use .0 or .255 addresses, it could cause problems".
Without doubt, the pools must be bigger than /24 in order for .0 or .255 to be used as host addresses. Never tried it personally, but I can see no reason why .0.255 or .1.0 wouldn't be usable in a .0.0/23 - obviously assuming that you pass /23 to the hosts as a netmask. Jon
--On dimanche 12 septembre 2004 20:14 +0100 Jon Lawrence <jon@lawrence.org.uk> wrote:
Without doubt, the pools must be bigger than /24 in order for .0 or .255 to be used as host addresses. Never tried it personally, but I can see no reason why .0.255 or .1.0 wouldn't be usable in a .0.0/23 - obviously assuming that you pass /23 to the hosts as a netmask.
Our experience as ISP proved that you don't want to allocate .0 and .255 addresses to your customers: stats reveal lower rates and lower connection times for those customers. We assumed that was due to the windows TCP/IP stack, and we have proved the Cisco stack to be culprit some times, sending other customers broadcast frames to the unfortunate .255 Since then we've definitely stopped allocating .0 and .255 addresses, no problem anymore. -- Jerome Fleury Tiscali France Network Engineer Tel: +33 1 45082314
* Jon Lawrence:
Without doubt, the pools must be bigger than /24 in order for .0 or .255 to be used as host addresses. Never tried it personally, but I can see no reason why .0.255 or .1.0 wouldn't be usable in a .0.0/23 - obviously assuming that you pass /23 to the hosts as a netmask.
Some sites filter .0 and .255, but I don't see why one should support such misconfiguration. ISPs with large dial-up ranges certainly assign .0 and .255 addresses to customers.
This is issue but not routing-wg's... We noticed this problem some time ago. First we thought that the problem is in the BRAS equipment but it's not. It seems to be that site's behind broken firewalls which refuses the connection from x.x.x.0 and x.x.x.255 addresses. We haven't been able to find out which vendors break classless ip. If there is Firewall WG in IETF, it would be the correct place for this topic... Regards, Jarno Lähteenmäki Jon Lawrence wrote:
On Sunday 12 September 2004 18:05, Volodymyr Yakovenko wrote:
Dear Colleagues,
I am trying to push one BIG telecom equipment vendor TAC to consider wrong situation with assignment of IP addresses like xxx.xxx.xxx.0 and xxx.xxx.xxx.255 from dynamic IP pools bigger than or equal to /24.
Quick googling has not shown any STD or BCP documents, which could be used as reference, but has shown number of pages, saying something like "do not use .0 or .255 addresses, it could cause problems".
Without doubt, the pools must be bigger than /24 in order for .0 or .255 to be used as host addresses. Never tried it personally, but I can see no reason why .0.255 or .1.0 wouldn't be usable in a .0.0/23 - obviously assuming that you pass /23 to the hosts as a netmask.
Jon
Jon Lawrence wrote:
On Sunday 12 September 2004 18:05, Volodymyr Yakovenko wrote:
Dear Colleagues,
I am trying to push one BIG telecom equipment vendor TAC to consider wrong situation with assignment of IP addresses like xxx.xxx.xxx.0 and xxx.xxx.xxx.255 from dynamic IP pools bigger than or equal to /24.
Quick googling has not shown any STD or BCP documents, which could be used as reference, but has shown number of pages, saying something like "do not use .0 or .255 addresses, it could cause problems".
Without doubt, the pools must be bigger than /24 in order for .0 or .255 to be used as host addresses. Never tried it personally, but I can see no reason why .0.255 or .1.0 wouldn't be usable in a .0.0/23 - obviously assuming that you pass /23 to the hosts as a netmask.
The main problem is the classfull behavior of windows tcp/ip stack and DUN for the ipcp negotiated address. It's sure that you can't use network and broadcast address of an old natural network if running MS Windows & DUN. Assingnament of the correct netmask can't be used as workaround because in traditional ppp the mask is not negotiated ( netmask assignament in ipcp is a very new feature ). Félix
participants (7)
-
Florian Weimer -
Félix Izquierdo -
Gert Doering -
Jarno Lähteenmäki -
Jerome Fleury -
Jon Lawrence -
Volodymyr Yakovenko