how simplistic your view is against so complex
nature of PRISM etc, against which, only the simplest
protection is effective.
Masataka Ohta
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
.
Masataka Ohta
) 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
standards allow that to happen.
I'm afraid you want to increase monitoring cost.
Masataka Ohta
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
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
authority (delegation) servers.
Wrong. The domain owners can't know some victims are supplied
faked data.
Masataka Ohta
are intelligent intermediate systems.
But, if CAs were trusted third parties, it means both Alice
and Bob can safely trust them.
Masataka Ohta
?
Masataka Ohta
, PKIs requiring time stamps for expiration or CRL are
broken.
Masataka Ohta
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
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
, apparently by
supplying it false location.
Masataka Ohta
systems, PCs with open source UNIX are much
safer, even though USG can still use a lot of approaches to
compromise them.
Masataka Ohta
to be compatible with
existing TXT usages.
Thanks,
Masataka Ohta
compatibilities (or lack of them) between the existing usages,
might help.
Masataka Ohta
not for address space extension but
for better handling of multiple addresses for better routing
table aggregation.
Masataka Ohta
.
Masataka Ohta
thought so.
Rest of the people developed DHCP and, now, you can see which is
better.
Masataka Ohta
, 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
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
.
Masataka Ohta
of the tla/nla classful insanity. but
u/g? puhleeze.
Yup
TLA/NLA is a good thing, *IF* multiple addresses of a node
and automatic renumbering including routers and DNS were
properly supported. It is not very difficult to have done so.
Masataka
and consequent transparency
to most applications. Ha!
There is no need for IPv6 specific changes.
Masataka Ohta
unusable.
Masataka Ohta
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
.
Masataka Ohta
.
Masataka Ohta
at the end of 2003.
There were disputes in courts and the supreme court judged
that copyright of the movies expired.
Masataka Ohta
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
.
Masataka Ohta
.
Masataka Ohta
countries at border towns.
But the main long range 2G/3G signals are
TDMA or CDMA in regulated bands.
Forget them.
Masataka Ohta
assigned
bandwidth within their border.
Anyway, there can be no inter-border coordination by ITU-T
between fighting countries.
Masataka Ohta
.
Masataka Ohta
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 telephone
companies are just
to minimise per-packet processing.
is bogus, because searching cache means a lot more effort than
recomputing checksum.
Masataka Ohta
.
Masataka Ohta
the complication caused by 6-4 translation.
Masataka Ohta
using the existing mechanism.
IPv4 addresses? What do you mean?
Masataka Ohta
that applies to
this draft, though.
So, you are lucky that I have noticed the problem at the last call.
Masataka Ohta
.
Masataka Ohta
source/destination address pair for
IPv6, whereas for IPv4 it is only 16 bits and required unique per
source/destination/protocol triple.
Masataka Ohta
.
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.
by the destinations.
Masataka Ohta
almost useless
because no one will follow the rate 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
unique for
the longest possible MSL and the fastest possible packet rate,
which 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
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
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.
Masataka Ohta
.
Masataka Ohta
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 is not surprising if end users think you are guilty.
Masataka Ohta
draft.
Masataka Ohta
(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
:
As expired IDs are referenced, may I suggest to add
draft-ohta-e2e-nat-00.txt
along with [Bo11] and [De11].
Masataka Ohta
.
There should be. May I volunteer?
Masataka Ohta
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
.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
.
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 addresses.
___
Ietf mailing list
Ietf@ietf.org
to, it's an operational issue.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
, 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).
Masataka Ohta
___
Ietf mailing list
Ietf
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
___
Ietf mailing
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
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
.
Thus, IPv6 was mortally wounded from the beginning.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
end to end transparent.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
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
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
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?
Masataka Ohta
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?
Masataka Ohta
___
Ietf
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
___
Ietf mailing list
Ietf@ietf.org
https
allocation.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
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 Ohta
?
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
of the capability of a double NAT
equipment should argue for allocation of another space
to enable development of the double NAT equipment.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org
PMTUD, including
unicast ones.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
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
://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
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
.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
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@ietf.org
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
___
Ietf mailing
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.
Masataka Ohta
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 mailing list
Ietf@ietf.org
https
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
.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
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.ietf.org
internationalized DNS.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
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.
Masataka Ohta
.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
draft works for
deciding when to prefer a 6to4 address over IPv4.
A problem is that there is no point to stick to IPv6 broken
so much.
But, it's not my problem.
Masataka Ohta
___
Ietf mailing list
Ietf
?
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
and harmful. Proper support
of multihoming can be done only at the transport layer and above.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
, thanks to poor
estimation of RFC1715, is impossible to remember.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Brian E Carpenter wrote:
Since 6to4 is a transition mechanism it has no long term future
*by definition*.
By observation, the transition is continuing for these 16 years
since RFC1883.
Masataka Ohta
in the browser retries within a hundred ms:
So yes, it can take several seconds to just resolve a host and then
only a few hundreds of ms to retrieve
the objects. I've observed it.
won't happen.
Masataka Ohta
with IPv4 address exhaustion.
Masataka Ohta
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
1 - 100 of 522 matches
Mail list logo
