IPv6 multicast address equivalent of IPv4 multicast address: 234.56.78.90 ? - TCP-IP

This is a discussion on IPv6 multicast address equivalent of IPv4 multicast address: 234.56.78.90 ? - TCP-IP ; Gegroet, Skybuck Flying schreef: > I don't quite understand ipv6 scopes and multicast scopes and such... pretty > confusing. No really. It just defines how far your multicast is going to reach. That's all. > With ipv4 the following multicast ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 31 of 31

Thread: IPv6 multicast address equivalent of IPv4 multicast address: 234.56.78.90 ?

  1. Re: IPv6 multicast address equivalent of IPv4 multicast address:234.56.78.90 ?

    Gegroet,


    Skybuck Flying schreef:
    > I don't quite understand ipv6 scopes and multicast scopes and such... pretty
    > confusing.


    No really.

    It just defines how far your multicast is going to reach. That's all.



    > With ipv4 the following multicast address works for loopback, local area
    > network and probably internet too:
    > 234.56.78.90


    To be honest. I doubt that this would ever get on the internet.

    On the local network, OK, as long as all routers of the network have
    IP-multicast enabled and all point to the same RP.

    But as the implementation of "internet-wide multicast" on IPv4 was done
    on a protocol (MSDP) which isn't scalebale at all, I would not count on
    having anything near "internet-wide" multicast.



    > Is there an ipv6 multicast equivalent ?
    > I am looking for a single ipv6 multicast address which can be used to test
    > pretty much everything: loopback, lan, internet ?!?


    The easiest you can do is use the "RP-embedded" IP-addresses.

    Say you have a /64 subnet for IPv6 (say 2001:1234:5678:9ABC::/64) and
    the RP uses one of the first 15 addresses, then the range of IPv6
    multicast-addresses you can use is
    FF7x:0y40:2001:1234:5678:9ABC::/96

    Where "x" is the scope, and "y" is the last 4 bits of the IP-address of
    your RP.
    Read rfc3956 for more info.



    But of course, this will only work if
    - your CPE-router supports IPv6 multicast (I haven't seen much who do).
    - your ISP supports IPv6 multicast
    - your ISP peers with other ISPs for multicast.

    But if your goal is to play around with IPv6 multicast, I propose you
    contact m6bone to set up a tunnel with them. That way you can try out
    IPv6 multicast with some other people.
    See http://www.m6bone.net/




    > Bye,
    > Skybuck.

    Cheerio! Kr. Bonne.

  2. Re: IPv6 multicast address equivalent of IPv4 multicast address: 234.56.78.90 ?

    "Pascal Hambourg" wrote in message
    news:g8tvb4$oal$1@biggoron.nerim.net...
    > Skybuck Flying a écrit :
    >>>
    >>>IPv6 addresses are 128-bit long, so the notation contains 8 hex 16-bit
    >>>groups separated by colons.

    >>
    >> The IPv4 Address notation was 4 decimal 8 bit groups separated by dots.
    >>
    >> Why now the sudden change to 16 bit groups ?

    >
    > The address length was multiplied by 4. Would you have preferred a
    > notation with *16* 8-bit groups ?


    Depends on point of view.

    1. Clutter-point-of-view:

    The 8 group version is easier because less of these ':'.
    (And leading zero's might be omitted ? )

    I think

    FF11:0102:0304:0506:0708:090A:0B0C:0D0E

    and

    FF11:102:304:506:708:90A:B0C0E

    is considered the same ?

    Or is this one illegal ?

    2. Transition-point-of-view:

    People are used to seperating ip addressess in bytes.

    So the 16 group version would be more natural/logical.

    3. Programmer-point-of-view:

    Short ipv6 notations probably more difficult to translate from string to
    binary.

    Vica versa probably too.

    4. Processor/performance-point-of-view (only matters if string conversions
    need to be done often which is probably not the case):

    Full-ipv6-notation probably faster...

    5. Confusion-point-of-view:

    Full-ipv6-notation 100% crystal clear... no doubts about it.

    It could even be written as:

    6. Coolness point-of-view:

    12.3.24.43.35.64.157.23.123.123.43.54.65.1.3.34

    ^^^ Looks ways more cool.

    7. Handyness point-of-view:

    12.3.24.43.35.64.157.23.123.123.43.54.65.1.3.34

    ^^^ This could work in a browser as well...
    since it contains decimals only... it's clearly not a dns name.

    While hexadecimals might be interpretated accidently as dns...
    unless ofcourse one scans for : but that creates other problems as well.
    : already used for something else.

    8. Calculations point-of-view:

    Quickly calculating a mask... I could do that with decimals...

    However I am not so good with hexadecimals.

    Some people might understand binary... but hexadecimals ? That's a stretch !


    9. Common knowledge/reasoning point-of-view:

    Everybody knows what comes after 1, it's 2, after that 3, etc.

    What about AA or 3B or 10 or F.

    Makes it more difficult for people to understand the addresses.

    When I see:

    212.123.123.43
    214.23.23.43

    Then I kinda know how far apart these networks might be... especially

    214.23.22.45

    With hexadecimal that again becomes a little bit more difficult

    aa:ff:fa:ba:a5:b
    aa:ff:fa:10:a3:d

    Not to mention the short notation confusion.

    Actually I thought about this once how to maybe make it remember easier.

    Cow.Horse.Shoe.Iron.Metal.Go.Home.Ok.Jezus.Etc.

    Give each byte value a name

    LOL.

    0 = Cow
    1 = Horse
    3 = Shoe
    etc
    255 = Something

    So then it would translate to:

    1.2.3.4.5.6.7.8.etc

    Anyway it's so long... that's a problem in itself... now the hexadecimal and
    notation stuff adds a little more complexity to it

    Not to mention the scope and special stuff. Ouch !

    Bye,
    Skybuck !



  3. Re: IPv6 multicast address equivalent of IPv4 multicast address: 234.56.78.90 ?

    I am doing quite well yes

    However the OS (Windows XP 32 bit) was not doing so well when looping back
    the multicast traffic...

    Don't know why... maybe I didn't set the loopback to "on". Maybe if it was
    "on" it would work better..

    But the OS started freezing a lot at 7 MByte/sec etc with larger packet
    sizes or so (2KB or 12 KB).

    This was on PIII 450 mhz though.

    So far WinXP x64 seems to work ok on AMD 3800+ dual core

    Bye,
    Skybuck.



  4. Re: IPv6 multicast address equivalent of IPv4 multicast address: 234.56.78.90 ?

    Also I had firewall on on windows xp 32 bit... or something like that... not
    completely sure... sometimes it asked to unblock... sometimes not (?) that
    might have something to do with the freezing... (firewall maybe eating lots
    of cpu)

    Oh well I don't care such much about the PII 450 mhz performance... I don't
    use that PC so much anymore...

    As long as it's working ok on my current dream pc then I am happy =D

    Bye,
    Skybuck.



  5. Re: IPv6 multicast address equivalent of IPv4 multicast address:234.56.78.90 ?

    Skybuck Flying a écrit :
    >
    > (And leading zero's might be omitted ? )
    >
    > I think
    >
    > FF11:0102:0304:0506:0708:090A:0B0C:0D0E
    >
    > and
    >
    > FF11:102:304:506:708:90A:B0C0E
    >
    > is considered the same ?


    Yes, leading zeroes in each group may be omitted.

  6. Re: IPv6 multicast address equivalent of IPv4 multicast address:234.56.78.90 ?

    Gegroet,

    Skybuck Flying schreef:
    >> The address length was multiplied by 4. Would you have preferred a
    >> notation with *16* 8-bit groups ?


    > Depends on point of view.
    > 1. Clutter-point-of-view:
    > The 8 group version is easier because less of these ':'.
    > (And leading zero's might be omitted ? )


    > I think
    > FF11:0102:0304:0506:0708:090A:0B0C:0D0E
    > and
    > FF11:102:304:506:708:90A:B0C0E
    > is considered the same ?


    See rfc4291.


    > 2. Transition-point-of-view:
    > People are used to seperating ip addressess in bytes.
    > So the 16 group version would be more natural/logical.


    People wil just have to learn to deal with hex.

    In most cases, people will only have to deal with the first 64 bits, so
    you'll remember that you have IP-address in the range
    2001:1234:5678:SSSS:

    Where 2001:1234:5678 will be fixed (identifing the company), "SSSS" is
    an identification of the network (read: a site-id) and the
    will be filled in based on the MAC-address of the host, so you do not
    need to worry about that.

    As there is no limit anymore of 256 IP-addresses per subnet, you can
    just create one layer-2 network per building. No need to create multiple
    subnets per building and things like that.



    Also, as hosts can have multiple IP-addresses on one machine, what you
    can do is use IP-addresses to identify SERVICES instead of SERVERS.

    What you can do is reserve a range of IP-addresses for services, say
    2001:1234:5678:0::xxxx:yyyy where
    "xxxx" = service (e.g. 1 = DNS, 2 = YP, 3 = mail-server, 4 = ...)
    "yyyy" = machine

    And "site" (the "SSSS" above) = 0.

    E.g.
    2001:1234:5678::3:8 will then be the IP-address of the 8th mail-server
    of the company.

    You just stick this IP-address as the an additional IP-address to the
    correct box, and announce the specific /128 route to that box in your
    internal routing-protocol on your network and that's it.

    Build your own logic!



    > 3. Programmer-point-of-view:
    > Short ipv6 notations probably more difficult to translate from string to
    > binary.

    That's why you have C-libraries. :-)


    > 4. Processor/performance-point-of-view (only matters if string conversions
    > need to be done often which is probably not the case):
    > Full-ipv6-notation probably faster...


    Hum. Unless you need to do a million conversions per second, this looks
    all pretty trivial.


    > 5. Confusion-point-of-view:
    > Full-ipv6-notation 100% crystal clear... no doubts about it.


    Do I hear a sarcastic tone? :-)


    > It could even be written as:
    > 6. Coolness point-of-view:
    > 12.3.24.43.35.64.157.23.123.123.43.54.65.1.3.34
    > ^^^ Looks ways more cool.


    Nah. I guess we can vote on it, but I think most people find this much
    more confusing then the correct syntax.


    > 7. Handyness point-of-view:
    > 12.3.24.43.35.64.157.23.123.123.43.54.65.1.3.34
    > ^^^ This could work in a browser as well...
    > since it contains decimals only... it's clearly not a dns name.
    > While hexadecimals might be interpretated accidently as dns...
    > unless ofcourse one scans for : but that creates other problems as well.
    > : already used for something else.


    The URL with a IP-address is constucted like this:
    http://[2001:1234:5678::1]:8080/

    See rfc 2732


    > 8. Calculations point-of-view:
    > Quickly calculating a mask... I could do that with decimals...


    "masks" do not exist anymore, only "prefix" values.

    Prefixes in IPv6 are almost always /32, /48 or /64, which represents 2,
    3 or 4 "packs" of 4 hex-values.

    2001:1234::/32 ( allocated to an ISP)
    2001:1234:5678::/48 (allocated to a company)
    2001:1234:5678:9ABC:;/64 (one layer-2 network)


    Remember, netmasks are a result of CIDR, which is the result of a
    shortage of IPv4-addresses to do (much easier) class-based routing.

    Ipv6 does not have this problem anymore, so there is no reason anymore
    to use netmasks.
    We're back to the "keep it simple" principle.



    > However I am not so good with hexadecimals.


    I guess more and more the impression that YOU are the problem, not IPv6. :-)



    > Some people might understand binary... but hexadecimals ? That's a stretch !
    >


    > 9. Common knowledge/reasoning point-of-view:
    > Everybody knows what comes after 1, it's 2, after that 3, etc.
    > What about AA or 3B or 10 or F.



    It's actually quite logical.

    The problem with IPv4 is that you needed to "calculate" with them; as
    the size of a LAN was limited to 256 addresses.
    "OK, I have 4000 hosts overthere, so that's how much /24 subnets? 16, so
    we'll use 10.100.4.x up to 10.100.20.x"

    There is no reason to "calculate" in IPv6. Concider it all as an
    identifier of an network:
    2001:1234:5678:SSSS:



    You can even work on your own logic; say
    2001:1234:5678:XYYY:

    X = 1 -> IT network
    X = 2 -> technical network
    X = 3 -> sunray network
    ....
    X = F -> lab network

    YYY = identification of building.

    (or something like that)


    > Anyway it's so long... that's a problem in itself... now the hexadecimal and
    > notation stuff adds a little more complexity to it
    > Not to mention the scope and special stuff. Ouch !


    Look at it this way: IPv6 is a new network-technology and a way to do
    away with a lot of the limitations of IPv4.

    To say it with some music: "free your mind and the rest will follow".


    > Bye,
    > Skybuck !


    Cheerio! Kr. Bonne.

  7. Re: IPv6 multicast address equivalent of IPv4 multicast address: 234.56.78.90 ?

    >> Is there an ipv6 multicast equivalent ?
    >> I am looking for a single ipv6 multicast address which can be used to
    >> test
    >> pretty much everything: loopback, lan, internet ?!?

    >
    > The easiest you can do is use the "RP-embedded" IP-addresses.
    >
    > Say you have a /64 subnet for IPv6 (say 2001:1234:5678:9ABC::/64) and
    > the RP uses one of the first 15 addresses, then the range of IPv6
    > multicast-addresses you can use is
    > FF7x:0y40:2001:1234:5678:9ABC::/96


    The 7 is intriguing.

    Now that I read this document again:

    "RFC 4291 - IP Version 6 Addressing Architecture.mht"

    It seems those 7 bits are 4 flags.

    I knew about the first flag... the "transient" flag.

    It's supposed to be 1 if it's "dynamically" assigned.

    Which I think means: "It's not a known multicast address just a user
    multicast address".

    Anyway there seem to be 2 other flags:

    The R flag...
    The P flag...

    Each has it's own document explaining it.

    That's what you probably talking about... rp etc.

    Well it's getting way too complex for me at this point in time

    It's probably not gonna work anyway with my isp <- just a hunch.

    And I don't know anything about isp's network or whatever.

    At least the functionality is there for people that do know what the hell
    their doing

    Also it's there in case I ever make my own multicast protocol LOL =D

    I just want to know if I interpreted the T flag correctly ?

    Anyway at this point in time I have other interests... maybe in the future I
    look further into these r and p flags

    Bye,
    Skybuck.



  8. Re: IPv6 multicast address equivalent of IPv4 multicast address:234.56.78.90 ?

    Skybuck Flying wrote:
    > I knew about the first flag... the "transient" flag.
    >
    > It's supposed to be 1 if it's "dynamically" assigned.
    >
    > Which I think means: "It's not a known multicast address just a user
    > multicast address".


    No need to 'think' at all. It means exactly what it says in the RFC:

    T = 0 indicates a permanently-assigned ("well-known") multicast
    address, assigned by the Internet Assigned Numbers Authority
    (IANA).

    T = 1 indicates a non-permanently-assigned ("transient" or
    "dynamically" assigned) multicast address.

    > I just want to know if I interpreted the T flag correctly ?


    No.

  9. Re: IPv6 multicast address equivalent of IPv4 multicast address: 234.56.78.90 ?

    "EJP" wrote in message
    news:rpNsk.31390$IK1.11828@news-server.bigpond.net.au...
    > Skybuck Flying wrote:
    >> I knew about the first flag... the "transient" flag.
    >>
    >> It's supposed to be 1 if it's "dynamically" assigned.
    >>
    >> Which I think means: "It's not a known multicast address just a user
    >> multicast address".

    >
    > No need to 'think' at all. It means exactly what it says in the RFC:
    >
    > T = 0 indicates a permanently-assigned ("well-known") multicast
    > address, assigned by the Internet Assigned Numbers Authority
    > (IANA).
    >
    > T = 1 indicates a non-permanently-assigned ("transient" or
    > "dynamically" assigned) multicast address.


    IPv6 documents:

    IPv6 multicast addresses start with FF.

    Does this mean all multicast addresses are to be considered "well-known".

    If so this interpretation would always lead to a T of 0.

    On the other hand if "well known" / "assigned" means only the remaining
    bits/bytes.. then the remaining bits/bytes would need to be looked up in an
    IANA list of "well known" addressess

    Which could then result in a T of 0 as well.

    Otherwise it would be a 1.

    So a little bit more clarification on which bits/bytes the T is related to
    would be nice !

    Bye,
    Skybuck.



  10. Re: IPv6 multicast address equivalent of IPv4 multicast address:234.56.78.90 ?

    Hello,


    Skybuck Flying schreef:
    >>> I knew about the first flag... the "transient" flag.
    >>> It's supposed to be 1 if it's "dynamically" assigned.
    >>> Which I think means: "It's not a known multicast address just a user
    >>> multicast address".


    >> No need to 'think' at all. It means exactly what it says in the RFC:
    >> T = 0 indicates a permanently-assigned ("well-known") multicast
    >> address, assigned by the Internet Assigned Numbers Authority
    >> (IANA).
    >> T = 1 indicates a non-permanently-assigned ("transient" or
    >> "dynamically" assigned) multicast address.


    > IPv6 documents:
    > IPv6 multicast addresses start with FF.
    > Does this mean all multicast addresses are to be considered "well-known".
    > If so this interpretation would always lead to a T of 0.

    (...)


    Let's put it this way, if it doesn't start with FF, it isn't multicast.

    As you now know this, I think you're smart enough to find out the rest
    for yourself, aren't you? :-)



    > Bye,
    > Skybuck.


    Cheerio! Kr. Bonne.

  11. Re: IPv6 multicast address equivalent of IPv4 multicast address:234.56.78.90 ?

    Skybuck Flying wrote:
    > IPv6 multicast addresses start with FF.
    >
    > Does this mean all multicast addresses are to be considered "well-known".


    No. Why would it mean that?

    You seem to be just creating difficulties here. The specification seems
    perfectly clear to me.

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2