Which entry of the routing table was selected? - TCP-IP

This is a discussion on Which entry of the routing table was selected? - TCP-IP ; "Martijn Lievaart" wrote: > In that case, stop thinking of an > interface having an IP adress. Yes, it appears it has come to this. Yet we know that while maybe a single MAC addresses can be associated with multiple ...

+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3
Results 41 to 49 of 49

Thread: Which entry of the routing table was selected?

  1. Re: Which entry of the routing table was selected?

    "Martijn Lievaart" wrote:

    > In that case, stop thinking of an
    > interface having an IP adress.


    Yes, it appears it has come to this. Yet we know that while maybe a
    single MAC addresses can be associated with multiple interfaces in one
    host (which is fine as long as they're in different IP subnets), IP
    addresses are instead associated strictly with an interface of the
    machine. Here's the quote from RFC 791, where "local address" is the MAC
    address:

    The local address, assigned by the local network, must allow for a
    single physical host to act as several distinct internet hosts.
    That is, there must be a mapping between internet host addresses and
    network/host interfaces that allows several internet addresses to
    correspond to one interface. It must also be allowed for a host to
    have several physical interfaces and to treat the datagrams from
    several of them as if they were all addressed to a single host.

    The IP address identifies an interface. Multiple IP addresses can
    identify that same interface. Multiple interfaces cannot be identified
    by the same IP address.

    You're saying in practice this isn't so, at least when it comes to
    assigning IP source addresses to packets.

    > The coupling between an IP address an an interface is used only in a
    > few
    > specific instances.
    > - When a locally generated packet doesn't have a source address, the
    > address of the outgoing interface is used[1].
    > - When responding to an arp request[2].
    > - To add the correct route to the routing table[3].
    >
    > Other than that, don't think of an interface as "having" an address.
    > The
    > machine has addresses and the routing tables route the packet through
    > a
    > specific interface.
    >
    > M4
    >
    > [0] Except in the so called "strong ended IP model". In that model all
    > I
    > say is wrong. However I have never seen an IP stack implement that
    > model,
    > so better forget this footnote.
    >
    > [1] Strictly speaking, this is not correct. What if an interface has
    > multiple IP adresses? Which one should be choosen? The first? There
    > are
    > situations where that is wrong. In Linux, the source address is
    > determined
    > by the routing table to avoid this problem[4].


    This is an issue that needs to be fixed correctly, especially in IPv6.

    > [2] But nothing stops an IP stack to respond on all interfaces to arp
    > requests for all IPs of that machine. In fact, this is not uncommon.
    > So
    > even there the coupling is not so strict[4].
    >
    > [3] And again, this is not exactly an interface property, but a side
    > effect of setting up the interface[4].
    >
    > [4] And even this is not completely correct, but hey, let's not make
    > it
    > even more complex!
    >
    > --
    > Redundancy is a great way to introduce more single points of failure.


    Bert


  2. Re: Which entry of the routing table was selected?

    In article <1147375681.484484.229600@u72g2000cwu.googlegroups. com>,
    Albert Manfredi wrote:

    >> IP is about packet switching
    >> instead of circuit switching. Perhaps the fundamental difference is
    >> that in circuit switching the ends of the circuit have some control
    >> and a pretty good idea of the paths their data follow, but in packet
    >> switching, the hosts just toss their data out and just hope the next
    >> hop will pass it along in approximately the right direction.



    >This is going rather far afield of the original thread, but I think
    >you're being overly pessimistic.


    Only a circuit switching advocate would think I'm being pessimistic
    or saying anything negative about packet switching. A packet switching
    advocate thinks tossing packets in the ocean of routers and hoping
    they'll be passed in the right direction is a good thing and better
    than circuit switching. Given the popularity of VoIP among the
    telephants, most of the old "Bell Heads" have either died or become
    packet switching collaborators.

    > The only requirement for this to work,
    >you're being overly pessimistic. The only requirement for this to work,
    >with TCP, is that the source IP of packets be the IP address of the
    >actual port that transmitted the packet.


    You keep saying that, but it remains wrong, both for anything related
    how to standard TCP might work and to how TCP actually works.


    >There's plenty of fussing going on as we speak, in IPv6, to figure out
    >which of the multiple available IPv6 source addresses should be used in
    >specific sessions. It is going to depend in part on where the network
    >is at the other end of the session link. And even more interesting, the
    >specific case of a multihomed host came up. The problem is, some IPv6
    >addresses might not have scope compatible with the other end of the
    >link.


    Yes, but that's all irrelevant (except for the craziness smoke, vapor,
    and nonsense of splicing NAT into every host in the IPv6 Internet).
    Once a TCP 4-tuple is chosen, it cannot, does not, and does not need
    to change even if a multi-homed host loses interface that had owned
    of the IPv{4,6} addresses in the 4-tuple.


    >This is related. The relationship between port used and source address
    >matters. Sure, circuit-switched techniques make the redundant data path
    >comms more clear-cut. But in a controlled network, i.e. not the
    >Internet, the path taken by packets in normal conditions should be very
    >predictable. I just don't think this is so absurd.


    Absurd or not, IP is what it is. By your notions now as years ago
    when we argued about ATM, neither the Internet nor any except the
    most trivial, private (small-I) internet is what you consider a
    controlled network. The essense of packet switching is not controlling
    the path. If you control or even know the path, then you have a
    circuit, and that's not packet switching.

    Assymetric routes are a fact of life and not necessarily bad.
    Unpredictable routing is a Good Thing(tm), even if it is why Van
    Jacobson invented traceroute and why `ping -R` used LSRR back when
    that used to work.


    Vernon Schryver vjs@rhyolite.com

  3. Re: Which entry of the routing table was selected?


    vjs@calcite.rhyolite.com (Vernon Schryver) writes:
    > Only a circuit switching advocate would think I'm being pessimistic
    > or saying anything negative about packet switching. A packet
    > switching advocate thinks tossing packets in the ocean of routers
    > and hoping they'll be passed in the right direction is a good thing
    > and better than circuit switching. Given the popularity of VoIP
    > among the telephants, most of the old "Bell Heads" have either died
    > or become packet switching collaborators.


    we were called in to consult with this small client/server startup
    that wanted to do payments on their server
    http://www.garlic.com/~lynn/aadsm5.htm#asrn2
    http://www.garlic.com/~lynn/aadsm5.htm#asrn3

    they had this technology they called SSL and were looking at taking
    payment message definitions from a cricuit-based infrastructure and
    mapping it into a purely packet environment with this thing called a
    payment gateway (i've periodically claimed it may be the first SOA
    .... service oriented architecture).

    very early testing, there was a problem called into the trouble desk.
    the trouble desk had been used to doing first level problem
    determination in a telco provisioned circuit-based infrastructure.
    after 3hrs of concerted effort, they finally closed the trouble ticket
    as NTF (no trouble found).

    we had to go back and do some detailed analysis of all kinds of
    possible failure modes and then develop some amount of software and
    diagnostic procedures to even marginally compensate for not having a
    telco provisioned operation. at least for the server to payment
    gateway, we had fair amount of sign-off and authority and could see
    that it got done.

    part of it had been based on having done detailed vulnerability
    analysis of tcp/ip when were were starting our ha/cmp product
    in the late 80s
    http://www.garlic.com/~lynn/subtopic.html#hacmp

    minor topic drift on recent thread re: reliable connections/communication
    http://www.garlic.com/~lynn/aadsm23.htm#21 Reliable Connections Are Not
    http://www.garlic.com/~lynn/2006i.html#16 blast from the past, reliable communication
    http://www.garlic.com/~lynn/2006i.html#17 blast from the past on reliable communication
    http://www.garlic.com/~lynn/2006i.html#18 blast from the past on reliable communication
    http://www.garlic.com/~lynn/2006i.html#19 blast from the past on reliable communication
    http://www.garlic.com/~lynn/2006i.html#20 blast from the past on reliable communication
    http://www.garlic.com/~lynn/2006i.html#21 blast from the past on reliable communication


    --
    Anne & Lynn Wheeler | http://www.garlic.com/~lynn/

  4. Re: Which entry of the routing table was selected?

    On Thu, 11 May 2006 22:17:28 +0000, Rick Jones wrote:

    > In comp.protocols.tcp-ip Martijn Lievaart wrote:
    >> Think of a machine having the IP address, it is much more
    >> accurate[0].

    >
    >> [0] Except in the so called "strong ended IP model". In that model
    >> all I say is wrong. However I have never seen an IP stack implement
    >> that model, so better forget this footnote.

    >
    > Depending on which stacks you've seen you may have seen it and not
    > noticed it


    Spot on.

    > HP-UX 11 and later offers the Strong End System Model via an ndd
    > setting. The default is the "weak" end system model. Later versions
    > have a "firm" end-system model. Firm end-system in HP-UX means that
    > source IP is part of the route selection, but the restriction on
    > datagrams arriving on interfaces with matching IP(s) is relaxed to be
    > like the "weak" end system model.


    Ah, but HP also tried redefining how PMTUD works, then added another
    setting that allowed PMTUD as the rest of the world does it. Their "weak"
    end model was broken so this sounds as if the "firm" model is also how the
    rest of the world does "weak".

    The problem is a host with two (or more) ip addresses in different subnets
    on the same interface. Selecting a source address for outgoing packets
    must depend on the destination address in this case, or more precise on
    the route the outgoing packets take. So in my view, source address
    selection is a function of routing. In older HP-UXen HP got this wrong and
    always used the first address of the interface.

    > I suspect that Solaris 2 and later also offers the strong end-system
    > model with the weak as the default. I've no idea if it does something
    > akin to a "firm" one.


    It is to long since I played with Solaris.

    M4
    --
    Redundancy is a great way to introduce more single points of failure.


  5. Re: Which entry of the routing table was selected?

    On Thu, 11 May 2006 22:52:16 +0000, Albert Manfredi wrote:

    > "Martijn Lievaart" wrote:
    >
    >> In that case, stop thinking of an
    >> interface having an IP adress.

    >
    > Yes, it appears it has come to this. Yet we know that while maybe a
    > single MAC addresses can be associated with multiple interfaces in one
    > host (which is fine as long as they're in different IP subnets), IP
    > addresses are instead associated strictly with an interface of the
    > machine. Here's the quote from RFC 791, where "local address" is the MAC
    > address:
    >
    > The local address, assigned by the local network, must allow for a
    > single physical host to act as several distinct internet hosts.
    > That is, there must be a mapping between internet host addresses and
    > network/host interfaces that allows several internet addresses to
    > correspond to one interface. It must also be allowed for a host to
    > have several physical interfaces and to treat the datagrams from
    > several of them as if they were all addressed to a single host.


    I fail to see the relevance of this quote.

    > The IP address identifies an interface. Multiple IP addresses can
    > identify that same interface. Multiple interfaces cannot be identified
    > by the same IP address.
    >
    > You're saying in practice this isn't so, at least when it comes to
    > assigning IP source addresses to packets.


    This isn't so at all. Look at IP unnumbered in Ciscos IOS. I was amazed
    when I first saw tun interfaces under Linux with the same IP address as my
    ethernet interface, wich is essentially the same as Ciscos IP unnumbered.

    Mulitple interfaces can have the same IP addres, in fact it is pretty
    common. Multiple interfaces on multipoint interfaces probably should have
    different IP addresses, due to the arp to interface mapping, although I'm
    not completely sure about that.

    M4
    --
    Redundancy is a great way to introduce more single points of failure.


  6. Re: Which entry of the routing table was selected?

    In comp.protocols.tcp-ip Martijn Lievaart wrote:
    > Ah, but HP also tried redefining how PMTUD works, then added another
    > setting that allowed PMTUD as the rest of the world does it.


    I presume you are refering to the "it seemed like a good idea at the
    time" "use an ICMP echo request to probe the PMTU mechanism that was
    in earlier HP-UX 11 (and certain MacOS stacks - I forgot about that
    initially - and perhaps even Solaris since they all shared a common
    ancestor)? IIRC that was an il-fated attempt to avoid PTMU blackholes
    and indeed in the end had undesirable properties and was nuked.

    > Their "weak" end model was broken so this sounds as if the "firm"
    > model is also how the rest of the world does "weak".


    I'm a bit confused here - are you trying to equate weak end system
    with PMTUD behaviour?

    rick jones
    --
    denial, anger, bargaining, depression, acceptance, rebirth...
    where do you want to be today?
    these opinions are mine, all mine; HP might not want them anyway...
    feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

  7. Re: Which entry of the routing table was selected?

    "Martijn Lievaart" wrote:

    >> You're saying in practice this isn't so, at least when it comes to
    >> assigning IP source addresses to packets.

    >
    > This isn't so at all. Look at IP unnumbered in Ciscos IOS. I was
    > amazed
    > when I first saw tun interfaces under Linux with the same IP address
    > as my
    > ethernet interface, wich is essentially the same as Ciscos IP
    > unnumbered.


    Thanks guys (also Vernon, Rick, and Barry). Useful discussion. Even if I
    was viciously accused of being a circuit switching guy.

    Bert


  8. Re: Which entry of the routing table was selected?

    On Fri, 12 May 2006 17:11:10 +0000, Rick Jones wrote:

    >> Their "weak" end model was broken so this sounds as if the "firm"
    >> model is also how the rest of the world does "weak".

    >
    > I'm a bit confused here - are you trying to equate weak end system
    > with PMTUD behaviour?


    No, as I explained HPUX used to select the wrong source address on
    multinetted interfaces. Nothing against HPUX, it's one of the nicer OSses
    I worked with. But I consider both the PMTU ping strategy as well as
    selecting the wrong source address as bugs, that's the only eqation.

    M4
    --
    Redundancy is a great way to introduce more single points of failure.


  9. Re: Which entry of the routing table was selected?


    Martijn Lievaart wrote:
    > On Wed, 10 May 2006 09:22:04 -0700, Albert Manfredi wrote:
    >
    > > Yes, I understood that if asymmetric paths are acceptable, then clearly
    > > the source IP of the packet doesn't need to point to the true source
    > > port used by the machine.

    >
    > I think you mean s/port/interface/. In that case, stop thinking of an
    > interface having an IP adress.


    but they do have IP addresses. They just don't find the path-The router
    finds the path.
    The IP is usually only for identifiying the interface. And they don't
    usually write their ip in. except, I guess, as you say below.
    But isn't it silly and unrealistic to pretend that they don't have IP
    addresses when they do. It's not like it causes a big problem in
    understanding. It's largely only for identification, as you yourself
    indicate by listing when the ip is written into the packet.

    I was suprised when I read that cisco router's interfaces had IP
    addresses. that's because all I had was a 'home router' so I was
    actually connecting to a switch connected to effectively, a real router
    interface. - A brouter I suppose



    > The coupling between an IP address an an interface is used only in a few
    > specific instances.
    > - When a locally generated packet doesn't have a source address, the
    > address of the outgoing interface is used[1].
    > - When responding to an arp request[2].
    > - To add the correct route to the routing table[3].
    >


    ok




+ Reply to Thread
Page 3 of 3 FirstFirst 1 2 3