* [Cerowrt-devel] CeroWrt port numbering [not found] <mailman.2.1330632002.8558.cerowrt-devel@lists.bufferbloat.net> @ 2012-03-02 4:22 ` Richard Brown 2012-03-02 10:50 ` Dave Taht 0 siblings, 1 reply; 6+ messages in thread From: Richard Brown @ 2012-03-02 4:22 UTC (permalink / raw) To: <cerowrt-devel@lists.bufferbloat.net> [-- Attachment #1: Type: text/plain, Size: 1841 bytes --] While I was posting a note about 3.3-rc5-1 and tidying the site, I noticed that the table on the Default Network Numbering page (http://www.bufferbloat.net/projects/cerowrt/wiki/Default_network_numbering) was incorrect - it still showed the default se00 at 172.30.42.33. It's fixed. I also added a row for ge00 as the public IP. This led me to look at the various tables made available via SNMP, and I had a couple consistency questions. (See the attached spreadsheet for the data, especially rows 58-66. It was taken from bql-40, but I believe it's the same for 3.3.) - I note that there's no interface at 172.30.42.33/27. I believe this is correct, but just checking. (It's thinkable that the se00 wired interface could go to a /26 if more wired devices were needed. But let's keep to the rule "Everything's a /27" for a while longer.) - I'm a little surprised that the babel interfaces both have ...224/32. (But I don't know anything about babel...) - I'm confused about the OUI's for the interfaces. As expected, C4:3D:C7... is the OUI for Netgear. But C6:3D:C7... isn't allocated to anyone. Is that by design? - I don't understand the pattern of the OUIs for the interfaces: why is the C4 prefix issued to the Ethernet ge00 and wireless sw00 and sw10, while C6 goes to Ethernet se00 and the remaining wireless interfaces? - I also note that the MAC addresses sort to an odd order, intermixing ethernet and wireless. (This is related to the previous item.) sw00 C4:3D:C7:9D:E3:9A ge00 C4:3D:C7:9D:E3:9B sw10 C4:3D:C7:9D:E3:9C se00 C6:3D:C7:9D:E3:9A gw00 C6:3D:C7:9D:E3:9B gw01 C6:3D:C7:9D:E3:9C gw10 C6:3D:C7:9D:E3:9D gw11 C6:3D:C7:9D:E3:9E - Finally, I haven't fired up 6to4 or anything, but will the global IP address assignments be randomized more than the local (fe80) addresses? Best, Rich [-- Attachment #2: CeroWrt Ports-BQL40.xlsx --] [-- Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet, Size: 43068 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Cerowrt-devel] CeroWrt port numbering 2012-03-02 4:22 ` [Cerowrt-devel] CeroWrt port numbering Richard Brown @ 2012-03-02 10:50 ` Dave Taht 2012-03-02 15:37 ` Richard Brown 0 siblings, 1 reply; 6+ messages in thread From: Dave Taht @ 2012-03-02 10:50 UTC (permalink / raw) To: Richard Brown; +Cc: <cerowrt-devel@lists.bufferbloat.net> On Thu, Mar 1, 2012 at 8:22 PM, Richard Brown <richard.e.brown@dartware.com> wrote: > While I was posting a note about 3.3-rc5-1 and tidying the site, I noticed that the table on the Default Network Numbering page (http://www.bufferbloat.net/projects/cerowrt/wiki/Default_network_numbering) was incorrect - it still showed the default se00 at 172.30.42.33. It's fixed. I also added a row for ge00 as the public IP. thx! > > This led me to look at the various tables made available via SNMP, and I had a couple consistency questions. (See the attached spreadsheet for the data, especially rows 58-66. It was taken from bql-40, but I believe it's the same for 3.3.) I won't be able to look into the snmp stuff until next week. I'd like to know how well that is working with ipv6, btw, overall. > > - I note that there's no interface at 172.30.42.33/27. I believe this is correct, but just checking. (It's thinkable that the se00 wired interface could go to a /26 if more wired devices were needed. But let's keep to the rule "Everything's a /27" for a while longer.) I thought about widening the default /27 in this case, but long on my mind has been getting to where vlans could be successfully used and tested, so mentally that's 'reserved for dmz vlan'. This was actually why .33 was used instead of .1 for the main router interface in the early days, but too many people found that puzzling. > > - I'm a little surprised that the babel interfaces both have ...224/32. (But I don't know anything about babel...) Actually that's an 'AHCP'-ism. Babel is capable of mesh routing, and with p2p wireless links nothing more than a /32 or /128 (for ipv6) is needed to be distributed on mesh node links. It makes failover simpler in the mesh routing case. > > - I'm confused about the OUI's for the interfaces. As expected, C4:3D:C7... is the OUI for Netgear. But C6:3D:C7... isn't allocated to anyone. Is that by design? Two issues: There is no separate mac address for one of the network devices on the wndr, so we take a known good address from one of the devices, and flip the 'local mac' bit. Each wireless VIF creates it's own mac address as well, based on incrementing the underlying mac, and I don't remember the algo offhand. > > - I don't understand the pattern of the OUIs for the interfaces: why is the C4 prefix issued to the Ethernet ge00 and wireless sw00 and sw10, while C6 goes to Ethernet se00 and the remaining wireless interfaces? > > - I also note that the MAC addresses sort to an odd order, intermixing ethernet and wireless. (This is related to the previous item.) > > sw00 C4:3D:C7:9D:E3:9A > ge00 C4:3D:C7:9D:E3:9B > sw10 C4:3D:C7:9D:E3:9C > > se00 C6:3D:C7:9D:E3:9A > gw00 C6:3D:C7:9D:E3:9B > gw01 C6:3D:C7:9D:E3:9C > gw10 C6:3D:C7:9D:E3:9D > gw11 C6:3D:C7:9D:E3:9E Hopefully what I wrote above sort of explains this. > - Finally, I haven't fired up 6to4 or anything, but will the global IP address assignments be randomized more than the local (fe80) address? Not sure what you mean here. In the case of ipv6 autoconfiguration, you get EUI-64s based on the underlying mac addresses, which are long... In the case of 6to4 autoassignment ( the openwrt feature that didn't work for me in this week's test), each interface gets a 2002:X:Y:Z::1/64 where Z=1 for se00, and increments by one for every interface configured for the ge01 device. In the case of using dhcp-pd youu can either use ipv6 autoconfiguration for the downstream nodes, or install a dhcpv6 server to give more rationally numbered clients. > > Best, > > Rich > > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > -- Dave Täht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Cerowrt-devel] CeroWrt port numbering 2012-03-02 10:50 ` Dave Taht @ 2012-03-02 15:37 ` Richard Brown 2012-03-02 15:56 ` Dave Taht 0 siblings, 1 reply; 6+ messages in thread From: Richard Brown @ 2012-03-02 15:37 UTC (permalink / raw) To: Dave Taht; +Cc: Richard Brown, <cerowrt-devel@lists.bufferbloat.net> >> This led me to look at the various tables made available via SNMP, and I had a couple consistency questions. (See the attached spreadsheet for the data, especially rows 58-66. It was taken from bql-40, but I believe it's the same for 3.3.) > > I won't be able to look into the snmp stuff until next week. > I'd like to know how well that is working with ipv6, btw, overall. I don't (yet) have facilities for testing IPv6 here, so I can't offer any advice >> - I note that there's no interface at 172.30.42.33/27. I believe this is correct, but just checking. (It's thinkable that the se00 wired interface could go to a /26 if more wired devices were needed. But let's keep to the rule "Everything's a /27" for a while longer.) > > I thought about widening the default /27 in this case, but long on my > mind has been getting to where vlans could be successfully used and > tested, so mentally that's 'reserved for > dmz vlan'. This was actually why .33 was used instead of .1 for the > main router interface in the early days, but too many people found > that puzzling. Good choices (both reserving for dmz vlan and switching to .1) >> - I'm a little surprised that the babel interfaces both have ...224/32. (But I don't know anything about babel...) > > Actually that's an 'AHCP'-ism. Babel is capable of mesh routing, and > with p2p wireless links nothing more than a /32 or /128 (for ipv6) is > needed to be distributed on mesh node links. > > It makes failover simpler in the mesh routing case. I was just curious whether they were meant to be the same /32 address... >> - I'm confused about the OUI's for the interfaces. As expected, C4:3D:C7... is the OUI for Netgear. But C6:3D:C7... isn't allocated to anyone. Is that by design? > > Two issues: > > There is no separate mac address for one of the network devices on the > wndr, so we take a known good address from one of the devices, and > flip the 'local mac' bit. Ahah. I learn something every day. The 0x02 bit of the most significant byte is the "local" bit; the 0x01 bit is the multicast bit. See: http://en.wikipedia.org/wiki/Organizationally_Unique_Identifier > Each wireless VIF creates it's own mac address as well, based on > incrementing the underlying mac, and I don't remember the algo > offhand. Yes, that makes sense. But... I still don't understand the reasoning behind the mix and match (see list below). Why wouldn't you put all the wireless together as C4:... and Ethernet on the other? Or divide by 2.4GHz or 5GHz? or Secure vs. Guest, or some other scheme? (Or is it purposely to prevent people like me from imputing meaning where none is needed? :-) >> - I don't understand the pattern of the OUIs for the interfaces: why is the C4 prefix issued to the Ethernet ge00 and wireless sw00 and sw10, while C6 goes to Ethernet se00 and the remaining wireless interfaces? >> >> - I also note that the MAC addresses sort to an odd order, intermixing ethernet and wireless. (This is related to the previous item.) >> >> sw00 C4:3D:C7:9D:E3:9A >> ge00 C4:3D:C7:9D:E3:9B >> sw10 C4:3D:C7:9D:E3:9C >> >> se00 C6:3D:C7:9D:E3:9A >> gw00 C6:3D:C7:9D:E3:9B >> gw01 C6:3D:C7:9D:E3:9C >> gw10 C6:3D:C7:9D:E3:9D >> gw11 C6:3D:C7:9D:E3:9E > > Hopefully what I wrote above sort of explains this. > >> - Finally, I haven't fired up 6to4 or anything, but will the global IP address assignments be randomized more than the local (fe80) address? > > Not sure what you mean here. Privacy advocates are saying that the "easy way" to create a global IPv6 address is bad: it's too easy to plop the MAC address in the lower 64 bits of your address, and then the bad guys can use that as another (really powerful) tracking identifier. This is clearly not a CeroWrt-specific issue, and it's actively in discussion. (See, for example Barrera et al, in the Usenix Vol 36, Number 1, https://www.usenix.org/system/files/login/articles/105438-Barrera.pdf ) Thanks! Rich ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Cerowrt-devel] CeroWrt port numbering 2012-03-02 15:37 ` Richard Brown @ 2012-03-02 15:56 ` Dave Taht 2012-03-02 16:26 ` Dave Taht 0 siblings, 1 reply; 6+ messages in thread From: Dave Taht @ 2012-03-02 15:56 UTC (permalink / raw) To: Richard Brown; +Cc: <cerowrt-devel@lists.bufferbloat.net> On Fri, Mar 2, 2012 at 7:37 AM, Richard Brown <richard.e.brown@dartware.com> wrote: > > I don't (yet) have facilities for testing IPv6 here, so I can't offer any advice I'm going to get to where I have a ula generating script to make that easier. soon. (unfinished draft in ceropackages/ipv6/ipv6policy) >>> - I'm a little surprised that the babel interfaces both have ...224/32. (But I don't know anything about babel...) >> >> Actually that's an 'AHCP'-ism. Babel is capable of mesh routing, and >> with p2p wireless links nothing more than a /32 or /128 (for ipv6) is >> needed to be distributed on mesh node links. >> >> It makes failover simpler in the mesh routing case. > > I was just curious whether they were meant to be the same /32 address... yes. The routing scheme figures out the right interface with using the /32 or a /128 on the same ip. www.pps.jussieu.fr/~jch/software/babel/wbmv4.pdf I'd been doing mesh networking for a long time prior to this project. I still find it kind of wierd to disconnect from my wired interface and go wireless and lose all my ssh connections. Others seem to find this normal, but it makes me mildly nuts. with a full mesh config, which is not the default cero can fails over to wireless in a split second, moves back to wired in a few seconds when you plug in the wired connection, no connection loss, no muss no fuss. > >>> - I'm confused about the OUI's for the interfaces. As expected, C4:3D:C7... is the OUI for Netgear. But C6:3D:C7... isn't allocated to anyone. Is that by design? >> >> Two issues: >> >> There is no separate mac address for one of the network devices on the >> wndr, so we take a known good address from one of the devices, and >> flip the 'local mac' bit. > > Ahah. I learn something every day. The 0x02 bit of the most significant byte is the "local" bit; the 0x01 bit is the multicast bit. See: http://en.wikipedia.org/wiki/Organizationally_Unique_Identifier > >> Each wireless VIF creates it's own mac address as well, based on >> incrementing the underlying mac, and I don't remember the algo >> offhand. > > Yes, that makes sense. But... > > I still don't understand the reasoning behind the mix and match (see list below). Why wouldn't you put all the wireless together as C4:... and Ethernet on the other? Or divide by 2.4GHz or 5GHz? or Secure vs. Guest, or some other scheme? (Or is it purposely to prevent people like me from imputing meaning where none is needed? :-) I think your diagnosis is correct. >>> - I don't understand the pattern of the OUIs for the interfaces: why is the C4 prefix issued to the Ethernet ge00 and wireless sw00 and sw10, while C6 goes to Ethernet se00 and the remaining wireless interfaces? >>> >>> - I also note that the MAC addresses sort to an odd order, intermixing ethernet and wireless. (This is related to the previous item.) >>> >>> sw00 C4:3D:C7:9D:E3:9A >>> ge00 C4:3D:C7:9D:E3:9B >>> sw10 C4:3D:C7:9D:E3:9C >>> >>> se00 C6:3D:C7:9D:E3:9A >>> gw00 C6:3D:C7:9D:E3:9B >>> gw01 C6:3D:C7:9D:E3:9C >>> gw10 C6:3D:C7:9D:E3:9D >>> gw11 C6:3D:C7:9D:E3:9E >> >> Hopefully what I wrote above sort of explains this. >> >>> - Finally, I haven't fired up 6to4 or anything, but will the global IP address assignments be randomized more than the local (fe80) address? >> >> Not sure what you mean here. > > Privacy advocates are saying that the "easy way" to create a global IPv6 address is bad: it's too easy to plop the MAC address in the lower 64 bits of your address, and then the bad guys can use that as another (really powerful) tracking identifier. This is clearly not a CeroWrt-specific issue, and it's actively in discussion. (See, for example Barrera et al, in the Usenix Vol 36, Number 1, https://www.usenix.org/system/files/login/articles/105438-Barrera.pdf ) This debate has been going on for a decade. I would like all those trying to make ipv6 even harder for mere mortals to use to go off and work on ipv7, hip, and the like. DNS naming has been hopelessly screwed up as it is, and while I'm a big privacy advocate, I'd like ip addresses to be mapped to DNS names and I figure that that will bug that crowd, too. See also 'dname debacle' http://www.ietf.org/mail-archive/web/ipv6/current/msg08079.html > Thanks! > > Rich > > -- Dave Täht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Cerowrt-devel] CeroWrt port numbering 2012-03-02 15:56 ` Dave Taht @ 2012-03-02 16:26 ` Dave Taht 2012-03-02 16:51 ` Dave Taht 0 siblings, 1 reply; 6+ messages in thread From: Dave Taht @ 2012-03-02 16:26 UTC (permalink / raw) To: Richard Brown; +Cc: <cerowrt-devel@lists.bufferbloat.net> >> Privacy advocates are saying that the "easy way" to create a global IPv6 address is bad: it's too easy to plop the MAC address in the lower 64 bits of your address, and then the bad guys can use that as another (really powerful) tracking identifier. This is clearly not a CeroWrt-specific issue, and it's actively in discussion. (See, for example Barrera et al, in the Usenix Vol 36, Number 1, https://www.usenix.org/system/files/login/articles/105438-Barrera.pdf ) > > This debate has been going on for a decade. > > I would like all those trying to make ipv6 even harder for mere > mortals to use to go off and work on ipv7, hip, and the like. > > DNS naming has been hopelessly screwed up as it is, and while I'm a > big privacy advocate, I'd like ip addresses to be mapped to DNS names > and I figure that that will bug that crowd, too. My position on this is considerably more nuanced than I allude to above, but I lack the time today to go into it in detail. briefly. IPv6's one big advantage is restoring end to end connectivity to the internet, this means that ip addresses do 'leak'. However, compared to all the other information that is tracked nowadays leaking that seems rather trivial, and having local connectivity that 'just works' would be nice to have compared to what we have nowadays. For thought-food, why should making a skype call to someone else in your office require a round trip through the internet? From a privacy standpoint there is the existing difference between the 'us' and 'them' views in bind, the plan has been to publish local ipv6 addresses in the 'us' view, and optionally in the them (public) view. the mdns whatever.local convention also applies to ipv6, and happens to work if you have the privacy extensions enabled on your machine, but needs a hook to talk to the local dns server that is standardized somehow.... naming, privacy, and ipv6 are ratholes.... gotta go >> > > > > -- > Dave Täht > SKYPE: davetaht > US Tel: 1-239-829-5608 > http://www.bufferbloat.net -- Dave Täht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Cerowrt-devel] CeroWrt port numbering 2012-03-02 16:26 ` Dave Taht @ 2012-03-02 16:51 ` Dave Taht 0 siblings, 0 replies; 6+ messages in thread From: Dave Taht @ 2012-03-02 16:51 UTC (permalink / raw) To: Richard Brown; +Cc: <cerowrt-devel@lists.bufferbloat.net> On Fri, Mar 2, 2012 at 8:26 AM, Dave Taht <dave.taht@gmail.com> wrote: >>> Privacy advocates are saying that the "easy way" to create a global IPv6 address is bad: it's too easy to plop the MAC address in the lower 64 bits of your address, and then the bad guys can use that as another (really powerful) tracking identifier. This is clearly not a CeroWrt-specific issue, and it's actively in discussion. (See, for example Barrera et al, in the Usenix Vol 36, Number 1, https://www.usenix.org/system/files/login/articles/105438-Barrera.pdf ) >> >> This debate has been going on for a decade. >> >> I would like all those trying to make ipv6 even harder for mere >> mortals to use to go off and work on ipv7, hip, and the like. >> >> DNS naming has been hopelessly screwed up as it is, and while I'm a >> big privacy advocate, I'd like ip addresses to be mapped to DNS names >> and I figure that that will bug that crowd, too. > > My position on this is considerably more nuanced than I allude to > above, but I lack the time today to go into it in detail. > > briefly. > > IPv6's one big advantage is restoring end to end connectivity to the > internet, this means that ip addresses do 'leak'. > > However, compared to all the other information that is tracked > nowadays leaking that seems rather trivial, and having local > connectivity that 'just works' would be nice to have compared to what > we have nowadays. For thought-food, why should making a skype call to > someone else in your office require a round trip through the internet? > > From a privacy standpoint there is the existing difference between the > 'us' and 'them' views in bind, the plan has been > to publish local ipv6 addresses in the 'us' view, and optionally in > the them (public) view. > > the mdns whatever.local convention also applies to ipv6, and happens > to work if you have the privacy extensions enabled on your machine, > but needs a hook to talk to the local dns server that is standardized > somehow.... > > naming, privacy, and ipv6 are ratholes.... > > gotta go and btw, I happen to like the idea of hip http://infrahip.hiit.fi/ and have been meaning to package it up and make it 'just work' for ages. The former seems straightforward, the latter.... also of interest are ipv6 nat (patches being floated around now), ccnx (already packaged), shim6, lisp, mobile-ipv6, etc.... but ENOTIME on my part. >>> >> >> >> >> -- >> Dave Täht >> SKYPE: davetaht >> US Tel: 1-239-829-5608 >> http://www.bufferbloat.net > > > > -- > Dave Täht > SKYPE: davetaht > US Tel: 1-239-829-5608 > http://www.bufferbloat.net -- Dave Täht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-03-02 16:51 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <mailman.2.1330632002.8558.cerowrt-devel@lists.bufferbloat.net>
2012-03-02 4:22 ` [Cerowrt-devel] CeroWrt port numbering Richard Brown
2012-03-02 10:50 ` Dave Taht
2012-03-02 15:37 ` Richard Brown
2012-03-02 15:56 ` Dave Taht
2012-03-02 16:26 ` Dave Taht
2012-03-02 16:51 ` Dave Taht
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox