s in bed with the NSA.
>>
>> The only secure way is to run your own.
>
> That's a very simplistic definition of "secure."
See above how simplistic your view is against so complex
nature of PRISM etc, against which, only the simplest
protection is effective.
Masataka Ohta
S company that's in bed with the NSA.
The only secure way is to run your own.
> Good standards allow that to happen.
I'm afraid you want to increase monitoring cost.
Masataka Ohta
d we stop working on HTTP?
For example, the following RFC:
6208Cloud Data Management Interface (CDMI) Media Types
K. Sankar, A. Jones [ April 2011 ] (TXT = 23187) (Status:
INFORMATIONAL) (Stream: IETF, WG: NON WORKING GROUP)
is a product of IETF to promote cloud service.
Masataka Ohta
is a technical issue.
Masataka Ohta
ivate this work
> correctly. It will yield a greater probability of success.
Using DH could protect us, until USG start deploying active attack.
So, it is important to develop technologies to detect attacks
against DH.
Masataka Ohta
clock is not its availability but that
they can easily be faked, which means it is no better than relying
on some NTP service, such as time.nist.gov, which is as
(un)trustworthy as USG.
Masataka Ohta
t the end to end principle, because
CAs are intelligent intermediate systems.
But, if CAs were trusted third parties, it means both Alice
and Bob can safely trust them.
Masataka Ohta
ey query the
> TLD authority (delegation) servers.
Wrong. The domain owners can't know some victims are supplied
faked data.
Masataka Ohta
robert bownes wrote:
> A 1pulse per second aligned to GPS is good to a few ns.
GPS time may be accurate, if it were assured to be secure.
Masataka Ohta
ned plain, apparently by
supplying it false location.
Masataka Ohta
t there is a great deal
> more transparency in the DNSSEC system than in the TLS PKI,
> and that should mean that the system is more robust in the
> face of this kind of attack.
According to your theory, we don't need DNSSEC, because
cache poisoning attacks on plain DNS is easily detectable.
Masataka Ohta
> (and for people who are worried about the NSA, both of these are US
> corporations), the whole system falls apart.
Right. PKI is fundamentally broken, because its fundamental
assumption that trusted third parties could exist is a total
fallacy.
Masataka Ohta
guably, never will, nor
> even probably should ever have them).
Even if you can, you can't be sure that the clock is accurate
enough.
Thus, PKIs requiring time stamps for expiration or CRL are
broken.
Masataka Ohta
se yet another PKI?
Masataka Ohta
re end systems, PCs with open source UNIX are much
safer, even though USG can still use a lot of approaches to
compromise them.
Masataka Ohta
t an issue for this
> proposed registry.
With a new RRTYPE, new usages are assured to be compatible with
existing TXT usages.
Thanks,
Masataka Ohta
ibing
compatibilities (or lack of them) between the existing usages,
might help.
Masataka Ohta
nt 1).
Changing TCP is required not for address space extension but
for better handling of multiple addresses for better routing
table aggregation.
Masataka Ohta
server is fine, it is not
a problem.
Masataka Ohta
>
#x27;t have to
waste time and packets to have DAD, with additional overehead
of IGMP, to confirm all the distributed nodes maintaining the
state of SLAAC consistently, that is, a new configured address
is unique.
Masataka Ohta
as.
> With IPX, AT address assignment was automatic. No DHCP in those old
> times.
That something was automatic only to produce useless (to me) results
does not mean it was a good idea.
Masataka Ohta
a at that time.
Not at all.
It was merely that those who had little operational insight had
thought so.
Rest of the people developed DHCP and, now, you can see which is
better.
Masataka Ohta
d manner involving all the nodes.
Masataka Ohta
gt; IPv6 was no need for changes to TCP and consequent transparency
> to most applications. Ha!
There is no need for IPv6 specific changes.
Masataka Ohta
properly supported. It is not very difficult to have done so.
Masataka Ohta
t loss.
Masataka Ohta
gt; I'm pretty sure the saving on headers is more than made up for in
> FEC, delay, etc. Not the engineering tradeoff one might want.
It has nothing to do with congestion, not at all.
Masataka Ohta
P
mostly unusable.
Masataka Ohta
years.
But, copyright of some movies expired at the end of 2003.
There were disputes in courts and the supreme court judged
that copyright of the movies expired.
Masataka Ohta
]
and everything should be fine.
Masataka Ohta
l, TELNET).
The basic rule of the RFC is:
Although labels can contain any 8 bit values in octets that make up a
label
A label may include '.' character as is, as there is no escape
mechanism, though applications expecting host names may fail to
recognize it.
Masataka Ohta
empt all the already assigned
bandwidth within their border.
Anyway, there can be no inter-border coordination by ITU-T
between fighting countries.
Masataka Ohta
kets from different countries at border towns.
> But the main long range 2G/3G signals are
> TDMA or CDMA in regulated bands.
Forget them.
Masataka Ohta
zed packets.
Masataka Ohta
ssues.
Masataka Ohta
t;.
ITU did it better for phone numbers.
Masataka Ohta
ates. The same is even more true of the
> likes of Google, Cisco, Apple, IBM, Microsoft etc.
You miss the most important stakeholders, the end users aligning
to countries.
Masataka Ohta
PS
Of course, countries acting as representatives for telephon
of each
packet to minimise per-packet processing.
is bogus, because searching cache means a lot more effort than
recomputing checksum.
Masataka Ohta
't reflect the errors in IPv6-IPv4 translation, which
> is not "IPv6".
Most, if not all, implementers do not think them errors.
Masataka Ohta
e, I can see no point you
insist on the original conclusion of the WG, which
overlooked the complication caused by 6->4 translation.
Masataka Ohta
. That has nothing to do with
> the quoted text above.
The problem is that, if rfc2460 is not "completely correct", above
text in your draft should be something based not on the current
rfc2460 but on completely correctly revised rfc2460, such as
"IPv6 ID field is required unique after translated into 16 bit
IPv4 ID".
> But neither of the above requires that IPv6 IDs must be easily
> translatable into valid IPv4 addresses using the existing mechanism.
IPv4 addresses? What do you mean?
Masataka Ohta
mind ID uniqueness (of IPv4,
>> at least) so much, RFC791 should not either.
>
> I think there are a lot of IETF documents that are not reviewed in the
> correct context of existing standards. I don't think that applies to
> this draft, though.
So, you are lucky that I have noticed the problem at the last call.
Masataka Ohta
.
Or, if you think RFC2460 does not mind ID uniqueness (of IPv4,
at least) so much, RFC791 should not either.
Masataka Ohta
Finally, the IPv6 ID field is
32 bits, but lower 16 bits are required unique per
source/destination address pair for
IPv6, whereas for IPv4 it is only 16 bits and required unique per
source/destination/protocol triple.
Masataka Ohta
full of states.
Or?
Masataka Ohta
PS
As the RFC specifies ID=0 when DF is set 0, it should also
be updated to conform to the robustness principle.
hich is not my point.
As the uniqueness is broken at some MSL and rate anyway, the
current code is enough to be "as unique as possible".
Masataka Ohta
e limitation requirement of
>> your draft.
>
> You can make that case in the doc that obsoletes 1191 if you like.
My point is that that's what IETF must do.
Masataka Ohta
PS
While your draft is rather harmful than useless, I'm fine
if the following point of t
ources.
The tunnels are often controlled uniquely only by the destinations.
Masataka Ohta
otocol police and clearing DF is not
considered guilty by operators community, the following
draft:
draft-generic-v6ops-tunmtu-03.txt
to fragment IPv6 packets by intermediate routers should be
very interesting to you.
Masataka Ohta
; may make their actions acceptable, but it will not make them compliant
> *until* someone updates the standards that require the DF not be
> cleared. This is not that document.
Once RFC1191 is obsoleted, your draft becomes almost useless
because no one will follow the rate limitation requirement of
your draft.
Masataka Ohta
ements already exist, albeit in pre-RFC2199 language.
As your draft actively tries to change the current situation
that:
>> Today, innocent operators often clear DF bit and
>> end users are happy with it, because, today, probability
>> of accidental ID match is small enough.
it
ssions misunderstand the problem as:
> That doesn't help ID uniqueness; it helps avoid fragmentation
> overload.
That does help ID uniqueness.
Masataka Ohta
always
zero, trying to discourage ICMP filtering and DF bit clearing.
But, as people filtering ICMP won't stop doing so and if
operators can do nothing other than clearing DF, it is
end users who suffers.
Then, end users may actively act against PMTUD and/or IETF.
source host after
it receives tens (or hundreds) of packets with different IDs
from the same source host.
A source host, then, is only required to remember the
previous ID used for each destination.
Masataka Ohta
ength of
>>IPv6 ID is 32 bit, from which it is impossible to generate
>>unique IPv4 ID.
>
> None of which I am aware.
There should be. May I volunteer?
Masataka Ohta
possible to generate
unique IPv4 ID.
and one comment:
As expired IDs are referenced, may I suggest to add
draft-ohta-e2e-nat-00.txt
along with [Bo11] and [De11].
Masataka Ohta
yes? I ask because NPT could be the end of it if we all agreed
> to use the right kind of signalling.
Signaling between what?
SPI negotiation may be called signaling.
Masataka Ohta
chosen to use IPv4 NAT instead?
Most of them, if I don't underestimate how large the Internet is.
All of them should be happy with IPv4 NAT with the end to end
transparency.
Masataka Ohta
a money to have fixed IP addresses, and, worse, independent
global routing table entries for multihoming, to reliably
maintain the end to end transparency to reach their servers.
They do have practical values.
That's why the global routing table have bloated so much.
y NAT, is more
than enough, there is no point to have IPv6 ID/LOC separation
nor IPv6, especially because NAT can be end to end transparent.
Masataka Ohta
ld be.
RFC1715 killed IPv6.
Masataka Ohta
e for IETF poorly designed
IPv6, because IPv6 must and could have designed to avoid
operational problems before operational experiences on
IPv6 was accumulated.
Masataka Ohta
gt; of course V6OPS.
Do look.
They are adding even new problems without any flexibility, of
course.
Masataka Ohta
ng necessary.
Masataka Ohta
hout transaction ID to distinguish requests and
responses, the worst case must be assumed, which means
the response must be interpreted that lifetime expired
190 seconds ago, which means all the subsequent responses
are meaningless because their lifetime must be interpreted
to have expired.
If we don't have to, it's an operational issue.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
ddress among many works and rest of the addresses are
unreachable.
Masataka Ohta
PS
IPv4, of course, is not ready to handle multiple addresses
properly, which causes some problems for multihomed hosts.
But it is not a serious problem because IPv4 hosts do not
have to have IPv6 addres
IPv6 addresses should have been
8B long.
Maybe, even with the current IPv6 packet format, routers
can look only at first 8B of addresses and ignore the
latter 8B (used as "original source/destination address"
for source/destination address rewriting).
't it obvious that, with a lot more than 1% penetration of the
Internet to the world today, we don't need address length much more
than 32 bits?
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
attack root servers.
Is it google who hired them to promote SEARS. :-)
Anyway, root servers are (or will be) anycast with a lot less
centralized management than google servers that they are more
resistant against attacks.
Masataka Ohta
__
t had been on the table.
Thus, IPv6 was mortally wounded from the beginning.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
es and 16 bit port
numbers will be suffice for a decade or two.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
ment scenarios, and interaction with
other layer-three protocols.
what is necessary are minor modification on IPv4/transport stack
of new (but not existing) hosts and minor extension of DHCP.
Masataka Ohta
__
announced us military space as rfc 1918
> space internal to their network. this turns out to be common.
What if the military space is sold to public and announced?
Who is forced to renumber and why?
Bradner, Scott wrote:
> the IAB advised ARIN that such assignments were in the purview of the IETF
Then, isn't it enough for IETF to conclude "let ARIN decide"?
Are there any objections to conclude so?
most cases.
It's Brian Carpenter who refused to discuss such issues in
MULTI6 WG.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
have the problem.
The only problem is that some people misinterpret it that
we had needed IPv6.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
r all the players to make IPv4 with NAT
end to end transparent.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
pathMTU.pdf
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
rough UPnP/PCP.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
address space allocation.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
continue to enable new uses of the key feature,
ie. end-node reachability.
Yes. So, let's abandon IPv6, a bad technical solution, and
deploy NAT with UPnP or PCP (if designed properly) capabilities.
Masataka
x27;t understand your question?
My point is that those who are arguing against the proposed
allocation because of the capability of a double NAT
equipment should argue for allocation of another space
to enable development of the double NAT equipment.
locate such address?
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
g.
It, of course, is a real problem against PMTUD, including
unicast ones.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
r unicast only when
operators are statically, without dynamic investigation, sure
that all the equipments support class E.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
re IETF is not the right
place to attempt to fix IPv6, which means IPv6 is hopeless.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
240/4 (except for 255.255.255.255)
should be released for unicast uses to reduce market price on
IPv4 addresses.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
work
http://meetings.apnic.net/__data/assets/file/0018/38214/pathMTU.pdf
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
e that something such as
> text/plain would indeed be the basis of our discussion here,
The MIME type of choice, other than text/plain, is
application/octet-stream.
Masataka Ohta
___
Ietf mailing list
Ietf
he LISP programming language at all.
You have demonstrated that the problem is what "the LISP people"
means within IT community including, but not limited to, IETF.
Thank you and I acknowledge that your demonstration was brief enough.
Robin Whittle wrote:
> Hi Luigi (and other LISP people),
As a member of the LISP people (I wrote an interpreter and
a compiler for 8080), your statement above is irritating.
Masataka Ohta
___
I
his block do not legitimately appear on the public
Internet. These addresses can be used without any coordination
with IANA or an Internet registry.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
eserved
addresses should be able to treat the unreservation.
However, as the unreserved space is still precious, only
small part of the space should be allocated for shared
transition.
Masataka Ohta
___
Ietf
ree with you.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
ecify like RFC1035:
Messages carried by UDP are restricted to 512 bytes (not
counting the IP or UDP headers).
Masataka Ohta
PS
You have been warned.
___
Ietf mailing list
Ietf@ietf.org
https://www.iet
ain DNS with ASCII is the most internationalized DNS.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
ding is not enough because it lacks
end to end transparency.
For example, you can't use PORT command of your ftp
client behind legacy nat.
See draft-ohta-e2e-nat-00.txt for how nat44 can be
transparent end to end.
OTOH, nat64 can not have end to end transparency.
have "knowledge" on
default free global routing tables.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
rent end to end.
So, why do we have to be bothered by 6to4?
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
1 - 100 of 574 matches
Mail list logo
