Joel jaeggli wrote:
|> Jeroen Massar wrote:
|>
|> |On 2011-09-29 09:20 , Roland Bless wrote:
|> |> 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
> Maybe we can start with new names;
>
> ULA-S (Self-assigned) - Statistically unique prefix with local
> algorithmic assignment at no cost, you assign a prefix yourself.
> ULA-R (Registered) - Unique Prefix registered to an Organizations
> through the RIRs, a prefix is assigned to you.
> ULA-M
On 9/29/11 06:20 , Dan Lanciani wrote:
> Jeroen Massar wrote:
>
> |On 2011-09-29 09:20 , Roland Bless wrote:
> |> 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?
On 9/29/11 06:44 , Christopher Morrow wrote:
> On Thu, Sep 29, 2011 at 4:59 AM, Roland Bless wrote:
>> 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) l
> -Original Message-
> From: Roland Bless [mailto:roland.bl...@kit.edu]
> Sent: Thursday, September 29, 2011 1:15 AM
> To: Dan Wing
> Cc: 'Joel M. Halpern'; '6man'
> Subject: Re: Centrally assigned "ULAs" for automotives and other
> envi
On Thu, Sep 29, 2011 at 10:09 AM, Roland Bless wrote:
> 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.
>
>
On Sep 28, 2011 11:26 PM, "Joel jaeggli" wrote:
>
> On 9/28/11 19:09 , Christopher Morrow wrote:
> > On Wed, Sep 28, 2011 at 8:51 PM, Dan Wing wrote:
> >> It's too bad computer science is not a science, or we would actually
> >> look at the past, and this mistakes that were made, to build tomorro
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
On Thu, Sep 29, 2011 at 4:59 AM, Roland Bless wrote:
> 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 info
Jeroen Massar wrote:
|On 2011-09-29 09:20 , Roland Bless wrote:
|> 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
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
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
a
collector on the ULA side and as a data provider on the "uplink"
side.
Message: 7
Date: Wed, 28 Sep 2011 17:51:13 -0700
From: "Dan Wing"
To: "'Manfredi, Albert E'", "'Roland
Bless'", "'Joel M. Halp
On 2011-09-29 09:20 , Roland Bless wrote:
> 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 defi
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.e.,
centrally assigned ULAs
On 9/28/11 19:09 , Christopher Morrow wrote:
> On Wed, Sep 28, 2011 at 8:51 PM, Dan Wing wrote:
>> It's too bad computer science is not a science, or we would actually
>> look at the past, and this mistakes that were made, to build tomorrow's
>> systems. ALGs were a mistake.
>
> I like algs for
On Wed, Sep 28, 2011 at 8:51 PM, Dan Wing wrote:
> It's too bad computer science is not a science, or we would actually
> look at the past, and this mistakes that were made, to build tomorrow's
> systems. ALGs were a mistake.
I like algs for some things but agree with dan here... and the larger
> -Original Message-
> From: Manfredi, Albert E [mailto:albert.e.manfr...@boeing.com]
> Sent: Wednesday, September 28, 2011 2:50 PM
> To: Dan Wing; 'Roland Bless'; 'Joel M. Halpern'
> Cc: '6man'
> Subject: RE: Centrally assigned "ULAs&qu
On 2011-09-29 10:28, Dan Wing wrote:
>> -Original Message-
>> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
>> Roland Bless
>> Sent: Wednesday, September 28, 2011 2:04 PM
>> To: Joel M. Halpern
>> Cc: 6man
>> Subject: Re:
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.
Harmful in your sense of the word is good, in some circles. Remember, we are
only talking abo
On 9/28/11 14:57 CDT, Roland Bless wrote:
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 t
> -Original Message-
> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
> Roland Bless
> Sent: Wednesday, September 28, 2011 2:04 PM
> To: Joel M. Halpern
> Cc: 6man
> Subject: Re: Centrally assigned "ULAs" for automotives and ot
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.
Brian
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf
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
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
On 9/28/11 15:25 CDT, Manfredi, Albert E wrote:
I dunno about automotive, but I'm with Roland on the requirement to keep the
internal controls strictly isolated from the Internet in other platforms. Yes,
there is remote condition monitoring going on, but NEVER directly from the
Internet to t
trally assigned "ULAs" for automotives and other environments
There seem to be a number of assumptions, some of which I suspect I am
misunderstanding, in the case being described.
I tend to make two assumptions:
1) Even low end intra-automotive devices can cope with multiple addresses
2
tember 28, 2011 4:10 PM
To: Roland Bless
Cc: 6man
Subject: Re: Centrally assigned "ULAs" for automotives and other environments
There seem to be a number of assumptions, some of which I suspect I am
misunderstanding, in the case being described.
I tend to make two assumptions:
1) Even
There seem to be a number of assumptions, some of which I suspect I am
misunderstanding, in the case being described.
I tend to make two assumptions:
1) Even low end intra-automotive devices can cope with multiple addresses
2) Even low end automotive-internal devices will need to communicate
ex
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
On Sep 28, 2011, at 5:08, Roland Bless wrote:
> 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 allocatin
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
- Original Message -
From: "Roland Bless"
To: "David Farmer"
Cc: "6man"
Sent: Wednesday, September 28, 2011 12:08 PM
> 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 m
"Eric Vyncke (evyncke)" wrote:
|The 'only' advantage of ULA vs. GUA is ease of filtering on a very short and
well-known prefix.
Well, the other advantage is cost, and that's exactly why we will likely
never have useful centrally allocated ULAs. If the ULAs were cheap they
would represent a thr
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
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
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
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
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
I'm following this thread with interest.
Car will have multiple prefixes, for different usages. The car makers
will probably allocate them an ULA (no decision made on this) for
diagnostic purposes and remote software updates. In addition, another
prefix will be alocated to the vehicle for a n
On 9/27/11 08:49 CDT, Christopher Morrow wrote:
On Tue, Sep 27, 2011 at 9:36 AM, Roland Bless wrote:
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 meter
On 9/27/11 08:36 CDT, Roland Bless wrote:
Hi,
it seems that there is currently not much interest in ULA-Cs (centrally
assigned ULAs).
That interest varies significantly I would suggest you are correct int
he IETF and service provider worlds. However, in the enterprise and
manufacturing wo
On Sep 27, 2011, at 4:32 PM, Roland Bless wrote:
> 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.
>
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) and to use a security gatewa
On Sep 27, 2011, at 3:15 PM, Manfredi, Albert E wrote:
> Doesn't seem logical to conclude that a NAT would be involved in any of this.
> But even if it is, what's wrong with a "basic NAT," i.e. one that provides a
> simple one to one mapping for a subset of the internal addresses?
If you do nee
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
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
-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
> Roland Bless
> Sent: Tuesday, September 27, 2011 12:46 PM
> To: Rob V
> Cc: 'Ray Hunter'; '6man'
> Subject: Re: Centrally assigned "ULAs" for automotives and other, environments
>
>
.org] On Behalf Of Roland
Bless
Sent: Tuesday, September 27, 2011 12:46 PM
To: Rob V
Cc: 'Ray Hunter'; '6man'
Subject: Re: Centrally assigned "ULAs" for automotives and other, environments
Hi,
On 27.09.2011 17:36, Rob V wrote:
> That doesn't mean all the sy
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)
and to use a security gateway/proxy when communication to the Internet
is somehow required.
WEG] ok
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
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
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
Roland,
At the risk of stating the obvious, ULA does not provide any real-world
security... They do not have the E-bit set ;-)
More seriously, ULA can be routed, so, if a ULA route leaks, then your ULA can
be reached. Obviously, if your ULA gets a default route, then it can send
packets to the
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 tell the dashboard
> its current read-out. I presume thos
On Sep 27, 2011, at 11:36 AM, 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.
True, but increasingly automotive telematics are being used / fol
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 those are the kinds of systems the OP was
refer
On Sep 27, 2011 6:49 AM, "Christopher Morrow"
wrote:
>
> On Tue, Sep 27, 2011 at 9:36 AM, Roland Bless
wrote:
> > 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, a
On Tue, Sep 27, 2011 at 10:53 AM, George, Wes wrote:
> From: ipv6-boun...@ietf.org On Behalf Of Roland Bless
>
> 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
> boundaries.
From: ipv6-boun...@ietf.org On Behalf Of Roland Bless
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
boundaries.
WEG] from the below it sounds like the first item isn't always
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
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
On 2011-09-27 15:36 , Roland Bless wrote:
> 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-bas
On Tue, Sep 27, 2011 at 9:36 AM, Roland Bless wrote:
> 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/clos
64 matches
Mail list logo