Re: Joel Jaeggli's Discuss on draft-ietf-6man-ext-transmit-04: (with DISCUSS and COMMENT)

2013-10-08 Thread Roland Bless
Hi Brian, On 08.10.2013 21:45, Brian E Carpenter wrote: > NEW >Today, IPv6 packets are often forwarded not only on the basis of their >first 40 bytes by straightforward IP routing. Some routers, and a >variety of intermediate nodes often referred to as middleboxes, such >as firewal

Re: 6MAN WG Last Call:

2013-07-29 Thread Roland Bless
Hi, On 19.07.2013 00:11, Bob Hinden wrote: > http://tools.ietf.org/html/draft-ietf-6man-ug-01 > > as a Proposed Standard. Substantive comments and statements of support for > advancing this document should be directed to the mailing list. Editorial > suggestions can be sent to the auth

Re: [its] I-D Action: draft-imadali-its-vinipv6-viid-00.txt

2013-04-04 Thread Roland Bless
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 04.04.2013 17:02, Michael Richardson wrote: > I think that imadali-its-vinipv6 is the wrong idea. If it is > useful for a manufacturer to derive a subnet-ID from a VIN, that's > fine, but I think it's a private matter. Let's write a BCP on ho

Re: Confirming consensus on adopting draft-carpenter-6man-ug-01

2013-03-23 Thread Roland Bless
Hi, On 21.03.2013 13:57, Ole Troan wrote: > This message starts a one week 6MAN Working Group call on confirming the > consensus on the mailing list: > http://tools.ietf.org/html/draft-carpenter-6man-ug-01 > > as a Working Group Document. Additional statements of support or opposition > sh

Re: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs

2013-02-20 Thread Roland Bless
Hi Randy, On 20.02.2013 12:09, Randy Bush wrote: >> This is sufficient for the onboard communication network, which was >> the problem we addressed. ULAs are a good match, since these addresses >> should not leak. > > and rfc1918 should not leak Yes, I know in practice they do leak, that's why I

Re: Announcing 2 drafts for VIN-based IPv6 ULA prefixes and IIDs

2013-02-20 Thread Roland Bless
Hi Alex, On 19.02.2013 15:31, Alexandru Petrescu wrote: > I agree privacy is important. > > An alternative method from R. Bless proposes to use a SHA output in the > prefix field of an address. This has an advantage with respect to > privacy - it's hardly feasible to reversely derive the VIN of

Re: [Fwd: I-D Action: draft-carpenter-6man-ug-00.txt]

2013-02-08 Thread Roland Bless
Hi, On 08.02.2013 09:31, Rémi Després wrote: > Hosts of an IPv6 customer site can have IPv6 addresses assigned, with > SLAAC or DHCPv6, BEFORE 4rd is activated. > If these addresses become in conflict with the CE 4rd address when > 4rd is activated, renumbering becomes necessary. The objective

Re: Keeping the 4rd-range issue separate from the general u/g discussion

2013-02-06 Thread Roland Bless
Hi, On 06.02.2013 17:55, Rémi Després wrote: >> Am 06.02.2013 14:52, schrieb Rémi Després: >>> As already said, the 4rd range only makes a first use of an existing >>> RFC4291 provision: "The use of the universal/local bit in the >>> Modified EUI-64 format identifier is to allow development of fut

Re: RFC4291 - ff01::/16

2013-02-06 Thread Roland Bless
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Michael, On 06.02.2013 19:23, Michael Richardson wrote: >> "TM" == TM writes: >>> RFC4291 is clear that packets destined to ff01::/16 must never >>> leave the local node, but what should be done if such packets >>> are received as a result f

Re: 3484bis and privacy addresses

2012-03-27 Thread Roland Bless
Hi, On 27.03.2012 09:33, Brian Haberman wrote: Please state your preference for one of the following default options : A. Prefer public addresses over privacy addresses B. Prefer privacy addresses over public addresses I prefer option B. Regards, Roland

Re: Centrally assigned "ULAs" for automotives and other environments

2011-09-29 Thread Roland Bless
Hi, On 29.09.2011 15:44, Christopher Morrow wrote: > have to help in the educational process a bit, but hiding behind > 'private addressing' and 'we never want to ... oops, we connected to > the internet!' just isn't working today. As a general statement fine, but in our use case you a) need stab

Re: Centrally assigned "ULAs" for automotives and other environments

2011-09-29 Thread Roland Bless
Hi Jeroen, Am 29.09.2011 09:30, schrieb Jeroen Massar: > You do realize that the RIRs are providing exactly what you describe? :) > > - globally guaranteed unique (due to registry) large address prefixes > > Which is why from my information ULA-C has also been abandoned, as it > already is some

Re: Centrally assigned "ULAs" for automotives and other environments

2011-09-29 Thread Roland Bless
Hi Dan, On 28.09.2011 23:28, Dan Wing wrote: > ALGs are harmful and the NAT industry has over a decade experience > that shows ALGs are harmful. ALGs have prevented proper operation > of SIP, FTP, and a variety of other protocols. The more complex > a protocol, the more likely an ALG interferes

Re: Centrally assigned "ULAs" for automotives and other environments

2011-09-29 Thread Roland Bless
Hi Brian, Am 28.09.2011 23:07, schrieb Brian E Carpenter: > On 2011-09-28 23:08, Roland Bless wrote: > ... >> The current ULA-C... > > What do you mean? There is no current definition of ULA-C. That's right :-) I was referring to the definition in RFC 4193 with L=0, i

Re: Centrally assigned "ULAs" for automotives and other environments

2011-09-28 Thread Roland Bless
Hi Joel, On 28.09.2011 22:39, Joel M. Halpern wrote: > Then use a good firewall to control what is and is not allowed to pass. > What I am objecting to is requiring an ALG, and using addressing to try > to create security. Sure, ALGs are ugly, but usually you don't want any kind of unwanted traff

Re: Centrally assigned "ULAs" for automotives and other environments

2011-09-28 Thread Roland Bless
Hi Joel, On 28.09.2011 22:10, Joel M. Halpern wrote: > There seem to be a number of assumptions, some of which I suspect I am > misunderstanding, in the case being described. Yes, I guess so. > I tend to make two assumptions: > 1) Even low end intra-automotive devices can cope with multiple addr

Re: Centrally assigned "ULAs" for automotives and other environments

2011-09-28 Thread Roland Bless
Hi David, On 28.09.2011 20:24, David Farmer wrote: > Yes, OUI exhaustion isn't and shouldn't be a problem unless we make > it one. > > My point was if you implement your proposal without doing a more > classic ULA-C also, you will create demand for OUIs from the > enterprise world just so they ca

Re: Centrally assigned "ULAs" for automotives and other environments

2011-09-28 Thread Roland Bless
Hi Tom, On 28.09.2011 14:44, t.petch wrote: > There was a recent post on OPSAWG from the IEEE RAC about their need > to ensure that they do not run out of OUI; it was Cloud Computing that > triggered their concern, but this might as well. Thanks for the hint. I see the point. The problem is caus

Re: Centrally assigned "ULAs" for automotives and other, environments

2011-09-28 Thread Roland Bless
Hi Thierry, On 28.09.2011 11:05, Thierry Ernst wrote: > Car will have multiple prefixes, for different usages. The car makers Our scenario is roughly like this: - the car has an IP-based on board network between its ECUs for internal control. This directly impacts the safety of the car in man

Re: Centrally assigned "ULAs" for automotives and other environments

2011-09-28 Thread Roland Bless
Hi David, On 28.09.2011 00:06, David Farmer wrote: > Also, the RIR policies focus on Internet connected uses of addresses. > Sometimes the policies outright prohibit non-connected use. Or if they > don't, there are written in ways that to the uninitiated think the > policies prohibit such use. A

Re: Centrally assigned "ULAs" for automotives and other environments

2011-09-28 Thread Roland Bless
Hi David, On 27.09.2011 23:28, David Farmer wrote: > I'm warming to the idea. However if we do something like this for the > manufacturing world we better move forward normal ULA-C for the The current ULA-C has the problem of allocating /48s. A manufacturer would have to request many of them and

Re: Centrally assigned "ULAs" for automotives and other, environments

2011-09-28 Thread Roland Bless
Hi, On 27.09.2011 23:25, Warren Kumari wrote: > Did you follow the link in my earlier email[0]? : Comprehensive Experimental > Analyses of Automotive Attack Surfaces -- > http://www.autosec.org/pubs/cars-usenixsec2011.pdf > And a vide of same (well worth watching) from USENIX Security: > htt

Re: Centrally assigned "ULAs" for automotives and other, environments

2011-09-28 Thread Roland Bless
Hi Jeroen, On 27.09.2011 17:55, Jeroen Massar wrote: > On 2011-09-27 17:36 , Rob V wrote: >> That doesn't mean all the systems within the car need to speak to the >> outside world. The engine thermometer doesn't care about traffic or the >> location of the nearest train station. It just needs to

Re: Centrally assigned "ULAs" for automotives and other environments

2011-09-27 Thread Roland Bless
Hi Wes, see inline. On 27.09.2011 19:43, George, Wes wrote: > From: Roland Bless [mailto:roland.bl...@kit.edu] > > all that I'm proposing is to use a stable internal addressing for the > onboard network (no matter how the car is currently connected to the > Internet) a

Re: Centrally assigned "ULAs" for automotives and other environments

2011-09-27 Thread Roland Bless
Hi, On 27.09.2011 18:06, Eric Vyncke (evyncke) wrote: > At the risk of stating the obvious, ULA does not provide any > real-world security... They do not have the E-bit set ;-) Even with the :-), I neither understood nor described ULAs as a security solution - they only simplify some filtering ru

Re: Centrally assigned "ULAs" for automotives and other, environments

2011-09-27 Thread Roland Bless
Hi, On 27.09.2011 17:54, Warren Kumari wrote: >> That doesn't mean all the systems within the car need to speak to >> the outside world. The engine thermometer doesn't care about >> traffic or the location of the nearest train station. > > True, but increasingly automotive telematics are being u

Re: Centrally assigned "ULAs" for automotives and other, environments

2011-09-27 Thread Roland Bless
Hi, On 27.09.2011 17:36, Rob V wrote: > That doesn't mean all the systems within the car need to speak to the > outside world. The engine thermometer doesn't care about traffic or the > location of the nearest train station. It just needs to tell the dashboard > its current read-out. I presume

Re: Centrally assigned "ULAs" for automotives and other, environments

2011-09-27 Thread Roland Bless
Hi Ray, On 27.09.2011 17:23, Ray Hunter wrote: > FYI A consortium in the Netherlands have just announced a scheme that is > planning to link in-car navigation systems with traffic control and > information systems, and also public transport systems, so that if > there's a traffic jam and it is goi

Re: Centrally assigned "ULAs" for automotives and other environments

2011-09-27 Thread Roland Bless
Hi Wes, On 27.09.2011 16:53, George, Wes wrote: > WEG] A firewall/gateway can do this regardless of the address space > that you are using. What you're proposing is a use case similar to the > IPv4 model of using RFC1918 addresses + NAT/NAPT at the edge of the > private network, and you will not

Re: Centrally assigned "ULAs" for automotives and other environments

2011-09-27 Thread Roland Bless
Hi Jeroen, On 27.09.2011 15:51, Jeroen Massar wrote: >> it seems that there is currently not much interest in ULA-Cs (centrally >> assigned ULAs). I came across several use cases, where manufacturers >> (e.g, those of cars, airplanes, or smart metering environments) >> would need internal/closed I

Re: Centrally assigned "ULAs" for automotives and other environments

2011-09-27 Thread Roland Bless
Hi Christopher, On 27.09.2011 15:49, Christopher Morrow wrote: > why can't these just use globally unique addresses? They can, but there are similar reasons for using ULAs: - They are not intended to be routed in the Internet - They use a well-known prefix to allow for easy filtering at site b

Centrally assigned "ULAs" for automotives and other environments

2011-09-27 Thread Roland Bless
Hi, it seems that there is currently not much interest in ULA-Cs (centrally assigned ULAs). I came across several use cases, where manufacturers (e.g, those of cars, airplanes, or smart metering environments) would need internal/closed IPv6-based networks (maybe only for internal control and manag

Re: [v6ops] IPv6 Diagnostic Option

2011-07-23 Thread Roland Bless
lacking a clear problem statement so that wasn't clear to me. >> On 22 Jul 2011, at 04:59, Roland Bless wrote: >>> a) the Flow Label is part of the standard common IPv6 header, thus >>> always present and easier to process (even in the fast path) as >>> you

Re: [v6ops] IPv6 Diagnostic Option

2011-07-22 Thread Roland Bless
Hi Erik, On 22.07.2011 08:35, Erik Kline wrote: >> I don't think that your proposed solution is necessary, since >> IPv6 has the Flow Label, that - if set by the source - may be >> very well suited for your purpose (tracking flows along a path). >> Please see http://datatracker.ietf.org/doc/draft-

Re: [v6ops] IPv6 Diagnostic Option

2011-07-21 Thread Roland Bless
Hi, On 22.07.2011 06:38, nalini.elk...@insidethestack.com wrote: > Would love to get feedback on an Internet Draft we have submitted. > The issue we are addressing is that the IP Identification field which > was available with IPv4 in the main header is available with IPv6 > only in the Fragment

Re: subnet router anycast

2011-07-04 Thread Roland Bless
Hi Randy, Am 04.07.2011 12:35, schrieb Randy Bush: >> There are definitely cases where it can be useful to have a group of >> anycast hosts inside a subnet, e.g., in order to increase robustness >> of services etc. > > do you use this in production or test? Frankly said, I wasn't aware that they

Re: subnet router anycast

2011-07-04 Thread Roland Bless
Hi Randy, On 04.07.2011 00:01, Randy Bush wrote: >IPv6 subnet anycast is not used operationally, complicates >implementations, and complicates protocol specifications. The form >of anycast actually used in the Internet is routing-based, and is >essentilly the same as that of IPv4

Re: subnet router anycast

2011-07-03 Thread Roland Bless
Hi, On 03.07.2011 19:03, Karl Auer wrote: > Which RFCs (or other sources) describe how IPv6 subnet anycast *works*? > In particular how it works when there are multiple routers in a single > subnet? That's a good question. I was also looking for that. It's distributed across various RFCs: ---

Re: Vehicle's VIN in IPv6.

2011-03-31 Thread Roland Bless
Hi Scott, On 31.03.2011 13:18, Scott Brim wrote: >> Perhaps something a bit more relevant to IETF is generating a ULA prefix >> from a VIN? > > If these addresses will never be used for anything except diagnostics > and internal communications, then okay, but this looks like a classic > case of

Re: Vehicle's VIN in IPv6.

2011-03-31 Thread Roland Bless
Hi, On 31.03.2011 12:43, Nathan Ward wrote: > Perhaps something a bit more relevant to IETF is generating a ULA prefix from > a VIN? That could indeed be useful. In the German SEIS project we are considering to use IPv6 internally for communication between ECUs in cars. For such internal use thi

Re: Vehicle's VIN in IPv6.

2011-03-31 Thread Roland Bless
Hi Alexandru, On 31.03.2011 12:08, Alexandru Petrescu wrote: > Thanks for the pointer, I am discovering OBD. We are also interested in > wireless usage of IP within the vehicle, with off-the-shelf links (i.e. > consumer electronics market wifi, bluetooth, ant) together with OBD if > needed. See

Re: Vehicle's VIN in IPv6.

2011-03-31 Thread Roland Bless
Hi George, On 31.03.2011 11:16, George Michaelson wrote: > I don't think "go away" is the right answer. I think "your model has > flaws" is closer. Yep. Given the huge IPv6 address space, some manufacturers are tempted to use the IPv6 address as identifier. > The key message is that if they appl

Re: Vehicle's VIN in IPv6.

2011-03-31 Thread Roland Bless
Hi Thierry, On 31.03.2011 11:07, Thierry Ernst wrote: > I fail to see why a VIN would be mapped to an IPv6 address as much as I > fail to see why a passport number would be mapped to an IPv6 number. As There may be scenarios where it may be useful to uniquely address a particular car, e.g., for (

Re: Vehicle's VIN in IPv6.

2011-03-31 Thread Roland Bless
Hi Radek, On 30.03.2011 17:31, Radek Wróbel wrote: > Vehicle / mechanic engineers are working on a new On Board Diagnosis > standard for vehicles > (http://en.wikipedia.org/wiki/On-board_diagnostics). Today EOBDv1 can > diagnose (quasi online) 849 failures. One of most important advantage of > EOB

Re: Hop-by-Hop Extension Header processed in Slow Path?

2011-02-07 Thread Roland Bless
Hi Vishwas, Am 04.02.2011 18:53, schrieb Vishwas Manral: > The problem is not just about known options here, like I mentioned > earlier. A structure where there is a list which needs to be walked > serially and no fixed place for an information, it is bad for the fast > path. I see. > I have men

Re: Hop-by-Hop Extension Header processed in Slow Path?

2011-02-07 Thread Roland Bless
Hi Chris, Am 04.02.2011 16:27, schrieb Christopher Morrow: > which options? how often would you expect this list to update? routers > live in the network for ~7 years or so, in large networks. ASIC > updates mean very expensive (equipment, personnel, sla) changes are > required. Which options dep

Re: Hop-by-Hop Extension Header processed in Slow Path?

2011-02-04 Thread Roland Bless
Hi, Christopher Morrow wrote: > My feeling is this: > hop-by-hop processing will happen in slow-path (if you permit it to > happen at all), you can't build a router today with an asic that'll > know how to handle options which are created in the future :( while the latter is surely true, I don't