In your letter dated Tue, 31 Jan 2012 15:58:55 -0300 you wrote:
>On 01/31/2012 08:12 AM, Philip Homburg wrote:
>> "Such traffic absolutely occurs in the wild. I have three reasonably
>> busy name servers where this is logged as an error from the ipfw code,
>> e.g."
In your letter dated Mon, 30 Jan 2012 20:42:27 -0300 you wrote:
>On 01/30/2012 06:28 PM, Philip Homburg wrote:
>> In your letter dated Sat, 28 Jan 2012 20:41:18 -0300 you wrote:
>>> That said, nobody is *introducing* atomic fragments.They should have
>>> been supported
In your letter dated Fri, 27 Jan 2012 19:13:46 -0300 you wrote:
>> For IPv4, either you have an mtu of 1500 or you use mss clamping. Relying on
>> pmtud gives a bad user experience.
>
>Since IPv4 MTUs can be as low as 296, and since I doubt you clamp the
>MSS to such a low value, you still rely on
In your letter dated Sat, 28 Jan 2012 20:41:18 -0300 you wrote:
>That said, nobody is *introducing* atomic fragments.They should have
>been supported for more than 15 years, and there is other stuff
>(mentioned by Dan Wing at others) that would break without this.
Currently, atomic fragments are r
In your letter dated Mon, 30 Jan 2012 12:18:21 +0100 you wrote:
>Because the network ends up second-guessing the host. RFC 2460 allows
>IPv6 nodes to act on ICMPv6 PTBs w/MTU < 1280 by simply lowering the
>Path MTU for the destination to the indicated value. In other words, an
>IPv6 node can perfor
In your letter dated Fri, 27 Jan 2012 16:18:28 -0300 you wrote:
>Hi, Philip,
>
>On 01/27/2012 02:36 PM, Philip Homburg wrote:
>>> (For IPv6, I suggest that you talk with davem@, which noted that we
>>> would not even want such a scheme for the IPv6 (i.e., 32-bit long)
&
In your letter dated Fri, 27 Jan 2012 13:19:24 -0300 you wrote:
>On 01/27/2012 08:13 AM, Philip Homburg wrote:
>> Given the current trends, just a random number would be good enough. But the
>> old RFCs assumed that a sequence number was used to maintain uniqueness.
>
>May I
In your letter dated Fri, 27 Jan 2012 09:01:46 -0300 you wrote:
>In any, please note the difference between *accepting* atomic fragments,
>generating ICMPv6 PTB when the MTU of the constricting link is < 1280,
>and reacting to ICMPv6 PTB by generating atomic fragments.
My strong preference would b
In your letter dated Fri, 27 Jan 2012 10:27:06 + you wrote:
>I'm still extremely bothered by atomic fragments. Their use case seems
>to be something like this:
>
> (1) A router receives a sufficiently large IPv6 packet for a
> destination which lies behind a link with a sub-1280 MTU.
>
>
In your letter dated Wed, 4 Jan 2012 08:46:31 -0500 you wrote:
>On 04 Jan 2012, at 07:17 , Philip Homburg wrote:
>> RFC-2460 is from 1998. You are talking about the IPv6 network
>> before 1998? And that resembles todays IPv6 internet in what way?
>
>The network laye
In your letter dated Wed, 4 Jan 2012 06:36:25 -0500 you wrote:
>
>On 03 Jan 2012, at 17:57 , Philip Homburg wrote:
>> - For IPv6, given that the host has to do the fragmentation,
>> a big minimum MTU is required. Otherwise, too much stuff
>> will end up being fragmente
In your letter dated Tue, 3 Jan 2012 07:32:17 -0500 you wrote:
>Of course an adaptation layer has various costs
>beyond a single bit, but please also consider the
>case where there are no unused bits at hand.
Well, Van Jacobson made his header compression work with SLIP. And everybody
was happy.
In your letter dated Mon, 2 Jan 2012 19:21:45 -0500 you wrote:
>I have been told of real-world IPv6 deployments
>where the link MTU is smaller than 1280,
>while the limited link bandwidth makes adding a new
>segmentation protocol layer impractical. I believe
>these account for some of the 576 b
In your letter dated Wed, 23 Nov 2011 12:48:02 +1100 you wrote:
>ULA has similar scope issues. It's just that the OS don't knock
>you over when you do bind(), connect(), sendto() and sendmsg()
>without scope information. You can avoid using non local ULA with
>the same filtering mechanisms.
I th
In your letter dated Tue, 22 Nov 2011 14:30:03 +1100 you wrote:
>On a related issue to link locals in URI's, we don't currently have
>a good method of supporting link locals in the DNS. Sure we can
>add them as records but they are essentially useless as the
>scope information is lost. Peopl
In your letter dated Mon, 17 Oct 2011 10:25:19 -0500 you wrote:
>Appreciate the quick reply. Note BrianC already noted that 20 bits will
>not suffice by saying "It puts you into birthday-paradox territory on a
>LAN with a few hundred nodes.". His email is at the URL below.
>
>http://www.ietf.org/
In your letter dated Mon, 17 Oct 2011 09:14:21 -0500 you wrote:
>-Original Message-
>From: Brian E Carpenter [mailto:brian.e.carpen...@gmail.com]
>Sent: Saturday, October 15, 2011 3:18 PM
>To: Hemant Singh (shemant)
>Cc: Tassos Chatzithomaoglou; IPv6 WG Mailing List
>Subject: Re: FW: New V
In your letter dated Sat, 13 Aug 2011 12:17:29 +0200 you wrote:
>I still think there's an issue with the suggested blanket global
>treatment of IPv4 RFC1918 addresses.
>
>Quote draft-ietf-6man-rfc3484-revise-04 "This issue can be fixed by changing t
>he
>address scope of private IPv4 addresses to
In your letter dated Sun, 7 Aug 2011 10:57:45 -0700 you wrote:
> B. Assumption 2 a draft updating 4861 would be a standards track =
>document.
I think it would be best to create a discussion document that describes the
various ways that RFC-4861 can be changed to deal with remote attacks on
In your letter dated Wed, 20 Jul 2011 17:35:31 -0400 you wrote:
>I am not sure the specs insist that an IPv6 implementation
>must treat an ICMPv6 Packet-Too-Big for less than 1280 bytes
>as "unrecoverable". (I haven't re-read the IPv6 specs recently.)
Some services, like big DNS server cannot af
In your letter dated Wed, 20 Jul 2011 10:17:51 -0700 you wrote:
>> A few remarks about this draft:
>> 1) It must be somewhere in RFC-4861, but it is not easy to find and it's
>> probably best to help implementors here: if a NCE for a router transitio
>ns
>> to UNREACHABLE state and there ar
In your letter dated Thu, 07 Jul 2011 13:41:41 -0700 you wrote:
>A new version of I-D, draft-nordmark-6man-impatient-nud-01.txt has been
>successfully submitted by Erik Nordmark and posted to the IETF repository.
A few remarks about this draft:
1) It must be somewhere in RFC-4861, but it is not e
In your letter dated Tue, 19 Jul 2011 22:28:03 -0700 you wrote:
>On 7/19/11 6:02 PM, Brian E Carpenter wrote:
>> For example, if you're tunneling IPv6 over an IPv4 network whose PMTU (to
>> the other end of the tunnel) is, to take a random example, 576, the tunnel
>> end points could use IPv4 fragm
In your letter dated Tue, 19 Jul 2011 09:36:05 -0700 you wrote:
>On 7/19/11 8:51 AM, Philip Homburg wrote:
>> How can it be persistently incorrect?
>
>Depends whether it is truly random, or pseudo-random, or random initial
>value plus an monotonic increment.
Truly random soun
In your letter dated Tue, 19 Jul 2011 08:18:40 -0700 you wrote:
>Then different fragmented datagrams between the same source and dest
>traveling through different translators could get the same ID, resulting
>in a risk of (persistent) incorrect reassembly.
How can it be persistently incorrect?
In your letter dated Mon, 18 Jul 2011 22:25:30 +1000 you wrote:
>I'm puzzled by something in RFC1981, which discusses PMTUD and IPv6.
>
>It contains these two paragraphs towards the end of Section 4:
>
> A node MUST NOT reduce its estimate of the Path MTU below the IPv6
> minimum link MTU.
>
>
[I dropped v6ops]
In your letter dated Sun, 17 Jul 2011 23:41:05 +0930 you wrote:
>Good point, there would need to be a message to solicit addresses. An
>NS to the all nodes address with an unspecified (::) target address
>perhaps.
>
>So perhaps the changes required would be mostly limited to -
>
In your letter dated Sun, 17 Jul 2011 22:48:40 +0930 you wrote:
>Actually, that level of change might not be that necessary. If the
>destination address for the Duplicate Address Detection probes was
>changed to the all-nodes rather than the solicited nodes multicast
>address, then all receving nod
In your letter dated Sun, 17 Jul 2011 21:53:20 +0930 you wrote:
>I think the ultimate root cause is that the creation of neighbor cache
>entries is triggered by data plane traffic, rather than created by a
>control plane protocol i.e. a neighbor registration protocol. I think
>that means that what
In your letter dated Sun, 17 Jul 2011 11:32:37 +0930 you wrote:
>The quite novel technique of allocation transient addresses to
>applications/processes to assist with firewalling also takes advantage
>of IPv6's large address space and that hosts can have multiple
>addresses at once. It'd be a shame
In your letter dated Fri, 15 Jul 2011 09:31:12 -0400 you wrote:
>To some extent, I would prefer an approach where IPv6 Ops would work
>on that informational document (threats/concerns, operational use cases,
>existing mitigations that could be deployed) first. Then, if there
>were use cases not ad
In your letter dated Wed, 13 Jul 2011 12:51:15 -0400 you wrote:
>Perhaps I am confused, but such a document sounds more like an IPv6 Ops WG
>item than an IPv6 WG item. So I'm wondering whether this thread belongs
>over there rather than here.
I started this thread to see if RFC-4861 can improve
In your letter dated Wed, 13 Jul 2011 09:14:15 -0400 you wrote:
> What's the point?
>
> If you asume unrealistic scenarios to prove your concept, then you
>have a problem with your solution.
>
> The problem is that you have a link where the attacker can have
>2^64 different addresses to spoof
In your letter dated Tue, 12 Jul 2011 18:32:15 -0400 you wrote:
>
> IMHO I think this would be a vector for other attacks in ND.
>
> You may solve a remote attack but you are opening the door to =
>local attacks, and a big ones I think.
Let's assume for a moment a 'normal' link (not on
In your letter dated Wed, 13 Jul 2011 01:47:32 +0200 you wrote:
>But EUI-48 itself has a not-very-well-published sub-structure of a
>"manufacturer's IEEE-assigned company_id" and a "manufacturer-selected
>extension identifier"
>
>What if SLAAC was (temporarily) redefined to build EUI-64 identifie
In your letter dated Tue, 12 Jul 2011 23:56:38 + you wrote:
>Then I am really not worried. This kind of attack is trivially mitigated by=
> any stateful firewall on the path.
If a stateful firewall is mandatory for the operation of IPv6 then it
should be there in the specs. Last time I looked
In your letter dated Tue, 12 Jul 2011 20:52:11 + you wrote:
>On the other hand, there are many ways for a local host to DOS a local rout=
>er. I am not sure that this specific one is particularly practical, or worr=
>isome.
I guess I should have been way more explicit that I was thinking about
In your letter dated Tue, 12 Jul 2011 09:56:33 -0700 you wrote:
>On Jul 12, 2011, at 9:39 AM, Philip Homburg wrote:
>> What does that mean? Each time I connect my laptop to a network, an =
>operator
>> shows up from behind the bushes and configures the right parameters?
>
>
In your letter dated Tue, 12 Jul 2011 12:09:03 -0400 you wrote:
>You can't have two-party communication have only one part (the router) =
>perform all the actions.
So, in my proposal, the router sends out a request for help. And all of its
neighbors respond with a Neighbor Solicitation.
>Is there
In your letter dated Tue, 12 Jul 2011 08:17:31 -0700 you wrote:
>The problem in my opinion is not that the router isn't sending enough =
>messages. It's sending too many for it's own purposes.
>
>keeping existing known hosts in the cache and learning new ones in the =
>face of resource exhaustion i
In your letter dated Tue, 12 Jul 2011 06:45:59 -0700 you wrote:
>we had a couple of suggestions.
>
>http://www.ietf.org/id/draft-gashinsky-v6nd-enhance-00.txt
Yes, but I prefer something triggered by a router then just requiring
host to do something occasionally on their own.
---
In your letter dated Tue, 12 Jul 2011 13:31:23 + you wrote:
>* Philip Homburg:
>
>> First, let me make clear that I was thinking about remote attacks.
>
>How would a remote attack work?
You send a stream of packets directed to a particular /64 but you make sure
that
In your letter dated Tue, 12 Jul 2011 13:22:32 + you wrote:
>* Philip Homburg:
>> Two, a NS doesn't require the router to maintain any state. The router
>> just stores the IPv6 address and the MAC in the table and sends an NA.
>
>Huh? If this isn't state, then w
In your letter dated Tue, 12 Jul 2011 12:40:12 + you wrote:
>* Philip Homburg:
>> So what I was thinking of, what if a router that is under attack would
>> periodically multicast to the all-nodes multicast address a message
>> saying "help I'm under attack"
In your letter dated Tue, 12 Jul 2011 22:34:53 +1000 you wrote:
>The router would need to know that it was under attack. That could be
>quite a complicated heuristic. It seems to me that it is simpler to
>treat ND slot exhaustion as the problem, and not worry too much about
>the cause.
First, let
In your letter dated Tue, 12 Jul 2011 11:22:06 +0200 you wrote:
>I have thought about this too. I wouldn't even mind if this became =
>(configurable) default behaviour. One thing though: all nodes should =
>send neighbour solicitations for each IPv6 address they are listening =
>on.
I was thinking
Occasionally the subject comes up: /64 (and SLAAC) is bad because it is
easy to DoS routers by getting to perform too much ND.
At least in theory this seems to be a valid complaint. A router can (and
should) carefully allocate resources for ND to avoid having ND interfere with
other parts of the r
In your letter dated Thu, 23 Jun 2011 20:30:05 -0500 you wrote:
>OH... That's an intriguing idea, use 802.1x to securely feed SEND. That
>might even make using SEND practical in an open network environment like
>a University. Its a massing protocol layering violation, but most
>things in the s
In your letter dated Thu, 23 Jun 2011 18:13:31 -0400 you wrote:
>On Jun 23, 2011, at 6:08 PM, Philip Homburg wrote:
>> Ideally, clients use end-to-end crypto to keep themselves secure, but =
>the
>> network still has to be protected against denial of service attacks.
>
>N
In your letter dated Thu, 23 Jun 2011 17:56:47 -0400 you wrote:
>On Jun 23, 2011, at 5:31 PM, Manfredi, Albert E wrote:
>> It is service providers that are interested in protecting their networks, in
> this discussion. If they also happen to protect their clients, that is just a
> nice byproduct.
>
In your letter dated Wed, 22 Jun 2011 07:08:43 -0400 you wrote:
>More importantly, the implementation approach I described on the IPv6
>list is neither complicated nor computationally expensive. In fact,
>supporting the limited set of non-silly-for-ND-packet Extension Headers
>has tiny increment
In your letter dated Fri, 10 Jun 2011 18:51:12 -0300 you wrote:
>A more relaxed approach would be as follows:
>* Extension headers are allowed with ND messages.
>* If the packet is fragmented, the upper-layer header (ICMPv6 in this
>case) must be present in the first fragment (i.e., hosts must not
In your letter dated Tue, 31 May 2011 14:45:24 +0200 you wrote:
>Is DHCPv6 more expensive than DHCPv4? Since even the most minimalistic =
>device with IPv4 support I know of has DHCPv4 support; however, you =
>might be referring to devices even more minimalistic than what I have in =
>mind.
I wa
In your letter dated Tue, 31 May 2011 13:19:39 +0200 you wrote:
>On 2011-05-31, at 12:35 , Philip Homburg wrote:
>> The difference is that IPv4 has a model of one subnet per link.
>
>Why do you think so? The computer I'm using right now has two IP =
>addresses of different
In your letter dated Tue, 31 May 2011 13:06:20 +0200 (CEST) you wrote:
>Absolutely, but if there is another way than to announce the on-link
>prefix than might make hosts communicate directly to each other on a
>subnet, that's news to me and I find this extremely interesting from a
>security sta
In your letter dated Tue, 31 May 2011 12:37:05 +0200 you wrote:
>Or you have the wrong provider... but if this is the only provider =
>available in your area, that can offer you a symmetric 100 MBit/s fibre =
>connection for business purposes, what are you going to do? Move your =
>whole company el
In your letter dated Tue, 31 May 2011 12:28:01 +0200 (CEST) you wrote:
>On Tue, 31 May 2011, Philip Homburg wrote:
>> No, ND is more clever than that. All traffic between prefixes that are
>> on-link goes directly between the hosts. Even when the prefix is
>> off-link i
In your letter dated Tue, 31 May 2011 11:54:57 +0200 you wrote:
>I don't think this related to ND, is it? ICMP redirects also exist for =
>IPv4 and IPv4 doesn't know ND. I think only difference is that ICPMv6 =
>optionally allows an link layer address in the redirect message. How =
>good IPv6 imple
In your letter dated Tue, 31 May 2011 11:12:13 +0200 you wrote:
>Of course this is possible, but this also means, that a node not doing =
>DHCPv6 (because it does not support it or because it is disabled on the =
>node), will only get an address of the SLAAC prefix and thus has to go =
>to through
In your letter dated Mon, 30 May 2011 12:47:19 +0200 you wrote:
>Then a node has both, a SLAAC address and a DHCPv6 address. Where is the probl
>em? The only problem I can think of is the issue I was trying to discuss here
>a couple of weeks ago: An address collision between SLAAC addresses and no
In your letter dated Mon, 30 May 2011 12:47:19 +0200 you wrote:
>Conflict resolution is not really necessary. What kind of conflict do you have
> to solve? If a network runs a DHCPv6 server that also hands out addresses, th
>e network operators probably want people to use DHCPv6 over SLAAC, so if a
In your letter dated Wed, 25 May 2011 08:05:27 -0700 you wrote:
>I said that the current assumed maximum 3 NUD probes one second apart
>makes IPv6/ND less flexible than IPv4/ARP, and I think we should remove
>those constraints.
>
>I'm having a hard time understanding what point you are trying to
In your letter dated Tue, 24 May 2011 10:22:09 -0700 you wrote:
>On 5/24/11 10:12 AM, Philip Homburg wrote:
>With current RFC 4861 this means that the NCE has to be discarded, since
>the neighbor is deemed UNREACHABLE.
>
>Without the NCE, the next time the node tries to send a
In your letter dated Tue, 24 May 2011 09:36:15 -0700 you wrote:
>One place where is shows up is when you have a stable network where the
>routers and hosts have neighbor cache entries for the peers they talk
>to. But then there is a short outage on the LAN, e.g., due to a switch
>or link failure
In your letter dated Mon, 23 May 2011 23:10:09 +0200 you wrote:
>Who says that NUD can't also be used to declare an interface down/
>detect router neighbor loss?
>
>Maybe think of a BGP process running over TCP receiving ICMP
>unreachables because the local NUD has declared the neighbor
>unreach
In your letter dated Mon, 23 May 2011 22:03:50 +0200 you wrote:
>e.g. 2. Say Node A (end host) declares node B (router) unreachable
>locally, but node B (router) is still up and running but has not yet
>timed out Node A.
I don't think I understand your model of how a router works.
To a large ex
In your letter dated Mon, 23 May 2011 11:46:29 -0700 you wrote:
>This draft proposes to change the requirement that NUD can not
>retransmit more than three times, so that NUD can be more robust against
>temporary network outages.
>
>Comments?
Do you have more data on how this problem actually sh
In your letter dated Wed, 20 Apr 2011 15:01:05 +1200 you wrote:
>In this situation a 6to4 relay (like any other tunnel end point)
>should behave according to section 3.2 of RFC 4213. That's quite
>a complicated section and I suppose there may be buggy
>implementations, even in the absence of ICMP f
In your letter dated Mon, 18 Apr 2011 11:45:45 -0700 you wrote:
>> -Original Message-
>> From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On Behalf Of
>> Philip Homburg
>> On the other hand, the difference between 1500 and 1280 is so small, I
>>
In your letter dated Sat, 16 Apr 2011 15:28:09 +0200 (CEST) you wrote:
>On Sat, 16 Apr 2011, Philip Homburg wrote:
>
>> PMTU blackhole detection seemed so obvious to me, that I never bothered to
>> find out if there was an RFC specifying that it should be done.
>
><
In your letter dated Sat, 16 Apr 2011 11:28:53 +0100 you wrote:
>On Sat, 2011-04-16 at 11:17 +0200, Philip Homburg wrote:
>>
>> PMTU blackhole detection seemed so obvious to me, that I never bothered to
>> find out if there was an RFC specifying that it should be done.
>
PMTU blackhole detection seemed so obvious to me, that I never bothered to
find out if there was an RFC specifying that it should be done. That is, until
I encountered an admin said that he didn't do PMTU blackhole detection because
end-users should just fix their systems (the irony is that this c
In your letter dated Wed, 30 Mar 2011 00:15:03 +0900 you wrote:
>So, the description of this rule should be like:
>
>If the implementation can know and manage the coupling of a next-hop and a pre
>fix
>delegated from it, then the corresponding prefix should be chosen as the sourc
>e address.
>For e
In your letter dated Wed, 16 Mar 2011 10:47:45 +0100 you wrote:
>On 2011-03-16, at 10:08 , Mohacsi Janos wrote:
>
>> Yes. DAD can fail, and you system log you will see.
>
>How will this help a network admin, when the system log says, that a server th
>at is supposed to have a certain fixed IP or a
In your letter dated Tue, 15 Mar 2011 20:27:32 +0100 you wrote:
>
>On 2011-03-15, at 19:27 , Philip Homburg wrote:
>
>> If you just need stable addresses, then you can also put your own =
>random
>> numbers in DHCP.=20
>
>I just thought it would be nice if
In your letter dated Tue, 15 Mar 2011 19:04:48 +0100 you wrote:
>On 2011-03-15, at 16:58 , Philip Homburg wrote:
>
>> I think the answer is that is statistically very unlikely that on a =
>single
>> subnet, a 64-bit random number will ever be equal to any address =
>manual
In your letter dated Mon, 14 Mar 2011 13:00:11 +0100 you wrote:
>And bear in mind, that other RFCs even mention cases where a device might
>create its 64 bit host ID entirely "random"; which is even worse than using a
>hash function.
I think the answer is that is statistically very unlikely that
In your letter dated Tue, 01 Mar 2011 22:28:55 +1030 you wrote:
>How come solicited node multicast addresses use only 24 bits of the
>host's IPv6 address? It looks like there is space for many more; 64 more
>at a pinch. Using more bits from the host address would decrease even
>further the likeliho
In your letter dated Mon, 25 Oct 2010 08:30:37 -0700 you wrote:
>Philip Homburg wrote:
>> This implies that the end-device has to be able to match RS messages
>> using timestamp, i.e. its clock has to be sufficiantly accurate (to withi=
>n
>> 5 minutes, according to the SEN
In your letter dated Fri, 22 Oct 2010 10:25:45 -0700 you wrote:
>Philip Homburg wrote:
>> In your letter dated Fri, 22 Oct 2010 11:05:42 -0400 you wrote:
>> I wonder what to make of that. If the SEND protected RS messages can be
>> replaced with AN-initiated (unprotected) R
In your letter dated Fri, 22 Oct 2010 11:05:42 -0400 you wrote:
>On 10-10-22 11:01 AM, Philip Homburg wrote:
>> Then I guess the obvious next question is how this interacts with SEND if
>> the original 3 RS messages are lost.
>
>The AN-initiated RSs in this case will not
In your letter dated Fri, 22 Oct 2010 10:45:57 -0400 you wrote:
>> But now I'm a bit confused. Given that the AN now has to ability to originat
>e
>> RS messages, why is it forwarding the end-device' RS at all? Is that only to
>> support SEND?
>
>Exactly. The ability to send host-initiated RSs thro
In your letter dated Fri, 22 Oct 2010 10:08:15 -0400 you wrote:
>On 10-10-22 10:06 AM, Philip Homburg wrote:
>> Maybe this draft should say something about what happens if the 3 router
>> solicitations sent by the host are lost.
>
>Certainly. We have added Section 5.3 to ver
Maybe this draft should say something about what happens if the 3 router
solicitations sent by the host are lost.
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo
In your letter dated Thu, 23 Sep 2010 13:38:11 +0200 (CEST) you wrote:
>On Thu, 23 Sep 2010, Philip Homburg wrote:
>> I did not mean to trust the CPE. I mean that whatever layer violation
>> you want done, can be hidden in the CPE instead of exposing it to the
>> host (or ro
In your letter dated Thu, 23 Sep 2010 13:03:35 +0200 (CEST) you wrote:
>On Thu, 23 Sep 2010, Philip Homburg wrote:
>> The CPE can then for example continue sending RS messages, and can
>> terminate NS messages by always returning the concentrator's MAC
>> address
In your letter dated Thu, 23 Sep 2010 07:33:24 +0200 (CEST) you wrote:
>I'm talking about ETTH, one port in an L2 switch is a household. I know
>what port goes to each household, so "trust" is not the issue.
>
>In IPv4 I hand out an IP address and I know to what port (option 82) this
>IP address
In your letter dated Tue, 20 Jul 2010 12:26:22 -0400 you wrote:
>For a p2p link, I think we all agree that Address Resolution is not
>necessary. But what about the other parts?
I think that is where it goes wrong. Yes, it is true that on a p2p link you
don't need the neighbors MAC address because
In your letter dated Wed, 14 Jul 2010 13:16:24 +0200 (CEST) you wrote:
>> For point-to-point links, which can do multicast trivially, there is no excu
>se
>> for not doing full ND (unless it is a link between two routers that actually
>> use hellos in the routing protocol to determine whether the o
In your letter dated Wed, 14 Jul 2010 20:26:47 +0930 you wrote:
>I'm a bit confused by that. My understanding of NUD was that it's main
>function is to ensure that existing entries in the neighbor cache are
>valid. If NUD fails, then the entry is removed from the neighbor cache
>so that next time t
In your letter dated Wed, 14 Jul 2010 20:26:47 +0930 you wrote:
>(Is something up with the 6man mailing list? I've had a few replies,
>including one from Philip, none of them have CC'd ipv6@ietf.org, nor
>have I seen any replies via the list, and yet below seems show that a
>copy of Philip's email
In your letter dated Sun, 11 Jul 2010 12:03:43 +0930 you wrote:
>These implementations, instead of performing ND NS/NA, "blindly" forward
>IPv6 packets onto directly onto the point-to-point link, regardless of
>whether the destination address exists. If both ends of the link don't
>perform ND NS/NA
In your letter dated Wed, 2 Jun 2010 13:30:40 +0900 you wrote:
>I think it is chicken-and-egg.
>Right now, the multi-prefix does not work nicely because of the
>lacking mechanisms documented in this draft. And IMO, those people
>will lead to invention of NAT for IPv6.
In Section 4.2 "Next-hop sele
In your letter dated Wed, 21 Apr 2010 16:33:03 +1200 you wrote:
>By contrast, a source host
>never has this problem, because it knows by construction when a flow
>ends (chances are, flow == socket).
I'm wondering about the 'never' part. What if an application uses sendto()
to communicate over UDP
In your letter dated Wed, 31 Mar 2010 15:59:16 +0400 you wrote:
>1. Absence of ND on p2p links is logical. There is no need for ND. There are
only two neighbors. We always know L2 destination address, why should we use
>any mechanisms to resolve it ?
Because, as is clearly demonstrated by the call
In your letter dated Wed, 31 Mar 2010 15:20:55 +0400 you wrote:
>I think the "PING-PONG issue" reason alone is sufficient to progress
>draft-kohno-ipv6-prefixlen-p2p. Using /64 and other short prefixes is very
>convenient for DDoS-attackers. With /64 prefixes they can utilize bandwidth
>of p2p(PPP)
I've a question about ND for p2p links, especially tunnels as defined
in RFC-4213.
I noticed some time ago that my tunnel did something weird w.r.t. neighbor
discovery, but I didn't have the time to investigate, and just disabled ND.
Recently, did look at what was going on and what happened is tha
97 matches
Mail list logo
