RE: rfc1918 ignorant (fwd)

[Darren Bolding]

Unfortunately, the vast majority of Cable modems use the private ("CM"
or "Docsis") MAC address for management and present the primary ("CPE")
MAC address to attached equipment.

E.G.- a cable provider has two DHCP scopes configured- a.b.c.d (RFC
1918) and w.x.y.z (Public Space).  In Cisco land at least, the CMTS is
configured with "cable-helper" which relays the CM MAC address to the
DHCP server from the primary address of the Cable Interface and the CPE
MAC Address is relayed from the secondary address of the Cable
Interface.

The CM interface is used for management of the system and such- a key
example is to transfer the DOCSIS configuration file which does things
such as setting rate limits, QoS parameters and lots of other parameters
dreamt up by cable-labs.  

The utility of this design is something I will choose to avoid
commenting on at this time.

--D

--
--  Darren Bolding

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Haesu
> Sent: Wednesday, July 23, 2003 5:10 PM
> To: [EMAIL PROTECTED]
> Subject: Re: rfc1918 ignorant (fwd)
> 
> 
> 
> Well, if uBR showing RFC1918 address out on the traceroute is 
> an issue, why not just reverse the way its configured?
> 
> Put RFC1918 as secondary, and put the routable addr as 
> primary. Either way, it should work w/o issues, right?
> 
> I know quite a few people who purposely put a non-routable IP 
> (whether it be 1918 or RIR-registered block) as primary on 
> their interface, and use routable IP as secondary. Their 
> reason for doing this is to somewhat "hide" their router's 
> real interface IP from showing up in traceroute.. Well, it wouldn't 
> completely 'hide' it, but to a certain level of degree, it 
> probably does...
> 
> -hc
> 
> -- 
> Sincerely,
>   Haesu C.
>   TowardEX Technologies, Inc.
>   WWW: http://www.towardex.com
>   E-mail: [EMAIL PROTECTED]
>   Cell: (978) 394-2867
> 
> On Wed, Jul 23, 2003 at 07:21:25PM -0400, Jeff Wasilko wrote:
> > 
> > On Wed, Jul 23, 2003 at 06:03:13PM -0400, Daniel Senie wrote:
> > > At 02:11 PM 7/23/2003, Dave Temkin wrote:
> > > 
> > > >2003 7:07 AM:]
> > > >> Comcast and many others seem to
> > > >> blithely ignore this for convenience sake. (It's not like they 
> > > >> need a huge amount of space to give private addresses to these 
> > > >> links.)
> > > >
> > > >ARIN required cable operators to use RFC 1918 space for the 
> > > >management agents of the bridge cable modems that have 
> been rolled 
> > > >out to the millions of residential cable modem 
> customers.  Doing so 
> > > >obviously requires a 1918 address on the cable router, 
> but Cisco's 
> > > >implementation requires that address to be the primary interface 
> > > >address.  There is also a publicly routable secondary 
> which in fact 
> > > >is the gateway address to the customer, but isn't the address 
> > > >returned in a traceroute.  Cisco has by far the lead in market 
> > > >share of the first gen Docsis cable modem router market so any 
> > > >trace to a cable modem customer is going to show this.
> > > 
> > > When MediaOne (remember them?) deployed the cable modems here 
> > > (LanCity
> > > stuff, originally), traceroutes did NOT show the 10/8 
> address from the 
> > > router at the head end. ATT bought MediaOne, and now 
> we've got Comcast. The 
> > > service quality has stayed low, and the price has jumped 
> quite a bit, and 
> > > somewhere along the line a change happened and the 10/8 
> address of the 
> > > router did start showing up. Now it's possible the router 
> in the head end 
> > > got changed and that was the cause. I really don't know.
> > 
> > That's exactly what happened. The Lancity equipment were 
> bridges, so 
> > you never saw them in traceroutes. The head-end bridges were 
> > aggregated into switches which were connected to routers.
> > 
> > The Cisco uBR is a router, so you see the cable interface (which is 
> > typically rfc1918 space) showing up in traceroutes from the 
> CPE out. 
> > Note that you don't see it on traceroutes towards the CPE since you 
> > see the 'internet facing' interface on the uBR.
> > 
> > -j
> 
> 

Re: rfc1918 ignorant (fwd)

[Haesu]

> 
> Hmm this could affect routing protocols which use the primary address.. 
> 

I haven't tried doing that with igp protocols.. But with BGP, it works does
manage to bind itself to the working address. (Or if you are sourcing update
to loopback, that would be fine too)

> 
> Right but this one benefit doesnt make right the wrongs!
> 
> I guess one thing you could do (if you really wanted to implement hacks) is to 
> use the rfc1918 space on your routers and then nat them to a global ip at your 
> borders.. achieves all your goals anyhow (not that i'd recommend it ;)

The thing is... some people want to hide the IP of the interface that faces
their transit on the border router, as most /30 demarcation subnet is assigned
from the transit. And since they would run either bgp or static route between
the transit and their border router, it shouldn't break routing..

-hc

-- 
Sincerely,
  Haesu C.
  TowardEX Technologies, Inc.
  WWW: http://www.towardex.com
  E-mail: [EMAIL PROTECTED]
  Cell: (978) 394-2867

Re: rfc1918 ignorant (fwd)

[Stephen J. Wilcox]

On Wed, 23 Jul 2003, Haesu wrote:

> Well, if uBR showing RFC1918 address out on the traceroute is an issue, why not
> just reverse the way its configured?
> 
> Put RFC1918 as secondary, and put the routable addr as primary. Either way, it
> should work w/o issues, right?

Hmm this could affect routing protocols which use the primary address.. 

> I know quite a few people who purposely put a non-routable IP (whether it be
> 1918 or RIR-registered block) as primary on their interface, and use routable
> IP as secondary. Their reason for doing this is to somewhat "hide" their
> router's real interface IP from showing up in traceroute.. Well, it wouldn't 
> completely 'hide' it, but to a certain level of degree, it probably does...

Right but this one benefit doesnt make right the wrongs!

I guess one thing you could do (if you really wanted to implement hacks) is to 
use the rfc1918 space on your routers and then nat them to a global ip at your 
borders.. achieves all your goals anyhow (not that i'd recommend it ;)

Re: rfc1918 ignorant (fwd)

[Haesu]

Well, if uBR showing RFC1918 address out on the traceroute is an issue, why not
just reverse the way its configured?

Put RFC1918 as secondary, and put the routable addr as primary. Either way, it
should work w/o issues, right?

I know quite a few people who purposely put a non-routable IP (whether it be
1918 or RIR-registered block) as primary on their interface, and use routable
IP as secondary. Their reason for doing this is to somewhat "hide" their
router's real interface IP from showing up in traceroute.. Well, it wouldn't 
completely 'hide' it, but to a certain level of degree, it probably does...

-hc

-- 
Sincerely,
  Haesu C.
  TowardEX Technologies, Inc.
  WWW: http://www.towardex.com
  E-mail: [EMAIL PROTECTED]
  Cell: (978) 394-2867

On Wed, Jul 23, 2003 at 07:21:25PM -0400, Jeff Wasilko wrote:
> 
> On Wed, Jul 23, 2003 at 06:03:13PM -0400, Daniel Senie wrote:
> > At 02:11 PM 7/23/2003, Dave Temkin wrote:
> > 
> > >2003 7:07 AM:]
> > >> Comcast and many others seem to
> > >> blithely ignore this for convenience sake. (It's not like they need a
> > >> huge amount of space to give private addresses to these links.)
> > >
> > >ARIN required cable operators to use RFC 1918 space for the management
> > >agents of the bridge cable modems that have been rolled out to the millions
> > >of residential cable modem customers.  Doing so obviously requires a 1918
> > >address on the cable router, but Cisco's implementation requires that
> > >address to be the primary interface address.  There is also a publicly
> > >routable secondary which in fact is the gateway address to the customer, 
> > >but
> > >isn't the address returned in a traceroute.  Cisco has by far the lead in
> > >market share of the first gen Docsis cable modem router market so any trace
> > >to a cable modem customer is going to show this.
> > 
> > When MediaOne (remember them?) deployed the cable modems here (LanCity 
> > stuff, originally), traceroutes did NOT show the 10/8 address from the 
> > router at the head end. ATT bought MediaOne, and now we've got Comcast. The 
> > service quality has stayed low, and the price has jumped quite a bit, and 
> > somewhere along the line a change happened and the 10/8 address of the 
> > router did start showing up. Now it's possible the router in the head end 
> > got changed and that was the cause. I really don't know.
> 
> That's exactly what happened. The Lancity equipment were bridges,
> so you never saw them in traceroutes. The head-end bridges were
> aggregated into switches which were connected to routers. 
> 
> The Cisco uBR is a router, so you see the cable interface (which
> is typically rfc1918 space) showing up in traceroutes from the CPE out. 
> Note that you don't see it on traceroutes towards the CPE since you see 
> the 'internet facing' interface on the uBR.
> 
> -j

Re: rfc1918 ignorant (fwd)

[Jeff Wasilko]

On Wed, Jul 23, 2003 at 06:03:13PM -0400, Daniel Senie wrote:
> At 02:11 PM 7/23/2003, Dave Temkin wrote:
> 
> >2003 7:07 AM:]
> >> Comcast and many others seem to
> >> blithely ignore this for convenience sake. (It's not like they need a
> >> huge amount of space to give private addresses to these links.)
> >
> >ARIN required cable operators to use RFC 1918 space for the management
> >agents of the bridge cable modems that have been rolled out to the millions
> >of residential cable modem customers.  Doing so obviously requires a 1918
> >address on the cable router, but Cisco's implementation requires that
> >address to be the primary interface address.  There is also a publicly
> >routable secondary which in fact is the gateway address to the customer, 
> >but
> >isn't the address returned in a traceroute.  Cisco has by far the lead in
> >market share of the first gen Docsis cable modem router market so any trace
> >to a cable modem customer is going to show this.
> 
> When MediaOne (remember them?) deployed the cable modems here (LanCity 
> stuff, originally), traceroutes did NOT show the 10/8 address from the 
> router at the head end. ATT bought MediaOne, and now we've got Comcast. The 
> service quality has stayed low, and the price has jumped quite a bit, and 
> somewhere along the line a change happened and the 10/8 address of the 
> router did start showing up. Now it's possible the router in the head end 
> got changed and that was the cause. I really don't know.

That's exactly what happened. The Lancity equipment were bridges,
so you never saw them in traceroutes. The head-end bridges were
aggregated into switches which were connected to routers. 

The Cisco uBR is a router, so you see the cable interface (which
is typically rfc1918 space) showing up in traceroutes from the CPE out. 
Note that you don't see it on traceroutes towards the CPE since you see 
the 'internet facing' interface on the uBR.

-j

RE: rfc1918 ignorant (fwd)

[Daniel Senie]

At 02:11 PM 7/23/2003, Dave Temkin wrote:

-- Forwarded message --
Date: Wed, 23 Jul 2003 07:53:26 -1000
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: rfc1918 ignorant
There's a common misconception reflected here that I wanted to correct.  I
don't have nanog-post, so I apologize if its not appropriate to reply
directly.  You may repost my comments if you'd like.
[Kevin Oberman  wrote on Wednesday, July 23,
2003 7:07 AM:]
> Comcast and many others seem to
> blithely ignore this for convenience sake. (It's not like they need a
> huge amount of space to give private addresses to these links.)
ARIN required cable operators to use RFC 1918 space for the management
agents of the bridge cable modems that have been rolled out to the millions
of residential cable modem customers.  Doing so obviously requires a 1918
address on the cable router, but Cisco's implementation requires that
address to be the primary interface address.  There is also a publicly
routable secondary which in fact is the gateway address to the customer, but
isn't the address returned in a traceroute.  Cisco has by far the lead in
market share of the first gen Docsis cable modem router market so any trace
to a cable modem customer is going to show this.
When MediaOne (remember them?) deployed the cable modems here (LanCity 
stuff, originally), traceroutes did NOT show the 10/8 address from the 
router at the head end. ATT bought MediaOne, and now we've got Comcast. The 
service quality has stayed low, and the price has jumped quite a bit, and 
somewhere along the line a change happened and the 10/8 address of the 
router did start showing up. Now it's possible the router in the head end 
got changed and that was the cause. I really don't know.


In fact, Comcast and others _do_ need a huge amount of private IP space
because of this.  We didn't "blithely ignore" the RFC, but didn't have a
choice in implementation.  Perhaps Cisco will improve their implementation
for the next round of CMTS development...
Perhaps Comcast and others should INSIST that Cisco fix their bug, rather 
than just wish for a fix. Cable companies are buying lots of gear from 
them. Why not use that purchasing muscle to get this issue resolved? Or are 
the cable companies really interested in selling Internet service, or an 
"online service" like AOL? At some point, if you're going to sell Internet 
Service, it'd be nice if Internet standards and requirements are met.


Filtering of RFC 1918 space by cable ISPs is of course another topic.

-Doug-

[Kevin Oberman  wrote on Wednesday, July 23,
2003 7:07 AM:]
>> Date: Wed, 23 Jul 2003 08:59:18 -0400 (EDT)
>> From: Dave Temkin <[EMAIL PROTECTED]>
>> Sender: [EMAIL PROTECTED]
>>
>>
>> Is this really an issue?  So long as they're not advertising the
>> space I see no issue with routing traffic through a 10. network as
>> transit. If you have no reason to reach their router directly (and
>> after Cisco's last exploit, I'd think no one would want anyone to
>> reach their router directly :-) ), what's the harm done?
>>
>> RFC1918 merely states that it shouldn't be routed on the global
>> internet, not that it can't be used for transit space.
>
> That's not what is in my copy of 1918.
>
> "In order to use private address space, an enterprise needs to
> determine which hosts do not need to have network layer connectivity
> outside the enterprise in the foreseeable future and thus could be
> classified as private. Such hosts will use the private address space
> defined above.  Private hosts can communicate with all other hosts
> inside the enterprise, both public and private. However, they cannot
> have IP connectivity to any host outside of the enterprise. While not
> having external (outside of the enterprise) IP connectivity private
> hosts can still have access to external services via mediating
> gateways (e.g., application layer gateways)."
>
> As I read this, packets with a source address in 19298 space should
> NEVER appear outside the enterprise. Comcast and many others seem to
> blithely ignore this for convenience sake. (It's not like they need a
> huge amount of space to give private addresses to these links.)

RE: rfc1918 ignorant (fwd)

[Randy Bush]

> ARIN required cable operators to use RFC 1918 space for the management
> agents of the bridge cable modems that have been rolled out to the
> millions of residential cable modem customers.

this would be really amazing, as it would have required a time machine.
the cable build was before arin existed.

randy

Re: rfc1918 ignorant (fwd)

[Petri Helenius]

So this, as many other discussions in the past, ends with the conclusion
that ARIN did their share of breaking RFC´s and the Internet ?

Pete

- Original Message - 
From: "Dave Temkin" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 23, 2003 9:11 PM
Subject: RE: rfc1918 ignorant (fwd)


>
> -- Forwarded message --
> Date: Wed, 23 Jul 2003 07:53:26 -1000
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: RE: rfc1918 ignorant
>
> There's a common misconception reflected here that I wanted to correct.  I
> don't have nanog-post, so I apologize if its not appropriate to reply
> directly.  You may repost my comments if you'd like.
>
> [Kevin Oberman <mailto:[EMAIL PROTECTED]> wrote on Wednesday, July 23,
> 2003 7:07 AM:]
> > Comcast and many others seem to
> > blithely ignore this for convenience sake. (It's not like they need a
> > huge amount of space to give private addresses to these links.)
>
> ARIN required cable operators to use RFC 1918 space for the management
> agents of the bridge cable modems that have been rolled out to the millions
> of residential cable modem customers.  Doing so obviously requires a 1918
> address on the cable router, but Cisco's implementation requires that
> address to be the primary interface address.  There is also a publicly
> routable secondary which in fact is the gateway address to the customer, but
> isn't the address returned in a traceroute.  Cisco has by far the lead in
> market share of the first gen Docsis cable modem router market so any trace
> to a cable modem customer is going to show this.
>
> In fact, Comcast and others _do_ need a huge amount of private IP space
> because of this.  We didn't "blithely ignore" the RFC, but didn't have a
> choice in implementation.  Perhaps Cisco will improve their implementation
> for the next round of CMTS development...
>
> Filtering of RFC 1918 space by cable ISPs is of course another topic.
>
> -Doug-
>
> [Kevin Oberman <mailto:[EMAIL PROTECTED]> wrote on Wednesday, July 23,
> 2003 7:07 AM:]
> >> Date: Wed, 23 Jul 2003 08:59:18 -0400 (EDT)
> >> From: Dave Temkin <[EMAIL PROTECTED]>
> >> Sender: [EMAIL PROTECTED]
> >>
> >>
> >> Is this really an issue?  So long as they're not advertising the
> >> space I see no issue with routing traffic through a 10. network as
> >> transit. If you have no reason to reach their router directly (and
> >> after Cisco's last exploit, I'd think no one would want anyone to
> >> reach their router directly :-) ), what's the harm done?
> >>
> >> RFC1918 merely states that it shouldn't be routed on the global
> >> internet, not that it can't be used for transit space.
> >
> > That's not what is in my copy of 1918.
> >
> > "In order to use private address space, an enterprise needs to
> > determine which hosts do not need to have network layer connectivity
> > outside the enterprise in the foreseeable future and thus could be
> > classified as private. Such hosts will use the private address space
> > defined above.  Private hosts can communicate with all other hosts
> > inside the enterprise, both public and private. However, they cannot
> > have IP connectivity to any host outside of the enterprise. While not
> > having external (outside of the enterprise) IP connectivity private
> > hosts can still have access to external services via mediating
> > gateways (e.g., application layer gateways)."
> >
> > As I read this, packets with a source address in 19298 space should
> > NEVER appear outside the enterprise. Comcast and many others seem to
> > blithely ignore this for convenience sake. (It's not like they need a
> > huge amount of space to give private addresses to these links.)
>

RE: rfc1918 ignorant (fwd)

[Dave Temkin]

-- Forwarded message --
Date: Wed, 23 Jul 2003 07:53:26 -1000
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: rfc1918 ignorant

There's a common misconception reflected here that I wanted to correct.  I
don't have nanog-post, so I apologize if its not appropriate to reply
directly.  You may repost my comments if you'd like.

[Kevin Oberman  wrote on Wednesday, July 23,
2003 7:07 AM:]
> Comcast and many others seem to
> blithely ignore this for convenience sake. (It's not like they need a
> huge amount of space to give private addresses to these links.)

ARIN required cable operators to use RFC 1918 space for the management
agents of the bridge cable modems that have been rolled out to the millions
of residential cable modem customers.  Doing so obviously requires a 1918
address on the cable router, but Cisco's implementation requires that
address to be the primary interface address.  There is also a publicly
routable secondary which in fact is the gateway address to the customer, but
isn't the address returned in a traceroute.  Cisco has by far the lead in
market share of the first gen Docsis cable modem router market so any trace
to a cable modem customer is going to show this.

In fact, Comcast and others _do_ need a huge amount of private IP space
because of this.  We didn't "blithely ignore" the RFC, but didn't have a
choice in implementation.  Perhaps Cisco will improve their implementation
for the next round of CMTS development...

Filtering of RFC 1918 space by cable ISPs is of course another topic.

-Doug-

[Kevin Oberman  wrote on Wednesday, July 23,
2003 7:07 AM:]
>> Date: Wed, 23 Jul 2003 08:59:18 -0400 (EDT)
>> From: Dave Temkin <[EMAIL PROTECTED]>
>> Sender: [EMAIL PROTECTED]
>>
>>
>> Is this really an issue?  So long as they're not advertising the
>> space I see no issue with routing traffic through a 10. network as
>> transit. If you have no reason to reach their router directly (and
>> after Cisco's last exploit, I'd think no one would want anyone to
>> reach their router directly :-) ), what's the harm done?
>>
>> RFC1918 merely states that it shouldn't be routed on the global
>> internet, not that it can't be used for transit space.
>
> That's not what is in my copy of 1918.
>
> "In order to use private address space, an enterprise needs to
> determine which hosts do not need to have network layer connectivity
> outside the enterprise in the foreseeable future and thus could be
> classified as private. Such hosts will use the private address space
> defined above.  Private hosts can communicate with all other hosts
> inside the enterprise, both public and private. However, they cannot
> have IP connectivity to any host outside of the enterprise. While not
> having external (outside of the enterprise) IP connectivity private
> hosts can still have access to external services via mediating
> gateways (e.g., application layer gateways)."
>
> As I read this, packets with a source address in 19298 space should
> NEVER appear outside the enterprise. Comcast and many others seem to
> blithely ignore this for convenience sake. (It's not like they need a
> huge amount of space to give private addresses to these links.)