On Jun 6, 2013, at 10:40 PM, Lorenzo Colitti
mailto:lore...@google.com>> wrote:
Like almost everything things in engineering, it's a cost/benefit tradeoff.
This discussion about "not enough bits" is simply attempting to quantify some
of the costs involved. I keep harping about it because the cos
On Jun 6, 2013, at 9:38 PM, Lorenzo Colitti
mailto:lore...@google.com>> wrote:
What about the APNIC policy I cited a few emails ago? You have not explained
why you think it supports your point of view that using semantic bits does not
make it harder for ISPs to assign /48s to users.
The policy
On Jun 6, 2013, at 2:57 PM, Owen DeLong
mailto:o...@delong.com>> wrote:
If you claim you gave a customer a /48 and the customer reports that they are
not allowed to exercise control over the use of that /48, then, you have not,
in fact, delegated authority over that /48 as you have claimed to AR
On Jun 6, 2013, at 10:09 AM, Lorenzo Colitti
mailto:lore...@google.com>> wrote:
Start by saying how the statement I point to as justification does not, in
fact, mean what I say, and why it does not?
The text doesn't say that ARIN won't allocate bits for semantic prefixes. It
doesn't even ment
On Jun 6, 2013, at 9:35 AM, Lorenzo Colitti
mailto:lore...@google.com>> wrote:
Saying "it says nothing of the sort" without even citing it is not a very
convincing argument. If you want to state convincingly that it says nothing of
the sort, then why not start from the text I posted earlier and
On Jun 6, 2013, at 7:48 AM, Lorenzo Colitti wrote:
> Sorry, but no. This is clearly spelled out in the policy which I quoted
> earlier. Surely you're not saying that hearsay from an employee who happens
> to work in the research group of an RIR is more authoritative than than the
> official, ap
On Jun 5, 2013, at 11:30 PM, Lorenzo Colitti
mailto:lore...@google.com>> wrote:
Personally, I'm waiting for us to agree that due to current RIR policies, if an
ISP chooses to use semantic prefixes, then it will not be able to give users as
much space as it would be able to give them if it chose
On Jun 5, 2013, at 11:26 PM, Lorenzo Colitti
mailto:lore...@google.com>> wrote:
Thus, using semantic prefixes makes it much harder to assign /48s to users -
indeed, the letter of the policy above suggests that a /48 is acceptable only
in the case of "extra large end sites", and that *every singl
On Jun 5, 2013, at 6:27 PM, Owen DeLong
mailto:o...@delong.com>> wrote:
Also note that if you give residential customers /56s, you will need to be able
to justify /48s for businesses in terms of the number of /56s they need at each
end site in order to qualify for an additional allocation. At le
On Jun 5, 2013, at 3:28 PM, "Manfredi, Albert E"
wrote:
> Actually, I was about to make that suggestion myself. We can stop this
> infinite thread by simply saying, do whatever semantic tricks you want with
> the address blocks allocated to you, but know that you won't get any more
> just so y
On Jun 5, 2013, at 12:04 PM, Sander Steffann wrote:
> Keep in mind that RIRs won't give you extra address space though. If you
> assign /56s to your users then that is what the RIR need-base calculations
> are based on (according to current policy).
So if the ISP says "we need a /48 per custome
On Jun 5, 2013, at 10:23 AM, Sander Steffann wrote:
> So they playing field is mixed. Some do /56, but the major players do (or
> will do) /48.
Sure, but you're just confirming my point that if a provider wants to do
semantic prefixes, they can get enough bits to do them by allocating a /56 to
On Jun 4, 2013, at 11:42 PM, Lorenzo Colitti
mailto:lore...@google.com>> wrote:
I still don't understand. What the above sentences seem to be saying is that
"there are bits available for semantic prefix assignment because RIRs assume
/48 but users don't actually get /48". Is that your point?
No
On Jun 4, 2013, at 11:11 PM, Lorenzo Colitti
mailto:lore...@google.com>> wrote:
On Wed, Jun 5, 2013 at 12:02 PM, Ted Lemon
mailto:ted.le...@nominum.com>> wrote:
So then your argument should be "RIRs should not plan to assign /48s to
subscribers because ISPs are assigning /5
On Jun 4, 2013, at 10:53 PM, Lorenzo Colitti
mailto:lore...@google.com>> wrote:
So then your argument should be "RIRs should not plan to assign /48s to
subscribers because ISPs are assigning /56s to subscribers anyway"?
No, it shouldn't. My argument is that the belief that no bits are availabl
On Jun 4, 2013, at 10:14 PM, Lorenzo Colitti
mailto:lore...@google.com>> wrote:
Addressing policy cannot be shaped on what the IETF thinks might happen in the
best case. It must be done taking into account real world constraints. If
efficiently-addressed, routed home networks don't happen, then
On Jun 4, 2013, at 11:12 AM, Owen DeLong
mailto:o...@delong.com>> wrote:
I don't rule out anything. I state that the bits should be there so that
automated topologies can be made to function in an arbitrary plug-and-play
environment.
If it can be used for other purposes, that's fine, but I do no
On Jun 3, 2013, at 9:46 AM, Owen DeLong
mailto:o...@delong.com>> wrote:
I believe that making bits available for greater flexibility in consumer
networking is a good use of bits.
I believe that stealing bits from the consumer for purposes of allowing the
provider to overload the IP address with
On Jun 2, 2013, at 11:26 PM, Owen DeLong
mailto:o...@delong.com>> wrote:
My point is that it should be up to the person running the home net (or other
end site) to decide what is better for their site and that we should not be
making the choice for them.
So, to recap, RIR policies seem to allow
On Jun 2, 2013, at 11:24 PM, Owen DeLong
mailto:o...@delong.com>> wrote:
No, there is no use case where this is better than doing the delegations from
the router that received the initial delegation (since we're apparently just
arguing by vigorous assertion).
Is your opinion. I disagree with you
On Jun 2, 2013, at 11:21 PM, Owen DeLong
mailto:o...@delong.com>> wrote:
Yes. A fine engineering solution for demonstration purposes, but not a good
solution for us to recommend for deployment in the long term. Because it
commits wide prefixes to sub-delegations, it wastes address space prof
On Jun 2, 2013, at 8:51 PM, Lorenzo Colitti
mailto:lore...@google.com>> wrote:
We shouldn't resuscitate it unless it has a solution for "user unplugs the
router which assigned all the prefixes in the home".
"Making hosts try all their addresses all the time" (or, more euphemistically,
"happy eye
On Jun 2, 2013, at 8:48 PM, Lorenzo Colitti
mailto:lore...@google.com>> wrote:
And when one of those two edge routers is unplugged by the user, the network is
dead in the water. We need to do better than that.
Yes, there is a lot of code out there that breaks horribly in the presence of
multiho
On Jun 2, 2013, at 8:40 PM, Lorenzo Colitti
mailto:lore...@google.com>> wrote:
An unadopted draft does not an implementation (or a deployment!) make.
The two are in fact completely orthogonal!
IETF IPv6 working group mailing l
On Jun 2, 2013, at 5:02 PM, Tim Chown
mailto:t...@ecs.soton.ac.uk>> wrote:
Isn't the hipnet model one with recursive PD?
Yes. A fine engineering solution for demonstration purposes, but not a good
solution for us to recommend for deployment in the long term. Because it
commits wide prefixes
On Jun 2, 2013, at 12:39 PM, Owen DeLong
mailto:o...@delong.com>> wrote:
We can agree to disagree.
Do you want to fly in an airplane designed by someone who agrees to disagree
with you on whether heavy objects fall faster in a vacuum? Agreeing to
disagree on matters of opinion is fine, but we
On Jun 2, 2013, at 12:29 PM, Tim Chown
mailto:t...@ecs.soton.ac.uk>> wrote:
Well, this is why the homenet arch says that prefix delegation should be
efficient. Using DHCP-PD forces a structure to the delegations, and thus
potential inefficiency. The OSPF-based solution doesn't have that limitat
On Jun 2, 2013, at 11:59 AM, Owen DeLong
mailto:o...@delong.com>> wrote:
You are assuming that all of the subordinate routers will act as DHCP relays
rather than doing PD.
That is certainly one possible solution, but, not necessarily ideal in all
cases.
In cases where the subordinate routers sho
On Jun 2, 2013, at 1:22 AM, Owen DeLong
mailto:o...@delong.com>> wrote:
{ISP Connection} -> Router -> multiple segments each of which contains one or
more routers, some of which have multiple segments which contain additional
routers.
All of the routers below the second tier are downstream from
On Jun 1, 2013, at 8:42 AM, Owen DeLong
mailto:o...@delong.com>> wrote:
The second one sounds like it gets pretty dysfunctional if you have downstream
routers with downstream routers.
There's no such thing, unless you think home nets are transit nets. If you
mean what if the network is multih
On May 31, 2013, at 10:47 PM, Owen DeLong
mailto:o...@delong.com>> wrote:
What solutions exist today that provide for the home of the future where there
are, in fact, multiple levels of routers many of which are managing routers
underneath them with multiple links attached?
There's a fairly ugl
On May 31, 2013, at 10:14 PM, Owen DeLong
mailto:o...@delong.com>> wrote:
The /48 is in order to allow 16 bits of space for automating the deployment of
hierarchy and routing within the end-site.
Right, which is ludicrous overkill, given that we have two different solutions
for the problem of e
On May 31, 2013, at 5:46 AM, Ray Hunter wrote:
> I was suggesting looking at using a tag option within an existing header
> (the hop by hop header), which theoretically is already processed by all
> nodes along the path. So new options rather than a new header.
Right, but the hop-by-hop header do
On May 30, 2013, at 12:08 PM, Owen DeLong
mailto:o...@delong.com>> wrote:
Not a great assumption... They should need 4 million or more /48s since every
subscriber is at least one end site and every subscriber end site should
receive a /48.
I am not in love with using bits from prefixes as seman
On May 23, 2013, at 10:04 AM, Brian Haberman wrote:
> 6MAN.
Really? I would have assumed that this would be an http document, but if it
can be done in 6man, that would be cool.
IETF IPv6 working group mailing list
ipv6@ietf.
On May 23, 2013, at 11:01 AM, Michael Sweet wrote:
> I've seen plenty of "pending" (not approved, not rejected) errata for other
> RFCs for stuff like this. Posting to the ipv6 mailing list is useful for
> people involved in RFC development but is completely opaque to ordinary
> implementers o
I happen to agree that a change like this would be a good change, but I also
agree that it needs to be done as a consensus document, not as an erratum.
This is true not only for process reasons, but because I think the change as
proposed was too broad. Is there a working group alive where th
On Apr 7, 2013, at 11:07 AM, joel jaeggli wrote:
>> So that possibly makes sense internally to the car, although possibly not.
>> It doesn't make a lot of sense to me between cars, except perhaps in the
>> most restricted applications. When you talk about capacity constrained RF
>> channels
On Apr 4, 2013, at 7:44 PM, Richard Roy wrote:
> [RR>] As I am sure you know, privacy is a cross-layer issue. Any layer that
> compromises privacy, compromises it for the user/ITS station. That said,
> FNTP/WSMP replace the IP layer with a different albeit null) networking
> protocol (essentiall
On Apr 4, 2013, at 1:51 PM, Richard Roy wrote:
> Furthermore, anonymity concerns and the simultaneous morphing of all content
> in these safety messages that could be used to infer behavior and violate
> privacy are being addressed within the IEEE 1609.2 and ETSI TC ITS security
> working groups (
On Apr 3, 2013, at 9:13 PM, Michael Richardson wrote:
> So, we have assumed that a 802.11p sniffer sitting in Times Square can
> sniff the prefix used by passing vehicles. If I put another sniffer
> outside Wrigley Field, I can do correlation... how does knowing the VIN
> help me? I already know
On Apr 3, 2013, at 12:00 PM, Michael Richardson
wrote:
> So, I have a question: how much privacy is actually contained in the
> VIN or indexed by the VIN? Given that it's printed on the windshield.
> Yes, it contains model, year and manufacturer of the car, but all of
> that information is also
On Feb 1, 2013, at 10:42 AM, Chuck Anderson wrote:
> There is also draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04
> which handles the case for DHCPv6 clients. That also requires no
> changes to clients--only the DHCPv6 Relay Agent.
This document doesn't apply to SLAAC or CGA addresses, thou
On Dec 12, 2012, at 10:40 AM, Brian E Carpenter
wrote:
> But all IPv6 nodes are required to support SLAAC and all
> routers are required to generate RAs. What is the meaning
> of "no SLAAC"?
A router advertisement that doesn't offer any prefixes where stateless
autoconfiguration is enabled?
--
There has been a working group last call in the DHC working group for the
DHCPv4-over-IPv6 draft, which provides a mechanism for doing DHCPv4 relay on an
IPv6-only network (for the purpose of configuring IPv4 stacks in a dual-stack
environment where the IPv4 service is provided over an IPv6 tunn
On Nov 22, 2011, at 8:18 AM, Ole Troan wrote:
for clarification, that was not my proposal. my suggestion was to merge all
information within one "provisioning domain".
unsure if we will end up with provisioning domain = link, as detection of
multiple provisioning domains on a single link may not
On Nov 21, 2011, at 3:36 PM, Thomas Narten wrote:
> Isn't this what DHC already does? I.e., you run DHCP on two
> interfaces, and get conflicting information.
I don't know what the antecedent to "this" was intended to be.
> The existing DHCP specs are silent on this, and the DHC WG has never
> be
On Nov 14, 2011, at 3:55 PM, "Mohacsi Janos" wrote:
> I think in reality it will not be very easy to implement all these things.
> Some Operating System might implement RA(SEND), some the Secure DHCP, some
> none of above. . The operator should operate the network consistently: - same
> informa
On Nov 14, 2011, at 10:35 AM, "Ole Troan" wrote:
> wouldn't they continue to do it wrong if we were to specify a default
> "policy"?
> I'm in the camp of "use all the information you've got". the prefer one of
> the other by default, is heading down 3484 country, and that hasn't been a
> pleasa
On Nov 14, 2011, at 10:30 AM, "Ole Troan" wrote:
> isn't this what a host does anyway? if it has more than one router on the
> link?
Yes, and they reliably do it wrong. This is why we have a MIF working group!
:)
IETF IPv6 w
On Nov 14, 2011, at 9:59 AM, "Ole Troan" wrote:
> why not just merge all the information received?
> e.g. if you get DNS server over DHCP and RA, use all.
> if you get addresses via SLAAC and DHCP, you use all...
Because "just merge" is essentially equivalent to "just walk across the river
witho
On Nov 14, 2011, at 9:46 AM, "Hui Deng" wrote:
> Finally, there is such thing as secure DHCP, so if
> both RA and DHCP are secure, prefer SEND. I must admit that I never
> heard about any realistic deployments of secure DHCP, but it will change
> over time.
This doesn't agree with the list of ste
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.
No, strictly speaking the *clients* need to be protected against DoS attacks.
One way to do this
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.
That's fine for service providers, but service providers are not
On Jun 23, 2011, at 4:40 PM, Manfredi, Albert E wrote:
> Your solutions appear to be more client-oriented.
That's correct. Ultimately the security of the client depends on the client
being secure. Trying to secure the client by securing the network is a noble
cause, but ultimately doomed to
On Jun 23, 2011, at 2:36 AM, Mikael Abrahamsson wrote:
> I don't see how it can be fixed. Short of encrypting all traffic and
> pre-distributing keys, ethernet can't be fixed without the "bandaids" you
> seem to call the measures being used widely to assure ethernet can in fact be
> used securel
On Jun 22, 2011, at 8:25 PM, Mark Smith wrote:
> You're right, with Ethernet being the wrong protocol.
Well, let's be clear here: Ethernet is apparently the wrong protocol *for you*.
You should be running 802.1x, not plain ethernet, because you have specific
needs that make plain ethernet an i
On Jun 22, 2011, at 7:41 AM, Mikael Abrahamsson wrote:
> I agree, that's the deployment model I advocate for hostile scenarios. Use
> DHCPv6 for stateful addressing, advertise default GW via RA, don't advertise
> any on-link prefix, and make sure hosts can't L2 communicate at all with each
> oth
On Jun 14, 2011, at 5:26 AM, "Nick Hilliard" wrote:
> probably vendors aren't going to do much about dhcp6-guard unless there is a
> standard to work towards. I'd offer to help out, but my dhcpv6-fu is
Can you come to the dhcwg meeting and talk with us about the problem?
--
On Jun 13, 2011, at 3:38 PM, Nick Hilliard wrote:
> dhcpv6 suffers from exactly the same problem. Are there plans to introduce
> dhcpv6-guard?
Nobody's proposed it.
IETF IPv6 working group mailing list
ipv6@ietf.org
Administra
On Nov 3, 2008, at 10:45 PM, Joseph Hyunwook Cha wrote:
I am assuming that (b) is supported by the provider. With this
assumption, packets destined to extra addresses can reach actual
destination hosts configured with these addresses via the ND proxy.
Yes, but this seems like an extraordinar
On Nov 3, 2008, at 6:40 PM, Joseph Hyunwook Cha wrote:
However, if the service provider provides DHCPv6 service for the
internet connectivity of customer's hosts and is willing to give
only /128 addresses without delegating prefixes, there are no other
feasible solutions than 6to6 NAPT for
On Oct 17, 2008, at 4:21 AM, Ralph Droms wrote:
1. Is the following text an accurate summary of the previous IETF
consensus on the definition and use of M/O bits:
The M/O flags indicate the availability of DHCPv6 service for
address assignment and other configuration information,
respectiv
On Oct 16, 2008, at 7:18 AM, Iljitsch van Beijnum wrote:
Anyone in the cellular industry reading this? What about firing up
transmitters and using up battery every 120 seconds for a protocol
that you KNOW isn't going to do anything useful?
In order for this to be a valid rejoinder, it would hav
On Oct 13, 2008, at 9:48 PM, Pekka Savola wrote:
I don't see why M/O bits would need to be completely deprecated (they
could still be hints about what should be available in the network).
I don't see what good a hint is. We'd need to understand what advice
the hint was intending to give.
Joseph, to summarize, it sounds like you believe that the ability to
stop DHCP clients broadcasting on a link is a requirement. And you
therefore think that deprecating the M&O bits is not the right
answer. Is that correct?
---
On Sep 18, 2008, at 6:01 AM, Thomas Narten wrote:
>> Perhaps this point might be a major conflict. As we both know,
>> consecutive DHCPv6 SOLICIT messages are sent exponentially
>> back-offed if no valid replies are received within timeouts. Since
>> this always holds, I would like to ask you why M
On Aug 23, 2007, at 5:20 AM, Mark Smith wrote:
I don't like doing that sort of thing, but I like that both the DHCP
server and hosts are robust enough to handle it gracefully when I
do. A
few extra packets seems to me to be a relatively small price to pay
for
robustness and resilience.
I'm
On Aug 2, 2005, at 5:27 PM, JINMEI Tatuya / 神明達哉 wrote:
At the
very bottom line, my understanding is that we can accept some level of
extensions to the current protocol...is that correct?
Yes, I think that's correct. The one extension I heard proposed,
which made stateless DHCP more compat
On Jul 27, 2005, at 12:21 AM, Iljitsch van Beijnum wrote:
Requirement 1 simply says "DHCP is not available"; it doesn't say "do
not try to find it".
I disagree. On some networks it's inappropriate to try to use DHCPv6.
And if hosts are going to look for DHCPv6 servers regardless of the
valu
On May 27, 2005, at 11:55 AM, Bound, Jim wrote:
If others want the cross posting that is fine I just asked the
question
and would like to hear what people think that is all.
Seems like part of what's going on is that we needed to have this
discussion cross-posted a year or three ago, so it'
On May 27, 2005, at 1:40 PM, Bernie Volz (volz) wrote:
Does anyone really see any value in 1?
And this is always possible - just don't configure the DHCPv6 server
with any configuration parameters to send out.
1 seems a bit odd, yes.
--
On May 27, 2005, at 6:18 AM, Bernie Volz (volz) wrote:
These changes would potentially cause some issues with any deployments
today because the clients and servers do not support this "new"
behavior, but it that's why it is critical we work this out ASAP.
However, those clients, if they use the M
On May 27, 2005, at 11:25 AM, Bernie Volz (volz) wrote:
If people are really concerned about this, we can always add a DHCPv6
option to the Solicit that tells the server "I'm a new client and am
able to receive other configuration parameters even if you're not
going
to give me any addresses."
On May 27, 2005, at 9:35 AM, Bound, Jim wrote:
ughh. sorry know of three production servers in use Lucent, HP, and
Linux version.
That's not what I mean. The point is that it's early days, and
updating servers isn't a hard problem. My point is that I don't
know of any widespread deploy
On Jun 6, 2004, at 9:28 PM, Christian Huitema wrote:
1) In the disadvantage of DHCPv6 section, you ought to mention that
there is a ensure that the DHCP server always returns an up-to-date
value for the address of the preferred recursive DNS server. In large
networks, this is not trivial: the notio
76 matches
Mail list logo
